Az Azure Cloud Services (Extended Support) 2027. március 31-én megszűnik: webes és feldolgozói szerepkörök költöztetése

A Microsoft 2025. március 31-én elavulttá nyilvánította az Azure Cloud Servicest (bővített támogatás), és 2027. március 31-én teljesen kivezeti. Ha egy üzleti alkalmazása webes szerepkörökként (web role) és feldolgozói szerepkörökként (worker role) fut, ezen dátum előtt az Azure-on belül máshol kell futnia. A kivezetésről szóló GYIK egyenesen válaszol a két kérdésre, amelyet mindenki elsőként feltesz: a Microsoft „nem tud hosszabbítási kérelmeket teljesíteni”, és „nem áll rendelkezésre egykattintásos migrációs eszköz.”

Mától, 2026. október 3-ától ez hat hónapot jelent.

Kinek szól ez a cikk

A tipikus eset: egy .NET Frameworkön futó ASP.NET-alkalmazás, elöl egy webes szerepkörrel, mögötte egy-két feldolgozói szerepkörrel, amelyek sorokat dolgoznak fel, és amelyet egy ügynökség épített nyolc-tíz évvel ezelőtt. Az ügynökség gyakran már továbbállt, az alkalmazás még mindig rendelésfeldolgozást vagy ügyfélportált futtat, és a legutóbbi migráció óta senki nem nyitotta meg a .csdef fájlt.

Ha ellenőrizni szeretné, hogy érintett-e, nyissa meg az Azure Portalt, és listázza a „Cloud services (extended support)” típusú erőforrásokat. A Microsoft kivezetési értesítése közvetlenül erre a nézetre hivatkozik. Ha üres, végzett.

Ez a cikk nem a Cloud Services (classic) szolgáltatásról szól, amelyet 2024-ben vezettek ki. Ha a terméket egy szoftverszállító üzemelteti Ön helyett, a migráció az ő dolga: kérje írásban a dátumát. Minden, ami ezután következik, azoknak a csapatoknak szól, amelyeké a kód, vagy papíron az övék, és találniuk kell valakit, aki érti.

Miért nehezebb ez, mint a 2024-es költözés

Sok cég 2024-ben, a classic kivezetésekor állt át a bővített támogatásra. Az a költözés szándékosan olcsó volt. A Microsoft bővített támogatásról szóló áttekintése szerint a .csdef, a .cscfg és a .cspkg fájlok „változatlanul átvihetők, a formátumuk nem változik”, és „a futásidejű kódon nem kell változtatni”. Még helyben történő migráció is volt. Ugyanez az oldal a nem fejlődő alkalmazásokhoz javasolta a bővített támogatást, mert „gyors migrációs utat biztosít”.

Ezúttal nincs egyenértékű cél. A Microsoft szavaival a Cloud Services „virtuális gépekként történő alkalmazástelepítésről szól. Az Ön által írt kód szorosan kötődik egy VM-példányhoz”. A kódja tudja, hogy egy szerepkörben fut. A szerepkörből olvassa a konfigurációt, a szerepkörön keresztül talál lemezterületet, a tanúsítványokat a szerepkör telepíti neki, és a szerepkör indulása előtt rendszergazdaként futtat telepítő szkripteket. Mindezt le kell cserélni.

Még egy dolog, mielőtt elolvassa a hivatalos útmutatást. A Microsoft kivezetési értesítése és GYIK-ja egyetlen célt nevez meg, a Service Fabric felügyelt fürtöt (managed cluster). Az áttekintő oldal ötöt sorol fel, a Microsoft saját migrációs döntési mátrixa pedig hetet hasonlít össze. A Service Fabric alapértelmezés, nem követelmény, és sok webes szerepkörnél rossz választás.

A célok, és mikor melyik illik

A webes és a feldolgozói szerepköröknek nem kell ugyanoda kerülniük. Szerepkörönként válasszon célt.

App Service (Windows). Egy ASP.NET-alkalmazásnál ez áll a legközelebb a webes szerepkörhöz. A Windows-példányokon a támogatott .NET Framework-verziók telepítve vannak, így a Web Forms és az MVC 5 újraírás nélkül fut. A feldolgozói szerepkörök WebJobként követhetik, amelyek „ugyanabban a példányban futnak, mint a webalkalmazás”, külön költség nélkül. A korlátot maga a gép jelenti: a COM-komponenseket, registry-hozzáférést vagy MSI-telepítőket igénylő alkalmazásokat a Microsoft a Managed Instance felé tereli, így a megemelt jogosultságú indítási feladatoknak egy standard csomagban nincs hová menniük.

App Service Managed Instance. Régi Windows-webalkalmazásokhoz készült. A Microsoft áttekintése szerint „egyes régiókban általánosan elérhető Windows-webalkalmazásokhoz”, a Pv4 és Pmv4 csomagokra korlátozva, előre telepített .NET Framework 3.5-tel és 4.8-cal, valamint olyan PowerShell-telepítőszkriptekkel, amelyek COM-komponenseket regisztrálhatnak, registry-kulcsokat írhatnak, MSI-telepítőket futtathatnak és beállíthatják az IIS-t. Ez lefedi a legtöbbet abból, amit a megemelt jogosultságú indítási feladatok végeztek. A korlátok: csak webalkalmazások (nincs WebJob), nincsenek konténerek, csak Entra ID és felügyelt identitás (nincs tartományhoz csatlakozás, NTLM vagy Kerberos), és e cikk írásakor az egyetlen felsorolt európai régió a North Europe.

Container Apps. Jó választás a feldolgozói szerepköröknek, ha már modern .NET-en futnak: sorvezérelt skálázás, ütemezett és eseményindítású feladatok, nullára skálázás. A konténerkövetelmények azonban kimondják: „Linux-alapú (linux/amd64) konténerképekre van szükség.” A .NET Frameworkön futó kód addig nem fut ott, amíg át nem portolják.

Azure Kubernetes Service. Windows Server-konténereket futtat Windows-csomópontkészletekben, így egy .NET Framework-alapú szerepkör konténerizálható és átköltöztethető. A döntési mátrix a migráció összetettségét és az üzemeltetési terhet is magasra értékeli. Akkor illik, ha már futtat Kubernetest, nem első fürtnek egyetlen régi alkalmazáshoz.

Virtual Machine Scale Sets. A mátrix szerint „közelebb áll a Cloud Services modelljéhez, egyszerűbb lift-and-shift költözést kínál”. Visszakapja a virtuális gépet, a javításokkal, a lemezkép-készítéssel és az IIS beállításával együtt, amelyeket korábban a szerepkör végzett el Ön helyett.

Service Fabric felügyelt fürt. A Microsoft által megnevezett cél. A feldolgozói szerepkörök tisztán leképezhetők rá. A webes szerepkörök gyakran nem: a Service Fabric „nem támogatja az IIS-t”, az átalakítási útmutató pedig nem támogatottként sorolja fel az ASP.NET Web Formst, és az ASP.NET Core MVC-re való átalakítást jelöli meg útként. A Service Fabric migrációs útmutatója hozzáteszi, hogy a felügyelt fürtök „jelenleg nem támogatják a konténereket”, így egy IIS-függő alkalmazásnak hagyományos fürt kell, több üzemeltetési teherrel.

Döntési táblázat

Mi változik a kódban

Keressen rá a megoldásban a Microsoft.WindowsAzure.ServiceRuntime névtérre. Minden fájl, amely importálja, a listára kerül.

RoleEntryPoint

Egy feldolgozói szerepkör egy osztály, amely a RoleEntryPoint osztályból öröklődik, és felülírja az OnStart, a Run és az OnStop metódust. Ha a Run visszatér, a példány újraindul. A Service Fabric mindhármat egyetlen RunAsync metódusba vonja össze, amelynek le kell állnia, „amikor a RunAsync metódus CancellationTokenje jelez”. App Service-en vagy konténerben ugyanez a logika konzolalkalmazás vagy hosztolt háttérszolgáltatás lesz, egy ciklussal és egy megszakítási tokennel.

Amit az emberek elfelejtenek, az a leállítás. Az OnStop adott egy pillanatot arra, hogy befejezze a kezében lévő üzenetet. Gondoskodjon róla, hogy az új hoszt továbbítsa a megszakítási jelzést, és hogy a feldolgozás közben félbehagyott üzenetet biztonságosan fel lehessen dolgozni kétszer is.

A webes szerepköröknek is gyakran van ilyenje, jellemzően a WebRole.cs. Ha az OnStart metódusa bármit csinál (IIS-finomhangolás, gyorsítótár-bemelegítés), derítse ki, mit, mielőtt törli.

RoleEnvironment

A RoleEnvironment.GetConfigurationSettingValue("Key") a .cscfg fájlból olvassa a beállításokat. A Cloud Servicesen kívül semmi nem biztosítja. Mielőtt bármit átköltöztetne, csomagoljon minden hívást egyetlen kis konfigurációs interfészbe, majd az új hoszton irányítsa ezt az interfészt az alkalmazásbeállításokra, a környezeti változókra vagy a Key Vaultra. Ez a projekt legolcsóbb változtatása, és a többit laptopon is tesztelhetővé teszi.

Három további használatot érdemes keresni:

• RoleEnvironment.Changed, amely újraindítás nélkül alkalmazta a konfigurációs változásokat. A Service Fabricben van megfelelő esemény. Máshol számítson arra, hogy egy beállítás módosítása újraindítja a folyamatot, és tesztelje, mit tesz ez a folyamatban lévő munkával.
• RoleEnvironment.CurrentRoleInstance, amelyet arra használtak, hogy egy példányt kijelöljenek az ütemezett munkára. Az indított (triggered) WebJobok egyetlen példányon futnak; a folyamatosak minden példányon, hacsak nem korlátozzák őket. Döntsön kifejezetten.
• RoleEnvironment.IsAvailable és IsEmulated elágazások. Ezek választják szét a „felhős” és a „helyi” utat, és az egyikből hamarosan halott kód lesz.

.cscfg és .csdef

A .cscfg a környezetenkénti beállításokat, a példányszámokat és a tanúsítványok ujjlenyomatait tartalmazza. A .csdef a végpontokat, a VM-méretet, a helyi tárolót, az indítási feladatokat, a tanúsítványtárolókat és néha egy webes szerepkörön belüli több IIS-webhelyet is. Menjen végig mindkettőn soronként, és írja le, hol él majd utána az egyes bejegyzés: alkalmazásbeállításban, Key Vault-hivatkozásban, infrastruktúrakódban, vagy sehol. A belső végpontokat, amelyeken keresztül a szerepkörök közvetlenül hívják egymást, le kell cserélni egy szolgáltatáscímre vagy egy sorra.

Tanúsítványok

A bővített támogatás már a Key Vaultba kényszerítette a tanúsítványokat, így a 2024-es munka ezen része megtérül. Az változik, hogyan találja meg őket a kód. Egy .csdef egy megnevezett tárolóba telepíti a tanúsítványokat, gyakran a LocalMachine tárolóba. Windowsos App Service-en a WEBSITE_LOAD_CERTIFICATES beállítás a Current User\My tárolóban teszi elérhetővé őket. Az a kód, amely a LocalMachine tárolót nyitja meg, semmit nem talál, és az első hívás, amelynek szüksége van a tanúsítványra, elbukik. Linuxos konténerekben indításkor töltse be a Key Vaultból.

Indítási feladatok

Nyissa meg a Startup.cmd fájlt. Itt laknak a meglepetések, jellemzően executionContext="elevated" beállítással futtatva: betűtípusok a PDF-generáláshoz, egy COM-komponens, egy IIS-újraíró modul, egy registry-módosítás a TLS miatt. Minden sornak háromféle sorsa lehet: már nincs rá szükség, átkerül egy telepítőszkriptbe a Managed Instance-en, vagy beépül egy konténer- vagy VM-lemezképbe.

Helyi tároló

A .csdef egyik LocalStorage erőforrása, amelyet a RoleEnvironment.GetLocalResource hívással olvastak, minden példánynak ideiglenes lemezterületet adott. A valódi ideiglenes fájlokhoz használja a platform temp könyvtárát. Minden, aminek túl kell élnie egy újraindítást, beleértve azokat a fájlokat is, amelyekről valaki azt feltételezte, hogy véglegesek, a Blob Storage-ba kerül.

Web Forms

Ez az a döntés, amely minden mást meghatároz. A Web Forms a System.Web-re épül, és nincs ASP.NET Core-változata, így egy Web Forms-alkalmazás Service Fabricre vagy Container Appsre költöztetése a felhasználói felület újraírását jelenti. Az App Service, a Managed Instance, egy Windows-konténer vagy egy méretezési csoport változatlanul futtatni tudja. Költöztesse úgy, ahogy van, a modernizációt pedig kezelje külön projektként, saját költségvetéssel. Egy felhasználói felület újraírásának nincs helye egy leállítási határidő kritikus útján.

A többi

A két felhőszolgáltatás közötti VIP-csere App Service-en üzembehelyezési slotokká, Container Appsen revíziókká válik. A diagnosztikai (WAD) bővítményen keresztül küldött naplóknak új célhely kell, általában az Application Insights. A standard App Service és a Container Apps nem kínál távoli asztalt; a Managed Instance az Azure Bastionön keresztül engedélyezi, kizárólag diagnosztikára.

Hat hónapos terv

2027. március 31-től visszafelé számolva, középen a decemberi ünnepekkel.

Október: leltár és célválasztás. Vegye számba az összes bővített támogatású telepítést. Minden szerepkörnél rögzítse a .NET Framework verzióját, hogy Web Forms vagy MVC, minden RoleEnvironment-hívást, indítási feladatot, helyi tároló erőforrást, tanúsítványt és végpontot. Ezután ellenőrizze a kellemetlen részt: le tudja-e fordítani a telepített csomagot a meglévő forráskódból? Ügynökség által épített rendszereknél a válasz néha nem, és október a hónap, amikor ezt ki kell deríteni. Válasszon célt szerepkörönként.

November: egy szerepkör, elejétől a végéig. Vezesse be a konfigurációs burkolót, írja meg a célkörnyezetet infrastruktúrakódként, és futtasson egy szerepkört (általában a legegyszerűbb feldolgozót) egy tesztkörnyezetben, naplókkal, tanúsítványokkal és telepítési folyamattal.

December és január: a többi portolása. Cserélje le a belépési pontokat, az indítási feladatokat és a helyi tárolót. Terhelje meg az éleshez hasonló adatokkal egy staging környezetet: egy WebJob vagy konténer nem feltétlenül éri el egy dedikált szerepkör-VM átbocsátóképességét.

Február: párhuzamos futtatás. Futtassa az új környezetet valódi forgalommal. Azoknál a feldolgozóknál, amelyek egy sort osztanak meg a régi szerepkörökkel, vagy előbb tegye idempotenssé a feldolgozást, vagy állítsa le a régi feldolgozókat, mielőtt elindítja az újakat.

Március eleje: átállás. Váltsa át a DNS-t, bőven hagyva időt. A régi telepítést egy-két hétig tartsa leállítva, de érintetlenül, aztán törölje. Ne március utolsó hetére ütemezze az átállást: egy sikertelen átállásnak akkor már nincs második kísérlete.

Ha ehelyett januárban kezd, a modernizációt teljesen hagyja el. Válassza azt a célt, amely a legkevesebb kódmódosítást igényli (App Service, Managed Instance vagy méretezési csoportok), költözzön, és utána refaktoráljon.

Mi nem világos

A Microsoft szerint a szolgáltatást „teljesen kivezetik”, és a migrációra „a szolgáltatáskiesés elkerülése érdekében” van szükség. Az általunk olvasott oldalak nem mondják meg, mi történik egy olyan telepítéssel, amely 2027. április 1-jén még fut. Ne tervezzen azzal, hogy kideríti. A Managed Instance régiói és csomagjai is valószínűleg változnak a következő hónapokban, ezért akkor ellenőrizze őket, amikor dönt, ne ebből a cikkből.

Hol kaphat segítséget

Átvesszük a mások által épített alkalmazásokat, kiderítjük, hogyan futnak, és átköltöztetjük őket: a leltár, a szerepkörönkénti cél, a RoleEnvironment és az indítási feladatok módosítása, valamint az átállás. A régi rendszerek karbantartására vonatkozó munkánk lefedi a .NET Frameworköt és a Web Formst; ha a saját csapata végzi a migrációt, és további kezekre van szüksége, nézze meg a csapatbővítési szolgáltatásunkat.

Ha van egy Cloud Services-telepítése és egy hat hónap múlva esedékes dátuma, írjon az office@c9group.dev címre.