Azure Cloud Services (Extended Support) darbību beidz 2027. gada 31. martā: web un worker lomu pārcelšana

Microsoft 2025. gada 31. martā pasludināja Azure Cloud Services (extended support) par novecojušu un 2027. gada 31. martā to pilnībā izbeidz. Ja kāda no jūsu biznesa lietotnēm darbojas kā web lomas un worker lomas, līdz šim datumam tai jādarbojas kaut kur citur Azure. Darbības beigu BUJ ir tiešs par diviem jautājumiem, ko visi uzdod vispirms: Microsoft „can't grant extension requests“ (nevar piešķirt termiņa pagarinājumus), un „there's no one-click migration tooling available.“ (rīka migrācijai ar vienu klikšķi nav).

Šodien, 2026. gada 3. oktobrī, līdz tam atliek seši mēneši.

Kam šis raksts paredzēts

Tipiskais gadījums: ASP.NET lietotne uz .NET Framework, priekšā web loma un aiz tās viena vai divas worker lomas, kas apstrādā rindas, ko aģentūra izstrādāja pirms astoņiem vai desmit gadiem. Aģentūra bieži vien jau ir citur, lietotne joprojām apstrādā pasūtījumus vai uztur klientu portālu, un kopš pēdējās migrācijas neviens nav atvēris .csdef failu.

Lai pārbaudītu, vai tas attiecas uz jums, atveriet Azure portālu un uzskaitiet resursus ar tipu „Cloud services (extended support)“. Microsoft paziņojums par darbības beigām ved tieši uz šo skatu. Ja tas ir tukšs, jums nekas nav jādara.

Šis raksts nav par Cloud Services (classic), kas tika izbeigts 2024. gadā. Ja produktu jums mitina piegādātājs, migrācija ir viņa darbs: lūdziet viņa datumu rakstiski. Viss turpmākais ir komandām, kurām kods pieder, vai pieder uz papīra, un kurām jāatrod kāds, kas to saprot.

Kāpēc tas ir grūtāk nekā pārcelšanās 2024. gadā

Daudzi uzņēmumi pārgāja uz extended support 2024. gadā, kad classic tika izbeigts. Šī pāreja apzināti bija lēta. Microsoft extended support pārskatā teikts, ka faili .csdef, .cscfg un .cspkg „are carried forward and there's no change in the formats“ (tiek pārnesti, un formāti nemainās) un ka „No changes are required to runtime code“ (izpildlaika kodā izmaiņas nav vajadzīgas). Bija pat migrācija uz vietas. Tajā pašā lapā extended support tika ieteikts lietotnēm, kas vairs netiek attīstītas, jo „it provides a quick migration path.“ (tas nodrošina ātru migrācijas ceļu).

Šoreiz līdzvērtīga mērķa nav. Microsoft vārdiem, Cloud Services „is about deploying applications as VMs. The code you write is tightly coupled to a VM instance“ (ir par lietotņu izvietošanu kā virtuālajām mašīnām; jūsu rakstītais kods ir cieši saistīts ar VM instanci). Jūsu kods zina, ka darbojas lomā. Tas lasa konfigurāciju no lomas, atrod diska vietu caur lomu, saņem sertifikātus, ko uzstāda loma, un pirms lomas palaišanas izpilda iestatīšanas skriptus ar administratora tiesībām. Tas viss ir jāaizstāj.

Vēl viena lieta, pirms lasāt oficiālos norādījumus. Microsoft paziņojumā par darbības beigām un BUJ minēts viens galamērķis, Service Fabric managed cluster. Pārskata lapā uzskaitīti pieci, un paša Microsoft migrācijas lēmumu matrica salīdzina septiņus. Service Fabric ir noklusējums, nevis prasība, un daudzām web lomām tas ir nepareizais.

Mērķi un kad katrs der

Web un worker lomām nav jānonāk vienā vietā. Izvēlieties mērķi katrai lomai atsevišķi.

App Service (Windows). Tuvākais web lomas analogs ASP.NET lietotnei. Windows instancēs ir uzstādītas atbalstītās .NET Framework versijas, tāpēc Web Forms un MVC 5 darbojas bez pārrakstīšanas. Worker lomas var sekot kā WebJobs, kas darbojas „in the same instance as a web app“ (tajā pašā instancē, kur web lietotne) bez papildu maksas. Ierobežojums ir pati mašīna: lietotnes, kurām vajag COM komponentus, piekļuvi reģistram vai MSI instalētājus, Microsoft novirza uz Managed Instance, tāpēc standarta plānā paaugstināto tiesību palaišanas uzdevumiem nav kur palikt.

App Service Managed Instance. Radīts vecām Windows web lietotnēm. Saskaņā ar Microsoft pārskatu tas ir „generally available for Windows web apps in select regions“ (vispārēji pieejams Windows web lietotnēm atsevišķos reģionos), tikai ar Pv4 un Pmv4 plāniem, ar iepriekš uzstādītu .NET Framework 3.5 un 4.8 un PowerShell instalēšanas skriptiem, kas var reģistrēt COM komponentus, rakstīt reģistra atslēgas, palaist MSI instalētājus un konfigurēt IIS. Tas aptver lielāko daļu no tā, ko darīja paaugstināto tiesību palaišanas uzdevumi. Ierobežojumi: tikai web lietotnes (bez WebJobs), bez konteineriem, tikai Entra ID un pārvaldītā identitāte (bez pievienošanas domēnam, NTLM vai Kerberos), un šī raksta tapšanas brīdī vienīgais norādītais Eiropas reģions ir North Europe.

Container Apps. Labi piemērots worker lomām, tiklīdz tās ir uz mūsdienu .NET: mērogošana pēc rindas, plānoti un notikumu palaisti uzdevumi, mērogošana līdz nullei. Taču konteineru prasībās teikts: „Linux-based (linux/amd64) container images are required.“ (vajadzīgi uz Linux balstīti konteineru attēli). Kods uz .NET Framework tur nedarbojas, kamēr tas nav pārnests.

Azure Kubernetes Service. Darbina Windows Server konteinerus Windows mezglu pūlos, tāpēc .NET Framework lomu var ievietot konteinerā un pārcelt. Lēmumu matrica gan migrācijas sarežģītību, gan ekspluatācijas slodzi vērtē kā augstu. Tas der, ja jau darbināt Kubernetes, nevis kā pirmais klasteris vienai vecai lietotnei.

Virtual Machine Scale Sets. Matrica to sauc par „Closer to Cloud Services model, offering easier lift-and-shift“ (tuvāk Cloud Services modelim, ar vieglāku pārcelšanu bez izmaiņām). Jūs atgūstat VM, un kopā ar to ielāpu uzstādīšanu, attēlu būvēšanu un IIS iestatīšanu, ko agrāk jūsu vietā darīja loma.

Service Fabric managed cluster. Microsoft nosauktais galamērķis. Worker lomas uz to pārnesas tīri. Web lomas bieži ne: Service Fabric „does not support IIS“ (neatbalsta IIS), un konvertēšanas rokasgrāmatā ASP.NET Web Forms norādīts kā neatbalstīts, ar konvertēšanu uz ASP.NET Core MVC kā ceļu. Service Fabric migrācijas rokasgrāmata piebilst, ka pārvaldītie klasteri „currently do not support containers“ (pašlaik neatbalsta konteinerus), tāpēc no IIS atkarīgai lietotnei vajadzīgs tradicionāls klasteris, ar ko ir vairāk ekspluatācijas darba.

Lēmumu tabula

Kas mainās kodā

Meklējiet risinājumā Microsoft.WindowsAzure.ServiceRuntime. Katrs fails, kas to importē, ir sarakstā.

RoleEntryPoint

Worker loma ir klase, kas manto RoleEntryPoint un pārdefinē OnStart, Run un OnStop. Ja Run atgriežas, instance tiek pārstartēta. Service Fabric visas trīs apvieno vienā RunAsync, kam jāapstājas, „when the RunAsync method's CancellationToken is signaled“ (kad tiek signalizēts RunAsync metodes CancellationToken). App Service vai konteinerā tā pati loģika kļūst par konsoles lietotni vai mitinātu fona pakalpojumu ar ciklu un atcelšanas marķieri.

Daļa, ko cilvēki palaiž garām, ir izslēgšana. OnStop deva brīdi, lai pabeigtu apstrādājamo ziņojumu. Pārliecinieties, ka jaunais resursdators nodod tālāk atcelšanas signālu un ka ziņojumu, kura apstrāde pārtraukta pusceļā, var droši apstrādāt divreiz.

Arī web lomām bieži tāda ir, parasti WebRole.cs. Ja tās OnStart kaut ko dara (IIS pielāgojumi, kešatmiņas iesildīšana), noskaidrojiet, ko tieši, pirms to dzēšat.

RoleEnvironment

RoleEnvironment.GetConfigurationSettingValue("Key") nolasa iestatījumus no .cscfg. Ārpus Cloud Services to nenodrošina nekas. Pirms kaut ko pārceļat, ietiniet katru izsaukumu vienā nelielā konfigurācijas saskarnē, tad jaunajā resursdatorā novirziet šo saskarni uz lietotnes iestatījumiem, vides mainīgajiem vai Key Vault. Tā ir lētākā izmaiņa projektā, un tā ļauj pārējo testēt klēpjdatorā.

Vēl trīs lietojumi, ko meklēt:

• RoleEnvironment.Changed, kas piemēroja konfigurācijas izmaiņas bez pārstartēšanas. Service Fabric ir līdzvērtīgs notikums. Citur pieņemiet, ka iestatījuma maiņa pārstartē procesu, un pārbaudiet, ko tas nodara iesāktajam darbam.
• RoleEnvironment.CurrentRoleInstance, ko izmantoja, lai izvēlētos vienu instanci plānotajam darbam. Triggered WebJobs darbojas vienā instancē; continuous darbojas visās instancēs, ja vien nav ierobežoti. Izlemiet to apzināti.
• RoleEnvironment.IsAvailable un IsEmulated zari. Tie nodala „mākoņa“ ceļu no „lokālā“, un viens no tiem drīz kļūs par mirušu kodu.

.cscfg un .csdef

.cscfg satur katras vides iestatījumus, instanču skaitu un sertifikātu nospiedumus. .csdef satur galapunktus, VM izmēru, lokālo krātuvi, palaišanas uzdevumus, sertifikātu krātuves un dažreiz vairākas IIS vietnes vienā web lomā. Izejiet cauri abiem rindu pa rindai un pierakstiet, kur katrs ieraksts dzīvos pēc tam: lietotnes iestatījumā, Key Vault atsaucē, infrastruktūras kodā vai nekur. Iekšējiem galapunktiem, caur kuriem lomas tieši izsauc viena otru, vajadzīgs aizstājējs: pakalpojuma adrese vai rinda.

Sertifikāti

Extended support jau piespieda sertifikātus pārcelt uz Key Vault, tāpēc šī 2024. gada darba daļa atmaksājas. Mainās tas, kā kods tos atrod. .csdef uzstāda sertifikātus nosauktā krātuvē, bieži LocalMachine. Windows App Service iestatījums WEBSITE_LOAD_CERTIFICATES padara tos pieejamus krātuvē Current User\My. Kods, kas atver LocalMachine krātuvi, neko neatrod, un pirmais izsaukums, kuram vajag sertifikātu, neizdodas. Linux konteineros to tā vietā ielādējiet no Key Vault palaišanas brīdī.

Palaišanas uzdevumi

Atveriet Startup.cmd. Tur slēpjas pārsteigumi, parasti palaisti ar executionContext="elevated": fonti PDF ģenerēšanai, COM komponents, IIS pārrakstīšanas modulis, reģistra izmaiņa TLS vajadzībām. Katrai rindai ir trīs iespējamie likteņi: vairs nav vajadzīga, pārcelta uz instalēšanas skriptu Managed Instance vai iestrādāta konteinera vai VM attēlā.

Lokālā krātuve

LocalStorage resurss .csdef failā, ko nolasa caur RoleEnvironment.GetLocalResource, katrai instancei deva pagaidu disku. Īstiem pagaidu failiem izmantojiet platformas pagaidu direktoriju. Viss, kam jāpārdzīvo pārstartēšana, ieskaitot failus, ko kāds uzskatīja par pastāvīgiem, iet uz Blob Storage.

Web Forms

Šis ir lēmums, kas nosaka visu pārējo. Web Forms ir būvēts uz System.Web, un tam nav ASP.NET Core versijas, tāpēc Web Forms lietotnes pārcelšana uz Service Fabric vai Container Apps nozīmē tās lietotāja saskarnes pārrakstīšanu. App Service, Managed Instance, Windows konteiners vai scale set to visi var darbināt bez izmaiņām. Pārceliet to tādu, kāda tā ir, un modernizāciju padariet par atsevišķu projektu ar savu budžetu. Lietotāja saskarnes pārrakstīšanai nav vietas kritiskajā ceļā pirms izslēgšanas datuma.

Pārējais

VIP maiņa starp diviem mākoņpakalpojumiem kļūst par izvietošanas slotiem App Service vai revīzijām Container Apps. Žurnāliem, kas tika sūtīti caur diagnostikas (WAD) paplašinājumu, vajadzīgs jauns galamērķis, parasti Application Insights. Standarta App Service un Container Apps nepiedāvā attālo darbvirsmu; Managed Instance to atļauj caur Azure Bastion, tikai diagnostikai.

Sešu mēnešu plāns

Rēķinot atpakaļ no 2027. gada 31. marta, ar decembra svētkiem pa vidu.

Oktobris: inventarizācija un mērķa izvēle. Uzskaitiet katru extended support izvietojumu. Katrai lomai pierakstiet .NET Framework versiju, Web Forms vai MVC, katru RoleEnvironment izsaukumu, palaišanas uzdevumu, lokālās krātuves resursu, sertifikātu un galapunktu. Tad pārbaudiet neērto daļu: vai no jūsu rīcībā esošā pirmkoda varat uzbūvēt izvietoto pakotni? Aģentūru būvētām sistēmām atbilde dažreiz ir nē, un oktobris ir mēnesis, kad to noskaidrot. Izvēlieties mērķi katrai lomai.

Novembris: viena loma no sākuma līdz galam. Pievienojiet konfigurācijas ietvaru, aprakstiet mērķa vidi kā infrastruktūras kodu un panāciet, lai viena loma (parasti vienkāršākā worker loma) darbojas testa vidē ar žurnāliem, sertifikātiem un konveijeru.

Decembris un janvāris: pārnesiet pārējo. Aizstājiet ieejas punktus, palaišanas uzdevumus un lokālo krātuvi. Veiciet slodzes testu sagatavošanas vidē ar ražošanai līdzīgiem datiem: WebJob vai konteiners var neatbilst atvēlētas lomas VM caurlaidspējai.

Februāris: paralēla darbība. Darbiniet jauno vidi ar reālu datplūsmu. Worker lomām, kas dala rindu ar vecajām lomām, vai nu vispirms padariet apstrādi idempotentu, vai apturiet vecās worker lomas, pirms palaižat jaunās.

Marta sākums: pārslēgšana. Pārslēdziet DNS ar laika rezervi. Veco izvietojumu nedēļu vai divas paturiet apturētu, bet neskartu, tad dzēsiet. Neplānojiet pārslēgšanu uz marta pēdējo nedēļu: tad neizdevusies pārslēgšana vairs nedod otru mēģinājumu.

Ja sākat tikai janvārī, modernizāciju atmetiet pavisam. Izvēlieties mērķi, kam vajag vismazāk koda izmaiņu (App Service, Managed Instance vai scale sets), pārceliet un pārveidojiet pēc tam.

Kas nav skaidrs

Microsoft saka, ka pakalpojums būs „fully retired“ (pilnībā izbeigts) un ka migrācija vajadzīga, „to avoid service disruption“ (lai izvairītos no pakalpojuma traucējumiem). Lapās, ko lasījām, nav teikts, kas notiks ar izvietojumu, kas vēl darbosies 2027. gada 1. aprīlī. Neplānojiet to noskaidrot. Arī Managed Instance reģioni un plāni tuvākajos mēnešos, visticamāk, mainīsies, tāpēc pārbaudiet tos lēmuma brīdī, nevis pēc šī raksta.

Kur saņemt palīdzību

Mēs pārņemam citu cilvēku būvētas lietotnes, noskaidrojam, kā tās darbojas, un pārceļam tās: inventarizācija, mērķis katrai lomai, RoleEnvironment un palaišanas uzdevumu izmaiņas un pārslēgšana. Mūsu mantoto sistēmu uzturēšanas darbs aptver .NET Framework un Web Forms; ja migrāciju veic jūsu pašu komanda un tai vajadzīgas papildu rokas, skatiet komandas papildināšanu.

Ja jums ir Cloud Services izvietojums un datums pēc sešiem mēnešiem, rakstiet uz office@c9group.dev.