Azure Cloud Services (Extended Support) се повлекува на 31 март 2027: преселување на web и worker улогите

Microsoft го прогласи Azure Cloud Services (extended support) за застарен на 31 март 2025 и целосно го повлекува на 31 март 2027. Ако некоја ваша деловна апликација работи како web улоги и worker улоги, мора да работи на друго место во Azure пред тој датум. Најчестите прашања за повлекувањето се директни за двете прашања што сите ги поставуваат први: Microsoft „не може да одобри барања за продолжување“ и „не постојат алатки за миграција со еден клик“.

Од денес, 3 октомври 2026, тоа остава шест месеци.

За кого е ова

Типичниот случај: ASP.NET апликација на .NET Framework, web улога напред и една или две worker улоги што обработуваат редици зад неа, изградена од агенција пред осум или десет години. Агенцијата често заминала, апликацијата сè уште ја води обработката на нарачките или порталот за купувачи, а никој не ја отворил датотеката .csdef од последната миграција.

За да проверите дали сте засегнати, отворете го порталот на Azure и прикажете ги ресурсите од видот „Cloud services (extended support)“. Известувањето на Microsoft за повлекувањето води директно до тој приказ. Ако е празен, готови сте.

Оваа статија не е за Cloud Services (classic), кој беше повлечен во 2024. Ако добавувач го хостира производот за вас, миграцијата е негова работа: побарајте го неговиот датум писмено. Сè подолу е за тимови што го поседуваат кодот, или го поседуваат на хартија и мора да најдат некој што го разбира.

Зошто ова е потешко од преселувањето во 2024

Многу компании преминаа на extended support во 2024, кога classic беше повлечен. Тоа преселување беше евтино по дизајн. Прегледот на extended support на Microsoft вели дека датотеките .csdef, .cscfg и .cspkg „се пренесуваат и нема промена во форматите“ и дека „не се потребни промени во кодот за извршување“. Постоеше дури и миграција на место. Истата страница го препорачуваше extended support за апликации што не се развиваат, бидејќи „нуди брз пат за миграција“.

Овој пат нема цел од ист вид. Со зборовите на Microsoft, Cloud Services „е за распоредување апликации како виртуелни машини. Кодот што го пишувате е тесно поврзан со инстанца на виртуелна машина“. Вашиот код знае дека работи во улога. Ја чита конфигурацијата од улогата, наоѓа простор на дискот преку улогата, добива сертификати што ги инсталира улогата и извршува скрипти за поставување како администратор пред улогата да стартува. Сето тоа мора да се замени.

Уште нешто пред да ги прочитате официјалните насоки. Известувањето на Microsoft за повлекувањето и најчестите прашања именуваат едно одредиште, Service Fabric managed cluster. Страницата со прегледот наведува пет, а самата матрица за одлучување за миграција на Microsoft споредува седум. Service Fabric е стандарден избор, а не барање, и за многу web улоги е погрешниот.

Целите и кога одговара секоја

Web и worker улогите не мора да завршат на истото место. Изберете цел по улога.

App Service (Windows). Најблиското до web улога за ASP.NET апликација. Windows инстанците доаѓаат со инсталирани поддржани верзии на .NET Framework, па Web Forms и MVC 5 работат без препишување. Worker улогите можат да следат како WebJobs, кои работат „во истата инстанца како веб-апликацијата“ без дополнителен трошок. Ограничувањето е самата машина: апликациите што бараат COM компоненти, пристап до регистарот или MSI инсталатори Microsoft ги насочува кон Managed Instance, па задачите за стартување со зголемени привилегии немаат каде да одат на стандарден план.

App Service Managed Instance. Изграден за наследени Windows веб-апликации. Според прегледот на Microsoft, тој е „општо достапен за Windows веб-апликации во избрани региони“, ограничен на плановите Pv4 и Pmv4, со однапред инсталирани .NET Framework 3.5 и 4.8 и PowerShell скрипти за инсталирање што можат да регистрираат COM компоненти, да запишуваат клучеви во регистарот, да извршуваат MSI инсталатори и да го конфигурираат IIS. Тоа го покрива најголемиот дел од она што го правеа задачите за стартување со зголемени привилегии. Ограничувањата: само веб-апликации (без WebJobs), без контејнери, само Entra ID и managed identity (без приклучување на домен, NTLM или Kerberos), а во моментот на пишување единствениот наведен европски регион е North Europe.

Container Apps. Добро за worker улоги откако ќе бидат на современ .NET: скалирање управувано од редици, закажани задачи и задачи активирани од настани, скалирање до нула. Но барањата за контејнери велат дека „се бараат слики на контејнери засновани на Linux (linux/amd64)“. Кодот на .NET Framework не работи таму додека не се пренесе.

Azure Kubernetes Service. Извршува Windows Server контејнери во Windows групи на јазли, па улога на .NET Framework може да се стави во контејнер и да се пресели. Матрицата за одлучување и сложеноста на миграцијата и оперативниот товар ги оценува како високи. Одговара ако веќе користите Kubernetes, а не како прв кластер за една наследена апликација.

Virtual Machine Scale Sets. Матрицата го нарекува „поблиску до моделот на Cloud Services, со полесно преселување без промени“. Ја добивате назад виртуелната машина, заедно со закрпите, изработката на слики и поставувањето на IIS што порано улогата го правеше наместо вас.

Service Fabric managed cluster. Одредиштето што го именува Microsoft. Worker улогите чисто се пресликуваат на него. Web улогите често не: Service Fabric „не поддржува IIS“, а водичот за претворање го наведува ASP.NET Web Forms како неподдржан, со претворање во ASP.NET Core MVC како пат. Водичот за миграција на Service Fabric додава дека управуваните кластери „засега не поддржуваат контејнери“, па апликација зависна од IIS бара традиционален кластер, со повеќе работа за одржување.

Табела за одлучување

Што се менува во кодот

Пребарајте го решението за Microsoft.WindowsAzure.ServiceRuntime. Секоја датотека што го увезува е на списокот.

RoleEntryPoint

Worker улогата е класа што наследува RoleEntryPoint и ги препокрива OnStart, Run и OnStop. Ако Run заврши, инстанцата се рестартира. Service Fabric ги спојува трите во еден RunAsync што треба да запре „кога CancellationToken на методот RunAsync ќе биде сигнализиран“. На App Service или во контејнер, истата логика станува конзолна апликација или хостирана позадинска услуга со јамка и токен за откажување.

Делот што луѓето го пропуштаат е гасењето. OnStop ви даваше момент да ја завршите пораката што е во обработка. Проверете дали новиот хост пренесува сигнал за откажување и дали порака напуштена среде обработка може безбедно да се обработи двапати.

И web улогите често имаат таква класа, обично WebRole.cs. Ако нејзиниот OnStart прави што било (прилагодувања на IIS, загревање на кешот), откријте што пред да ја избришете.

RoleEnvironment

RoleEnvironment.GetConfigurationSettingValue("Key") ги чита поставките од .cscfg. Ништо надвор од Cloud Services не го обезбедува тоа. Пред да преселите што било, завиткајте го секој повик во еден мал интерфејс за конфигурација, а потоа насочете го тој интерфејс кон app settings, променливи на околината или Key Vault на новиот хост. Тоа е најевтината промена во проектот и го прави остатокот тестабилен на лаптоп.

Уште три употреби што треба да ги барате:

• RoleEnvironment.Changed, што ги применуваше промените во конфигурацијата без рестарт. Service Fabric има еквивалентен настан. На друго место сметајте дека промената на поставка го рестартира процесот и тестирајте што тоа прави со работата што е во тек.
• RoleEnvironment.CurrentRoleInstance, користен за избор на една инстанца за закажана работа. Активираните (triggered) WebJobs работат на една инстанца; континуираните работат на сите инстанци, освен ако не се ограничени. Одлучете експлицитно.
• Разгранувањата со RoleEnvironment.IsAvailable и IsEmulated. Тие ја одделуваат „облачната“ патека од „локалната“, а една од нив наскоро ќе стане мртов код.

.cscfg и .csdef

.cscfg ги содржи поставките по околина, бројот на инстанци и отпечатоците (thumbprints) на сертификатите. .csdef ги содржи крајните точки, големината на виртуелната машина, локалното складирање, задачите за стартување, складиштата на сертификати, а понекогаш и неколку IIS сајтови во една web улога. Поминете ги двете ред по ред и запишете каде ќе живее секој запис потоа: како app setting, референца во Key Vault, код за инфраструктура или никаде. Внатрешните крајни точки преку кои улогите директно се повикуваат меѓусебно бараат замена, или адреса на услуга или редица.

Сертификати

Extended support веќе ги принуди сертификатите во Key Vault, па тој дел од работата од 2024 се исплатува. Се менува начинот на кој кодот ги наоѓа. .csdef ги инсталира сертификатите во именувано складиште, често LocalMachine. На Windows App Service, поставката WEBSITE_LOAD_CERTIFICATES ги прави достапни во Current User\My. Кодот што го отвора складиштето LocalMachine не наоѓа ништо, а првиот повик на кој му треба сертификатот паѓа. На Linux контејнери, наместо тоа вчитајте го од Key Vault при стартување.

Задачи за стартување

Отворете го Startup.cmd. Тука живеат изненадувањата, обично извршувани со executionContext="elevated": фонтови за генерирање PDF, COM компонента, модул за препишување во IIS, промена во регистарот за TLS. Секој ред има три можни судбини: повеќе не е потребен, преместен е во скрипта за инсталирање на Managed Instance или е вграден во слика на контејнер или виртуелна машина.

Локално складирање

Ресурсот LocalStorage во .csdef, читан преку RoleEnvironment.GetLocalResource, на секоја инстанца ѝ даваше привремен диск. За вистински привремени датотеки користете ја привремената папка на платформата. Сè што мора да преживее рестарт, вклучително и датотеките за кои некој претпоставил дека се трајни, оди во Blob Storage.

Web Forms

Ова е одлуката што го движи остатокот. Web Forms е изграден врз System.Web и нема верзија за ASP.NET Core, па преселувањето на Web Forms апликација на Service Fabric или Container Apps значи препишување на нејзиниот кориснички интерфејс. App Service, Managed Instance, Windows контејнер или scale set можат сите да ја извршуваат непроменета. Преселете ја каква што е, а модернизацијата направете ја посебен проект со сопствен буџет. Препишување на интерфејсот не припаѓа на критичната патека кон датум на исклучување.

Останатото

VIP swap меѓу две облачни услуги станува deployment slots на App Service или ревизии на Container Apps. Логовите испраќани преку дијагностичката екстензија (WAD) бараат ново одредиште, обично Application Insights. Стандардниот App Service и Container Apps не нудат далечинска работна површина; Managed Instance ја дозволува преку Azure Bastion, само за дијагностика.

План од шест месеци

Сметајќи наназад од 31 март 2027, со декемвриските празници во средината.

Октомври: попис и избор на цел. Наведете го секое распоредување на extended support. За секоја улога евидентирајте ја верзијата на .NET Framework, дали е Web Forms или MVC, секој повик кон RoleEnvironment, задача за стартување, ресурс за локално складирање, сертификат и крајна точка. Потоа проверете го непријатниот дел: можете ли да го изградите распоредениот пакет од изворниот код што го имате? Кај системите изградени од агенции одговорот понекогаш е не, а октомври е месецот да се открие тоа. Изберете цел по улога.

Ноември: една улога, од почеток до крај. Додадете го обвивката за конфигурација, напишете ја целната околина како код за инфраструктура и пуштете една улога (обично наједноставната worker улога) во тест-околина, со логови, сертификати и тек за распоредување.

Декември и јануари: пренесете го остатокот. Заменете ги влезните точки, задачите за стартување и локалното складирање. Направете тест на оптоварување на staging околина со податоци слични на продукциските: WebJob или контејнер можеби нема да ја достигнат пропусноста на посветена виртуелна машина за улога.

Февруари: паралелна работа. Пуштете ја новата околина на вистински сообраќај. За worker улогите што делат редица со старите улоги, или прво направете ја обработката идемпотентна, или запрете ги старите worker улоги пред да ги стартувате новите.

Почеток на март: преминување. Префрлете го DNS со доволно резервно време. Чувајте го старото распоредување запрено, но недопрено, една до две недели, а потоа избришете го. Не закажувајте го преминувањето за последната недела од март: неуспешно преминување тогаш нема втор обид.

Ако наместо тоа почнувате во јануари, целосно откажете се од модернизацијата. Изберете ја целта што бара најмалку промени во кодот (App Service, Managed Instance или scale sets), преселете се и преработувајте потоа.

Што не е јасно

Microsoft вели дека услугата ќе биде „целосно повлечена“ и дека миграцијата е потребна „за да се избегне прекин на услугата“. Страниците што ги прочитавме не кажуваат што се случува со распоредување што сè уште работи на 1 април 2027. Не планирајте да откриете. Регионите и плановите на Managed Instance најверојатно исто така ќе се менуваат во наредните месеци, па потврдете ги кога одлучувате, а не од оваа статија.

Каде да побарате помош

Преземаме апликации што ги изградиле други, откриваме како работат и ги преселуваме: пописот, целта по улога, промените во RoleEnvironment и задачите за стартување, и преминувањето. Нашата работа на одржување наследени системи ги покрива .NET Framework и Web Forms; ако миграцијата ја прави вашиот тим и му требаат дополнителни раце, погледнете го зајакнувањето на тимот.

Ако имате распоредување на Cloud Services и датум за шест месеци, пишете ни на office@c9group.dev.