Azure Cloud Services (extended support) poistuu 31. maaliskuuta 2027: web- ja worker-roolien siirto

Microsoft julisti Azure Cloud Services (extended support) -palvelun vanhentuneeksi 31. maaliskuuta 2025 ja poistaa sen kokonaan käytöstä 31. maaliskuuta 2027. Jos jokin liiketoimintasovelluksistasi toimii web- ja worker-rooleina, sen on toimittava jossain muualla Azuressa ennen tuota päivää. Käytöstäpoiston FAQ vastaa suoraan kahteen kysymykseen, jotka kaikki kysyvät ensin: Microsoft ”ei voi myöntää jatkoaikaa”, eikä ”yhden napsautuksen siirtotyökalua ole saatavilla”.

Tästä päivästä, 3. lokakuuta 2026, aikaa on kuusi kuukautta.

Kenelle tämä on

Tyypillinen tapaus: ASP.NET-sovellus .NET Frameworkilla, edessä web-rooli ja takana yksi tai kaksi jonoja käsittelevää worker-roolia, jonka jokin toimisto rakensi kahdeksan tai kymmenen vuotta sitten. Toimisto on usein siirtynyt muihin töihin, sovellus pyörittää yhä tilausten käsittelyä tai asiakasportaalia, eikä kukaan ole avannut .csdef-tiedostoa edellisen siirron jälkeen.

Tarkistaaksesi, koskeeko tämä sinua, avaa Azure-portaali ja listaa resurssit, joiden tyyppi on ”Cloud services (extended support)”. Microsoftin käytöstäpoistoilmoitus linkittää suoraan tähän näkymään. Jos se on tyhjä, olet valmis.

Tämä artikkeli ei koske Cloud Services (classic) -palvelua, joka poistettiin käytöstä vuonna 2024. Jos toimittaja isännöi tuotetta puolestasi, siirto on sen työ: pyydä päivämäärä kirjallisesti. Kaikki alla oleva on tiimeille, jotka omistavat koodin tai omistavat sen paperilla ja joutuvat etsimään jonkun, joka ymmärtää sen.

Miksi tämä on vaikeampaa kuin vuoden 2024 siirto

Monet yritykset siirtyivät extended supportiin vuonna 2024, kun classic poistettiin käytöstä. Se siirto oli suunniteltu halvaksi. Microsoftin extended supportin yleiskatsaus sanoo, että .csdef-, .cscfg- ja .cspkg-tiedostot ”siirtyvät mukana eikä niiden formaatteihin tule muutoksia” ja että ”ajonaikaiseen koodiin ei tarvita muutoksia”. Tarjolla oli jopa paikan päällä tehtävä siirto. Sama sivu suositteli extended supportia sovelluksille, joita ei enää kehitetä, koska ”se tarjoaa nopean siirtopolun”.

Tällä kertaa vastaavaa kohdetta ei ole. Microsoftin sanoin Cloud Services ”perustuu sovellusten käyttöönottoon virtuaalikoneina. Kirjoittamasi koodi on tiukasti sidottu virtuaalikoneen instanssiin”. Koodisi tietää toimivansa roolissa. Se lukee konfiguraation roolista, löytää levytilan roolin kautta, saa varmenteet roolin asentamina ja ajaa asennusskriptejä järjestelmänvalvojana ennen roolin käynnistymistä. Kaikki tämä on korvattava.

Vielä yksi asia ennen virallisen ohjeistuksen lukemista. Microsoftin käytöstäpoistoilmoitus ja FAQ nimeävät yhden kohteen, Service Fabric managed clusterin. Yleiskatsaussivu luettelee viisi, ja Microsoftin oma siirron päätösmatriisi vertailee seitsemää. Service Fabric on oletus, ei vaatimus, ja monelle web-roolille se on väärä.

Kohteet ja milloin kukin sopii

Web- ja worker-roolien ei tarvitse päätyä samaan paikkaan. Valitse kohde rooli kerrallaan.

App Service (Windows). Lähimpänä web-roolia ASP.NET-sovellukselle. Windows-instansseissa on tuetut .NET Framework -versiot valmiiksi asennettuina, joten Web Forms ja MVC 5 toimivat ilman uudelleenkirjoitusta. Worker-roolit voivat seurata WebJobeina, jotka toimivat ”samassa instanssissa kuin verkkosovellus” ilman lisäkustannuksia. Raja on itse kone: Microsoft ohjaa COM-komponentteja, rekisterin käyttöä tai MSI-asennusohjelmia tarvitsevat sovellukset Managed Instanceen, joten korotetuilla oikeuksilla ajettaville käynnistystehtäville ei ole paikkaa vakiopaketissa.

App Service Managed Instance. Rakennettu vanhoille Windows-verkkosovelluksille. Microsoftin yleiskatsauksen mukaan se on ”yleisesti saatavilla Windows-verkkosovelluksille valituilla alueilla”, rajattu Pv4- ja Pmv4-paketteihin, ja siinä on .NET Framework 3.5 ja 4.8 valmiiksi asennettuina sekä PowerShell-asennusskriptit, jotka voivat rekisteröidä COM-komponentteja, kirjoittaa rekisteriavaimia, ajaa MSI-asennusohjelmia ja konfiguroida IIS:n. Se kattaa suurimman osan siitä, mitä korotetuilla oikeuksilla ajettavat käynnistystehtävät tekivät. Rajoitukset: vain verkkosovellukset (ei WebJobeja), ei kontteja, vain Entra ID ja hallittu identiteetti (ei toimialueeseen liittämistä, NTLM:ää tai Kerberosta), ja kirjoitushetkellä ainoa listattu eurooppalainen alue on North Europe.

Container Apps. Hyvä worker-rooleille, kun ne ovat modernilla .NETillä: jonopohjainen skaalaus, ajastetut ja tapahtumalaukaistut työt, skaalaus nollaan. Mutta konttivaatimusten mukaan ”Linux-pohjaiset (linux/amd64) konttikuvat ovat pakollisia”. .NET Frameworkilla oleva koodi ei toimi siellä ennen kuin se on siirretty.

Azure Kubernetes Service. Ajaa Windows Server -kontteja Windows-solmupooleissa, joten .NET Framework -roolin voi kontittaa ja siirtää. Päätösmatriisi arvioi sekä sen siirron monimutkaisuuden että ylläpitokuorman korkeiksi. Se sopii, jos käytät jo Kubernetesia, ei ensimmäiseksi klusteriksi yhdelle vanhalle sovellukselle.

Virtual Machine Scale Sets. Matriisi kuvaa sitä sanoin ”lähempänä Cloud Services -mallia, tarjoaa helpomman lift-and-shift-siirron”. Saat virtuaalikoneen takaisin, ja sen mukana päivitykset, levykuvien rakentamisen ja IIS-asetukset, jotka rooli ennen teki puolestasi.

Service Fabric managed cluster. Microsoftin nimeämä kohde. Worker-roolit kohdistuvat siihen siististi. Web-roolit usein eivät: Service Fabric ”ei tue IIS:ää”, ja muunnosopas listaa ASP.NET Web Formsin ei-tuetuksi ja polkuna muunnoksen ASP.NET Core MVC:ksi. Service Fabricin siirto-opas lisää, että managed clusterit ”eivät tällä hetkellä tue kontteja”, joten IIS:stä riippuva sovellus tarvitsee perinteisen klusterin, jonka ylläpidettävää on enemmän.

Päätöstaulukko

Mikä koodissa muuttuu

Hae ratkaisusta Microsoft.WindowsAzure.ServiceRuntime. Jokainen tiedosto, joka tuo sen, on listalla.

RoleEntryPoint

Worker-rooli on luokka, joka perii RoleEntryPoint-luokan ja ylikirjoittaa metodit OnStart, Run ja OnStop. Jos Run palaa, instanssi kierrätetään. Service Fabric yhdistää nämä kolme yhdeksi RunAsync-metodiksi, jonka pitäisi pysähtyä, ”kun RunAsync-metodin CancellationToken signaloidaan”. App Servicessä tai kontissa sama logiikka muuttuu konsolisovellukseksi tai isännöidyksi taustapalveluksi, jossa on silmukka ja peruutustunniste.

Osa, joka jää huomaamatta, on sammutus. OnStop antoi hetken aikaa käsitellä käsillä oleva viesti loppuun. Varmista, että uusi isäntä välittää peruutussignaalin eteenpäin ja että kesken käsittelyn hylätyn viestin voi turvallisesti käsitellä kahdesti.

Web-rooleilla on usein myös oma luokkansa, tyypillisesti WebRole.cs. Jos sen OnStart tekee jotain (IIS-säätöjä, välimuistin lämmitystä), selvitä mitä ennen kuin poistat sen.

RoleEnvironment

RoleEnvironment.GetConfigurationSettingValue("Key") lukee asetuksia .cscfg-tiedostosta. Mikään Cloud Servicesin ulkopuolinen ei tarjoa sitä. Kääri ennen mitään siirtoa jokainen kutsu yhteen pieneen konfiguraatiorajapintaan ja osoita se sitten uudessa isännässä sovellusasetuksiin, ympäristömuuttujiin tai Key Vaultiin. Se on projektin halvin muutos, ja se tekee lopusta testattavaa kannettavalla.

Kolme muuta käyttötapaa, joita kannattaa etsiä:

• RoleEnvironment.Changed, joka otti konfiguraatiomuutokset käyttöön ilman uudelleenkäynnistystä. Service Fabricissa on vastaava tapahtuma. Muualla oleta, että asetuksen muutos käynnistää prosessin uudelleen, ja testaa, mitä se tekee keskeneräiselle työlle.
• RoleEnvironment.CurrentRoleInstance, jolla valittiin yksi instanssi ajastettua työtä varten. Laukaistut WebJobit toimivat yhdessä instanssissa; jatkuvat toimivat kaikissa instansseissa, ellei niitä rajoiteta. Päätä tästä tietoisesti.
• RoleEnvironment.IsAvailable- ja IsEmulated-haarat. Ne erottavat ”pilvi”-polun ”paikallisesta” polusta, ja toisesta niistä on tulossa kuollutta koodia.

.cscfg ja .csdef

.cscfg sisältää ympäristökohtaiset asetukset, instanssimäärät ja varmenteiden sormenjäljet. .csdef sisältää päätepisteet, virtuaalikoneen koon, paikallisen tallennustilan, käynnistystehtävät, varmennesäilöt ja joskus useita IIS-sivustoja yhden web-roolin sisällä. Käy molemmat läpi rivi riviltä ja kirjaa, missä kukin merkintä on jatkossa: sovellusasetuksena, Key Vault -viittauksena, infrastruktuurikoodissa vai ei missään. Sisäiset päätepisteet, joiden kautta roolit kutsuvat toisiaan suoraan, tarvitsevat korvaajan, joko palveluosoitteen tai jonon.

Varmenteet

Extended support pakotti jo varmenteet Key Vaultiin, joten se osa vuoden 2024 työstä maksaa itsensä takaisin. Muuttuu se, miten koodi löytää ne. .csdef asentaa varmenteet nimettyyn säilöön, usein LocalMachine-säilöön. Windowsin App Servicessä WEBSITE_LOAD_CERTIFICATES-asetus tuo ne saataville säilöön Current User\My. Koodi, joka avaa LocalMachine-säilön, ei löydä mitään, ja ensimmäinen varmennetta tarvitseva kutsu epäonnistuu. Linux-konteissa lataa varmenne sen sijaan Key Vaultista käynnistyksen yhteydessä.

Käynnistystehtävät

Avaa Startup.cmd. Siellä yllätykset asuvat, tyypillisesti ajettuina asetuksella executionContext="elevated": fontit PDF-muodostusta varten, COM-komponentti, IIS:n uudelleenkirjoitusmoduuli, rekisterimuutos TLS:ää varten. Jokaisella rivillä on kolme mahdollista kohtaloa: sitä ei enää tarvita, se siirtyy Managed Instancen asennusskriptiin tai se leivotaan kontti- tai virtuaalikonekuvaan.

Paikallinen tallennustila

.csdef-tiedoston LocalStorage-resurssi, jota luettiin RoleEnvironment.GetLocalResource-kutsulla, antoi jokaiselle instanssille työlevyn. Käytä alustan väliaikaishakemistoa aidoille väliaikaistiedostoille. Kaikki, minkä on säilyttävä uudelleenkäynnistyksen yli, myös tiedostot, joita joku oletti pysyviksi, menee Blob Storageen.

Web Forms

Tämä on päätös, joka ohjaa kaikkea muuta. Web Forms rakentuu System.Web-kirjaston varaan, eikä siitä ole ASP.NET Core -versiota, joten Web Forms -sovelluksen siirtäminen Service Fabriciin tai Container Appsiin tarkoittaa sen käyttöliittymän uudelleenkirjoittamista. App Service, Managed Instance, Windows-kontti tai scale set voivat kaikki ajaa sitä muuttamattomana. Siirrä se sellaisenaan ja tee modernisoinnista erillinen projekti omalla budjetillaan. Käyttöliittymän uudelleenkirjoitus ei kuulu sulkemispäivän kriittiselle polulle.

Loput

Kahden cloud servicen välinen VIP swap muuttuu App Servicen käyttöönottopaikoiksi (deployment slots) tai Container Appsin revisioiksi. Diagnostiikkalaajennuksen (WAD) kautta lähetetyt lokit tarvitsevat uuden kohteen, yleensä Application Insightsin. Vakio-App Service ja Container Apps eivät tarjoa etätyöpöytää; Managed Instance sallii sen Azure Bastionin kautta, vain diagnostiikkaan.

Kuuden kuukauden suunnitelma

Taaksepäin 31. maaliskuuta 2027 alkaen, joululomat keskellä.

Lokakuu: kartoitus ja kohteen valinta. Listaa jokainen extended support -käyttöönotto. Kirjaa jokaisesta roolista .NET Framework -versio, Web Forms vai MVC, jokainen RoleEnvironment-kutsu, käynnistystehtävä, paikallinen tallennustilaresurssi, varmenne ja päätepiste. Tarkista sitten epämukava osa: pystytkö rakentamaan käytössä olevan paketin hallussasi olevasta lähdekoodista? Toimistojen rakentamissa järjestelmissä vastaus on joskus ei, ja lokakuu on oikea kuukausi saada se selville. Valitse kohde rooli kerrallaan.

Marraskuu: yksi rooli alusta loppuun. Lisää konfiguraatiokääre, kirjoita kohdeympäristö infrastruktuurikoodiksi ja saa yksi rooli (yleensä yksinkertaisin worker) toimimaan testiympäristössä lokeineen, varmenteineen ja putkineen.

Joulu- ja tammikuu: loppujen siirto. Korvaa aloituspisteet, käynnistystehtävät ja paikallinen tallennustila. Kuormitustestaa esituotantoympäristö tuotannonkaltaisella datalla: WebJob tai kontti ei välttämättä yllä erillisen roolivirtuaalikoneen läpäisykykyyn.

Helmikuu: rinnakkaisajo. Aja uutta ympäristöä oikeaa liikennettä vasten. Jos workerit jakavat jonon vanhojen roolien kanssa, tee käsittelystä ensin idempotentti tai pysäytä vanhat workerit ennen uusien käynnistämistä.

Maaliskuun alku: siirtymä. Vaihda DNS hyvissä ajoin. Pidä vanha käyttöönotto pysäytettynä mutta koskemattomana viikon tai kaksi ja poista se sitten. Älä ajoita siirtymää maaliskuun viimeiselle viikolle: epäonnistuneelle siirtymälle ei silloin ole toista yritystä.

Jos aloitat vasta tammikuussa, jätä modernisointi kokonaan pois. Valitse kohde, joka vaatii vähiten koodimuutoksia (App Service, Managed Instance tai scale setit), siirrä ja refaktoroi jälkikäteen.

Mikä ei ole selvää

Microsoftin mukaan palvelu ”poistetaan kokonaan käytöstä” ja siirto tarvitaan ”palvelukatkon välttämiseksi”. Lukemamme sivut eivät kerro, mitä tapahtuu käyttöönotolle, joka on yhä käynnissä 1. huhtikuuta 2027. Älä suunnittele selvittäväsi sitä. Managed Instancen alueet ja paketit todennäköisesti myös muuttuvat tulevina kuukausina, joten varmista ne päätöshetkellä äläkä tästä artikkelista.

Mistä saat apua

Otamme haltuumme muiden rakentamia sovelluksia, selvitämme, miten ne toimivat, ja siirrämme ne: kartoituksen, kohteen rooli kerrallaan, RoleEnvironment- ja käynnistystehtävämuutokset sekä siirtymän. Vanhojen järjestelmien ylläpitotyömme kattaa .NET Frameworkin ja Web Formsin; jos oma tiimisi tekee siirron ja tarvitsee lisäkäsiä, katso henkilöstövuokraus.

Jos sinulla on Cloud Services -käyttöönotto ja päivämäärä kuuden kuukauden päässä, kirjoita osoitteeseen office@c9group.dev.