Azure Cloud Services (Extended Support) спира на 31 март 2027 г.: как да преместите уеб и работните роли

Microsoft обяви Azure Cloud Services (extended support) за остаряла услуга на 31 март 2025 г. и я спира окончателно на 31 март 2027 г. Ако някое ваше бизнес приложение работи като уеб роли (web roles) и работни роли (worker roles), то трябва да работи някъде другаде в Azure преди тази дата. Често задаваните въпроси за спирането отговарят направо на двата въпроса, които всеки задава първо: Microsoft „can't grant extension requests" (не може да удовлетворява искания за удължаване) и „there's no one-click migration tooling available" (няма инструмент за миграция с едно щракване).

Днес, 3 октомври 2026 г., това означава, че остават шест месеца.

За кого е тази статия

Типичният случай: ASP.NET приложение на .NET Framework, с уеб роля отпред и една или две работни роли отзад, които обработват опашки, изградено от агенция преди осем или десет години. Агенцията често вече не е в картината, приложението все още обслужва обработката на поръчки или клиентски портал, а никой не е отварял файла .csdef от последната миграция насам.

За да проверите дали ви засяга, отворете портала на Azure и потърсете ресурси от вида „Cloud services (extended support)". Известието на Microsoft за спирането води директно към този изглед. Ако списъкът е празен, приключихте.

Статията не се отнася до Cloud Services (classic), спряна през 2024 г. Ако доставчик хоства продукта вместо вас, миграцията е негова работа: поискайте датата му писмено. Всичко по-долу е за екипи, които притежават кода или го притежават на хартия и трябва да намерят някой, който го разбира.

Защо този път е по-трудно, отколкото през 2024 г.

Много компании преминаха към extended support през 2024 г., когато classic беше спряна. Този преход по замисъл беше евтин. Общият преглед на extended support на Microsoft посочва, че файловете .csdef, .cscfg и .cspkg „are carried forward and there's no change in the formats" (се пренасят и форматите им не се променят) и че „No changes are required to runtime code" (не са нужни промени в кода по време на изпълнение). Имаше дори миграция на място. Същата страница препоръчваше extended support за приложения, които не се развиват, защото „it provides a quick migration path" (предлага бърз път за миграция).

Този път няма равностойна целева платформа. По думите на Microsoft Cloud Services „is about deploying applications as VMs. The code you write is tightly coupled to a VM instance" (е внедряване на приложения като виртуални машини; кодът, който пишете, е тясно свързан с инстанция на виртуална машина). Вашият код знае, че работи в роля. Той чете конфигурацията от ролята, намира дисково пространство чрез ролята, получава сертификати, инсталирани от ролята, и изпълнява скриптове за настройка като администратор, преди ролята да стартира. Всичко това трябва да бъде заменено.

Още нещо, преди да прочетете официалните указания. Известието и често задаваните въпроси на Microsoft посочват една цел, Service Fabric managed cluster. Страницата с общия преглед изброява пет, а собствената матрица за избор при миграция на Microsoft сравнява седем. Service Fabric е избор по подразбиране, а не изискване, и за много уеб роли е погрешният.

Целевите платформи и кога е подходяща всяка от тях

Уеб и работните роли не е задължително да попаднат на едно и също място. Изберете цел за всяка роля поотделно.

App Service (Windows). Най-близкото до уеб роля за ASP.NET приложение. Инстанциите с Windows идват с инсталирани поддържани версии на .NET Framework, така че Web Forms и MVC 5 работят без пренаписване. Работните роли могат да ги последват като WebJobs, които работят „in the same instance as a web app" (в същата инстанция като уеб приложението) без допълнителни разходи. Ограничението е самата машина: Microsoft насочва приложенията, които се нуждаят от COM компоненти, достъп до регистъра или MSI инсталатори, към Managed Instance, така че стартовите задачи с повишени права нямат къде да отидат в стандартен план.

App Service Managed Instance. Създадена за стари уеб приложения за Windows. Според общия преглед на Microsoft тя е „generally available for Windows web apps in select regions" (общодостъпна за уеб приложения за Windows в избрани региони), ограничена до плановете Pv4 и Pmv4, с предварително инсталирани .NET Framework 3.5 и 4.8 и инсталационни скриптове на PowerShell, които могат да регистрират COM компоненти, да записват ключове в регистъра, да изпълняват MSI инсталатори и да конфигурират IIS. Това покрива повечето от онова, което правеха стартовите задачи с повишени права. Ограниченията: само уеб приложения (без WebJobs), без контейнери, само Entra ID и управлявана идентичност (без присъединяване към домейн, без NTLM и Kerberos), а към момента на писане единственият посочен европейски регион е North Europe.

Container Apps. Подходяща за работни роли, след като са преминали на съвременен .NET: мащабиране според опашката, планирани задачи и задачи, задействани от събития, мащабиране до нула. Но изискванията за контейнерите гласят: „Linux-based (linux/amd64) container images are required" (изискват се образи на контейнери за Linux, linux/amd64). Код на .NET Framework не работи там, докато не бъде пренесен.

Azure Kubernetes Service. Изпълнява контейнери с Windows Server в пулове от възли с Windows, така че роля на .NET Framework може да се контейнеризира и премести. Матрицата оценява и сложността на миграцията, и оперативната ѝ тежест като високи. Подходящо е, ако вече използвате Kubernetes, но не и като първи клъстер заради едно старо приложение.

Virtual Machine Scale Sets. Матрицата го описва като „Closer to Cloud Services model, offering easier lift-and-shift" (по-близо до модела на Cloud Services, с по-лесно пренасяне без промени). Получавате обратно виртуалната машина, заедно с актуализациите, изграждането на образи и настройката на IIS, които ролята преди вършеше вместо вас.

Service Fabric managed cluster. Целта, която Microsoft посочва. Работните роли се пренасят върху нея чисто. Уеб ролите често не: Service Fabric „does not support IIS" (не поддържа IIS), а ръководството за преобразуване посочва ASP.NET Web Forms като неподдържана технология, с преобразуване към ASP.NET Core MVC като решение. Ръководството за миграция към Service Fabric добавя, че управляваните клъстери „currently do not support containers" (засега не поддържат контейнери), така че приложение, зависимо от IIS, изисква традиционен клъстер, който се поддържа по-трудно.

Таблица за избор

Какво се променя в кода

Потърсете в решението Microsoft.WindowsAzure.ServiceRuntime. Всеки файл, който го импортира, влиза в списъка.

RoleEntryPoint

Работната роля е клас, който наследява RoleEntryPoint и предефинира OnStart, Run и OnStop. Ако Run върне управлението, инстанцията се рестартира. Service Fabric обединява трите в един RunAsync, който трябва да спре, „when the RunAsync method's CancellationToken is signaled" (когато бъде подаден сигнал чрез CancellationToken на метода RunAsync). В App Service или в контейнер същата логика се превръща в конзолно приложение или хоствана фонова услуга с цикъл и токен за прекратяване.

Частта, която хората пропускат, е спирането. OnStop ви даваше момент да довършите съобщението, което се обработва. Уверете се, че новият хост предава сигнал за прекратяване и че съобщение, изоставено по средата на обработката, може безопасно да се обработи два пъти.

Уеб ролите често също имат такъв клас, обикновено WebRole.cs. Ако неговият OnStart прави нещо (настройки на IIS, загряване на кеша), разберете какво, преди да го изтриете.

RoleEnvironment

RoleEnvironment.GetConfigurationSettingValue("Key") чете настройки от .cscfg. Извън Cloud Services нищо не го предоставя. Преди да местите каквото и да е, обвийте всяко извикване в един малък конфигурационен интерфейс, след което насочете този интерфейс към настройките на приложението, променливи на средата или Key Vault на новия хост. Това е най-евтината промяна в проекта и прави останалото възможно за тестване на лаптоп.

Три други употреби, които да потърсите:

• RoleEnvironment.Changed, който прилагаше промени в конфигурацията без рестартиране. Service Fabric има еквивалентно събитие. Другаде приемете, че промяна в настройка рестартира процеса, и тествайте какво става с работата, която е в ход.
• RoleEnvironment.CurrentRoleInstance, използван за избор на една инстанция за планираната работа. Задействаните WebJobs работят на една инстанция; непрекъснатите работят на всички инстанции, освен ако не са ограничени. Решете това изрично.
• Разклонения с RoleEnvironment.IsAvailable и IsEmulated. Те разделят пътя „в облака" от „локалния" път и единият от тях скоро ще стане мъртъв код.

.cscfg и .csdef

.cscfg съдържа настройките за всяка среда, броя на инстанциите и отпечатъците (thumbprints) на сертификатите. .csdef съдържа крайните точки, размера на виртуалната машина, локалното хранилище, стартовите задачи, хранилищата за сертификати, а понякога и няколко IIS сайта в една уеб роля. Минете през двата файла ред по ред и запишете къде ще живее всеки запис след това: настройка на приложението, препратка към Key Vault, инфраструктурен код или никъде. Вътрешните крайни точки, през които ролите се извикват директно една друга, имат нужда от заместител, било то адрес на услуга или опашка.

Сертификати

Extended support вече наложи сертификатите да са в Key Vault, така че тази част от работата през 2024 г. сега се отплаща. Променя се начинът, по който кодът ги намира. .csdef инсталира сертификатите в именувано хранилище, често LocalMachine. В App Service за Windows настройката 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 между две облачни услуги се заменя със слотове за внедряване (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, стартова задача, ресурс за локално хранилище, сертификат и крайна точка. След това проверете неудобната част: можете ли да изградите внедрения пакет от наличния изходен код? При системи, изградени от агенции, отговорът понякога е „не", а октомври е месецът, в който да разберете това. Изберете цел за всяка роля.

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

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

Февруари: паралелна работа. Пуснете новата среда срещу реален трафик. При работни процеси, които делят опашка със старите роли, или първо направете обработката идемпотентна, или спрете старите работни процеси, преди да стартирате новите.

Началото на март: превключване. Сменете DNS с резерв от време. Дръжте старото внедряване спряно, но непокътнато, седмица или две, след което го изтрийте. Не планирайте превключването за последната седмица на март: тогава неуспешното превключване няма втори опит.

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

Какво не е ясно

Microsoft казва, че услугата ще бъде „fully retired" (напълно спряна) и че миграцията е нужна „to avoid service disruption" (за да се избегне прекъсване на услугата). Страниците, които прочетохме, не казват какво става с внедряване, което все още работи на 1 април 2027 г. Не планирайте да го разберете на практика. Регионите и плановете на Managed Instance също вероятно ще се променят през следващите месеци, затова ги потвърдете, когато вземате решение, а не по тази статия.

Откъде да получите помощ

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

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