Azure Cloud Services (Extended Support) se ukine 31. marca 2027: selitev spletnih in delovnih vlog

Microsoft je Azure Cloud Services (extended support) opustil 31. marca 2025 in ga bo v celoti ukinil 31. marca 2027. Če vaša poslovna aplikacija teče kot spletne vloge (web roles) in delovne vloge (worker roles), mora pred tem datumom teči nekje drugje v Azure. Pogosta vprašanja o ukinitvi so neposredna glede dveh vprašanj, ki jih vsi zastavijo najprej: Microsoft „ne more odobriti zahtev za podaljšanje“ in „orodja za selitev z enim klikom ni“.

Od danes, 3. oktobra 2026, je to šest mesecev.

Za koga je to

Tipičen primer: aplikacija ASP.NET na .NET Framework, spredaj spletna vloga, zadaj ena ali dve delovni vlogi, ki obdelujeta vrste, zgradila pa jo je agencija pred osmimi ali desetimi leti. Agencija je pogosto že šla naprej, aplikacija še vedno poganja obdelavo naročil ali portal za stranke, datoteke .csdef pa od zadnje selitve ni odprl nihče.

Da preverite, ali ste prizadeti, odprite portal Azure in izpišite vire vrste „Cloud services (extended support)“. Microsoftovo obvestilo o ukinitvi povezuje naravnost na ta pogled. Če je prazen, ste opravili.

Ta članek ne govori o Cloud Services (classic), ki je bil ukinjen leta 2024. Če izdelek za vas gosti ponudnik, je selitev njegova naloga: zahtevajte njegov datum v pisni obliki. Vse spodaj je za ekipe, ki so lastnice kode ali so njene lastnice na papirju in morajo poiskati nekoga, ki jo razume.

Zakaj je to težje kot selitev leta 2024

Mnoga podjetja so leta 2024, ko je bil classic ukinjen, prešla na extended support. Ta prehod je bil po zasnovi poceni. Microsoftov pregled extended support pravi, da se datoteke .csdef, .cscfg in .cspkg „prenesejo naprej brez sprememb formatov“ in da „sprememb kode za izvajanje ni treba delati“. Obstajala je celo selitev na mestu. Ista stran je extended support predlagala za aplikacije, ki se ne razvijajo, ker „zagotavlja hitro pot selitve“.

Tokrat cilja, ki bi bil enakovreden, ni. Po Microsoftovih besedah je Cloud Services „namenjen nameščanju aplikacij kot navideznih strojev. Koda, ki jo napišete, je tesno povezana z instanco navideznega stroja“. Vaša koda ve, da teče v vlogi. Konfiguracijo bere iz vloge, prostor na disku najde prek vloge, potrdila ji namesti vloga, pred zagonom vloge pa kot skrbnik poganja nastavitvene skripte. Vse to je treba nadomestiti.

Še ena stvar, preden preberete uradna navodila. Microsoftovo obvestilo o ukinitvi in pogosta vprašanja navajajo en cilj, Service Fabric managed cluster. Stran s pregledom jih navaja pet, Microsoftova lastna matrika odločanja za selitev pa jih primerja sedem. Service Fabric je privzeta izbira, ne zahteva, in za veliko spletnih vlog je napačna.

Cilji in kdaj kateri ustreza

Spletne in delovne vloge ne rabijo pristati na istem mestu. Cilj izberite za vsako vlogo posebej.

App Service (Windows). Najbližje spletni vlogi za aplikacijo ASP.NET. Instance Windows imajo nameščene podprte različice .NET Framework, zato Web Forms in MVC 5 tečeta brez ponovnega pisanja. Delovne vloge lahko sledijo kot WebJobs, ki tečejo „v isti instanci kot spletna aplikacija“ brez dodatnih stroškov. Meja je sam stroj: Microsoft aplikacije, ki potrebujejo komponente COM, dostop do registra ali namestitvene programe MSI, usmerja na Managed Instance, zato zagonska opravila s povišanimi pravicami na standardnem paketu nimajo kam.

App Service Managed Instance. Zgrajen za starejše spletne aplikacije Windows. Po Microsoftovem pregledu je „splošno na voljo za spletne aplikacije Windows v izbranih regijah“, omejen na paketa Pv4 in Pmv4, s prednameščenima .NET Framework 3.5 in 4.8 ter namestitvenimi skriptami PowerShell, ki lahko registrirajo komponente COM, pišejo ključe v register, poganjajo namestitvene programe MSI in konfigurirajo IIS. To pokrije večino tega, kar so počela zagonska opravila s povišanimi pravicami. Omejitve: samo spletne aplikacije (brez WebJobs), brez vsebnikov, samo Entra ID in upravljana identiteta (brez pridružitve domeni, NTLM ali Kerberos), v času pisanja pa je edina navedena evropska regija North Europe.

Container Apps. Dobra izbira za delovne vloge, ko so enkrat na sodobnem .NET: skaliranje glede na vrste, načrtovana in z dogodki sprožena opravila, skaliranje na nič. Toda zahteve za vsebnike pravijo, da so „potrebne slike vsebnikov za Linux (linux/amd64)“. Koda na .NET Framework tam ne teče, dokler ni prenesena.

Azure Kubernetes Service. Poganja vsebnike Windows Server v naborih vozlišč Windows, zato je vlogo na .NET Framework mogoče zapakirati v vsebnik in preseliti. Matrika odločanja tako zahtevnost selitve kot obremenitev z upravljanjem ocenjuje kot visoko. Ustreza, če Kubernetes že uporabljate, ne pa kot prva gruča za eno starejšo aplikacijo.

Virtual Machine Scale Sets. Matrika ga opisuje kot „bližje modelu Cloud Services, z lažjim prenosom brez sprememb (lift-and-shift)“. Navidezni stroj dobite nazaj, skupaj s posodabljanjem, gradnjo slik in nastavitvijo IIS, ki jih je prej opravljala vloga.

Service Fabric managed cluster. Microsoftov imenovani cilj. Delovne vloge se nanj preslikajo čisto. Spletne vloge pogosto ne: Service Fabric „ne podpira IIS“, vodnik za pretvorbo pa ASP.NET Web Forms navaja kot nepodprt, pot pa je pretvorba v ASP.NET Core MVC. Vodnik za selitev na Service Fabric dodaja, da upravljane gruče „trenutno ne podpirajo vsebnikov“, zato aplikacija, odvisna od IIS, potrebuje klasično gručo, ki zahteva več upravljanja.

Tabela za odločanje

Kaj se spremeni v kodi

V rešitvi poiščite Microsoft.WindowsAzure.ServiceRuntime. Vsaka datoteka, ki ga uvaža, je na seznamu.

RoleEntryPoint

Delovna vloga je razred, ki deduje od RoleEntryPoint in preglasi OnStart, Run in OnStop. Če Run vrne, se instanca ponovno zažene. Service Fabric vse tri združi v en sam RunAsync, ki naj se ustavi, „ko je signaliziran CancellationToken metode RunAsync“. V App Service ali v vsebniku ista logika postane konzolna aplikacija ali gostovana storitev v ozadju z zanko in žetonom za preklic.

Del, ki ga ljudje spregledajo, je zaustavitev. OnStop vam je dal trenutek, da dokončate sporočilo, ki ste ga obdelovali. Poskrbite, da novi gostitelj signal za preklic posreduje naprej in da je sporočilo, opuščeno sredi obdelave, varno obdelati dvakrat.

Spletne vloge ga imajo pogosto tudi same, običajno WebRole.cs. Če njegov OnStart kaj počne (prilagoditve IIS, ogrevanje predpomnilnika), ugotovite kaj, preden ga izbrišete.

RoleEnvironment

RoleEnvironment.GetConfigurationSettingValue("Key") bere nastavitve iz .cscfg. Zunaj Cloud Services ga ne zagotavlja nič. Preden karkoli preselite, vsak klic ovijte v en majhen konfiguracijski vmesnik, nato pa ta vmesnik na novem gostitelju usmerite na nastavitve aplikacije, okoljske spremenljivke ali Key Vault. To je najcenejša sprememba v projektu in omogoči, da ostalo testirate na prenosniku.

Poiščite še tri druge uporabe:

• RoleEnvironment.Changed, ki je spremembe konfiguracije uveljavil brez ponovnega zagona. Service Fabric ima enakovreden dogodek. Drugje predpostavite, da sprememba nastavitve ponovno zažene proces, in preizkusite, kaj to naredi z delom, ki je v teku.
• RoleEnvironment.CurrentRoleInstance, ki se je uporabljal za izbiro ene instance za načrtovana opravila. Sproženi WebJobs tečejo na eni instanci; neprekinjeni tečejo na vseh instancah, razen če so omejeni. Odločite izrecno.
• Vejitve RoleEnvironment.IsAvailable in IsEmulated. Te ločujejo pot „v oblaku“ od „lokalne“ poti, ena od njiju pa bo kmalu postala mrtva koda.

.cscfg in .csdef

.cscfg vsebuje nastavitve za posamezna okolja, število instanc in prstne odtise potrdil. .csdef vsebuje končne točke, velikost navideznega stroja, lokalni pomnilnik, zagonska opravila, shrambe potrdil in včasih več spletnih mest IIS znotraj ene spletne vloge. Obe preglejte vrstico za vrstico in zapišite, kje bo vsak vnos živel pozneje: v nastavitvi aplikacije, v sklicu na Key Vault, v infrastrukturni kodi ali nikjer. Notranje končne točke, prek katerih vloge kličejo neposredno druga drugo, potrebujejo nadomestilo, bodisi naslov storitve bodisi vrsto.

Potrdila

Extended support je potrdila že prisilil v Key Vault, zato se ta del dela iz leta 2024 izplača. Spremeni pa se, kako jih najde koda. .csdef potrdila namesti v imenovano shrambo, pogosto LocalMachine. V App Service za Windows jih nastavitev WEBSITE_LOAD_CERTIFICATES da na voljo v Current User\My. Koda, ki odpre shrambo LocalMachine, ne najde ničesar, prvi klic, ki potrebuje potrdilo, pa odpove. V vsebnikih Linux ga namesto tega ob zagonu naložite iz Key Vault.

Zagonska opravila

Odprite Startup.cmd. Tu živijo presenečenja, običajno zagnana z executionContext="elevated": pisave za ustvarjanje PDF, komponenta COM, modul IIS za prepisovanje, sprememba registra za TLS. Vsaka vrstica ima tri možne usode: ni več potrebna, preseli se v namestitveno skripto na Managed Instance ali pa se vgradi v sliko vsebnika ali navideznega stroja.

Lokalni pomnilnik

Vir LocalStorage v .csdef, ki se bere prek RoleEnvironment.GetLocalResource, je vsaki instanci dal začasni disk. Za prave začasne datoteke uporabite začasni imenik platforme. Vse, kar mora preživeti ponovni zagon, vključno z datotekami, za katere je nekdo domneval, da so trajne, gre v Blob Storage.

Web Forms

To je odločitev, ki poganja vse ostalo. Web Forms temelji na System.Web in nima različice za ASP.NET Core, zato selitev aplikacije Web Forms na Service Fabric ali Container Apps pomeni ponovno pisanje njenega uporabniškega vmesnika. App Service, Managed Instance, vsebnik Windows ali nabor za skaliranje jo lahko poganjajo nespremenjeno. Preselite jo, kakršna je, posodobitev pa naj bo ločen projekt z lastnim proračunom. Ponovno pisanje uporabniškega vmesnika ne sodi na kritično pot roka za izklop.

Ostalo

Zamenjava VIP med dvema oblačnima storitvama postane umestitvene reže (deployment slots) v App Service ali revizije v Container Apps. Dnevniki, poslani prek razširitve za diagnostiko (WAD), potrebujejo nov cilj, običajno Application Insights. Standardni App Service in Container Apps ne ponujata oddaljenega namizja; Managed Instance ga dovoljuje prek Azure Bastion, le za diagnostiko.

Šestmesečni načrt

Šteto nazaj od 31. marca 2027, z decembrskimi prazniki vmes.

Oktober: popis in izbira cilja. Naštejte vse namestitve extended support. Za vsako vlogo zabeležite različico .NET Framework, Web Forms ali MVC, vsak klic RoleEnvironment, zagonsko opravilo, vir lokalnega pomnilnika, potrdilo in končno točko. Nato preverite neprijetni del: ali lahko nameščeni paket zgradite iz izvorne kode, ki jo imate? Pri sistemih, ki jih je zgradila agencija, je odgovor včasih ne, oktober pa je mesec, da to ugotovite. Za vsako vlogo izberite cilj.

November: ena vloga, od začetka do konca. Dodajte konfiguracijski ovoj, ciljno okolje zapišite kot infrastrukturno kodo in eno vlogo (običajno najpreprostejšo delovno) spravite v delovanje v testnem okolju, z dnevniki, potrdili in cevovodom.

December in januar: prenos preostalega. Zamenjajte vstopne točke, zagonska opravila in lokalni pomnilnik. Obremenitveno preizkusite testno okolje s podatki, podobnimi produkcijskim: WebJob ali vsebnik morda ne doseže prepustnosti namenskega navideznega stroja za vlogo.

Februar: vzporedno delovanje. Novo okolje poganjajte z resničnim prometom. Pri delovnih vlogah, ki si vrsto delijo s starimi vlogami, obdelavo najprej naredite idempotentno ali pa stare delovne vloge ustavite, preden zaženete nove.

Začetek marca: prehod. DNS preklopite z dovolj časovne rezerve. Staro namestitev za teden ali dva pustite ustavljeno, a nedotaknjeno, nato jo izbrišite. Prehoda ne načrtujte za zadnji teden marca: neuspešen prehod takrat nima drugega poskusa.

Če namesto tega začenjate januarja, posodobitev v celoti opustite. Izberite cilj, ki zahteva najmanj sprememb kode (App Service, Managed Instance ali nabore za skaliranje), preselite in preoblikujte pozneje.

Kaj ni jasno

Microsoft pravi, da bo storitev „v celoti ukinjena“ in da je selitev potrebna, „da se izognete motnjam v delovanju storitve“. Strani, ki smo jih prebrali, ne povedo, kaj se zgodi z namestitvijo, ki bo 1. aprila 2027 še tekla. Ne računajte na to, da boste to ugotovili. Regije in paketi za Managed Instance se bodo v prihodnjih mesecih verjetno tudi spreminjali, zato jih potrdite ob odločitvi, ne iz tega članka.

Kje dobiti pomoč

Prevzemamo aplikacije, ki so jih zgradili drugi, ugotovimo, kako tečejo, in jih preselimo: popis, cilj za vsako vlogo, spremembe RoleEnvironment in zagonskih opravil ter prehod. Naše delo na vzdrževanju podedovanih sistemov pokriva .NET Framework in Web Forms; če selitev izvaja vaša ekipa in potrebuje dodatne roke, si oglejte kadrovsko okrepitev.

Če imate namestitev Cloud Services in rok čez šest mesecev, pišite na office@c9group.dev.