Migrera ett program till Azure App Service och SQL Database

Den här artikeln visar hur det fiktiva företaget Contoso omstrukturerar ett Windows .NET-program med två nivåer som körs på virtuella VMware-datorer som en del av en migrering till Azure. Contoso-teamet migrerar programmets virtuella klientdelsdator (VM) till en Azure App Service webbapp och programdatabasen för att Azure SQL Database.

SmartHotel360-programmet som vi använder i det här exemplet tillhandahålls som programvara med öppen källkod. Om du vill använda det i dina egna testsyften kan du ladda ned det från GitHub.

Affärsdrivande faktorer

Contosos IT-ledningsgrupp har arbetat tillsammans med affärspartner för att förstå vad man vill uppnå med migreringen:

  • Hantera företagets tillväxt. Contoso växer och det finns ett tryck på deras lokala system och infrastruktur.
  • Öka effektiviteten. Contoso måste ta bort onödiga procedurer och effektivisera processer för utvecklare och användare. En snabb IT-lösning som inte slösar tid eller pengar är viktigt för företaget, så att man kan leverera snabbare enligt kundkraven.
  • Öka flexibiliteten. För att möjliggöra framgång i en global ekonomi måste Contoso IT vara mer lyhörd för verksamhetens behov. Den måste kunna reagera snabbare på ändringar på marknadsplatsen. IT får inte komma i vägen eller bli en affärsblockerare.
  • Skalning. När företagets verksamhet växer måste Contosos IT-avdelning tillhandahålla system som kan växa i samma takt.
  • Minska kostnaderna. Contoso vill minimera licenskostnaderna.

Migreringsmål

För att fastställa den bästa migreringsmetoden har Contosos molnteam fäst följande mål:

Krav Information
Program Programmet i Azure förblir lika viktigt som det är idag lokalt.

Den bör ha samma prestandafunktioner som den för närvarande har i VMware.

Teamet vill inte investera i programmet. För tillfället flyttar administratörer helt enkelt programmet på ett säkert sätt till molnet.

Teamet vill sluta stödja Windows Server 2008 R2, som programmet för närvarande körs på.

Teamet vill också gå från SQL Server 2008 R2 till en modern PaaS-databas (plattform som en tjänst), vilket minimerar behovet av hantering.

Contoso vill dra nytta av sina investeringar i SQL Server-licensiering och Software Assurance där det är möjligt.

Contoso vill dessutom minimera den felkritiska systemdelen på webbnivån.
Begränsningar Programmet består av ett ASP.NET program och en WCF-tjänst (Windows Communication Foundation) som körs på samma virtuella dator. De vill sprida dessa komponenter mellan två webbappar med hjälp av Azure App Service.
Azure Contoso vill flytta programmet till Azure, men de vill inte köra det på virtuella datorer. Contoso vill använda Azure PaaS-tjänster för både webb- och data nivåerna.
DevOps Contoso vill gå över till en DevOps-modell som använder Azure DevOps för sina bygg- och versionspipelines.

Lösningsdesign

När contoso har fäst sina mål och krav designar och granskar de en distributionslösning. De identifierar också migreringsprocessen, inklusive de Azure-tjänster som de ska använda för migreringen.

Aktuellt program

  • Det lokala SmartHotel360-programmet är nivåindelat på två virtuella datorer WEBVM och SQLVM.
  • De virtuella datorerna finns på VMware ESXi-värdversion contosohost1.contoso.com 6.5.
  • VMware-miljön hanteras av vCenter Server 6.5 (vcenter.contoso.com), som körs på en virtuell dator.
  • Contoso har ett lokalt datacenter (contoso-datacenter) med en lokal domänkontrollant (contosodc1).
  • De lokala, virtuella datorerna i Contoso-datacentret inaktiveras när migreringen är färdig.

Föreslagen lösning

  • För programmets databasnivå jämförde Contoso Azure SQL Database med SQL Server genom att referera till funktionsjämförelsen: Azure SQL Database och Azure SQL Managed Instance. Contoso bestämde sig för att använda Azure SQL Database av några anledningar:
    • Azure SQL Database är en hanterad tjänst för relationsdatabaser. Den ger förutsägbar prestanda på flera servicenivåer med nästan obefintlig administration. Fördelarna är dynamisk skalbarhet utan driftavbrott, inbyggd, intelligent optimering och global skalbarhet och tillgänglighet.
    • Contoso kan använda den enkla Data Migration Assistant för att utvärdera den lokala databasmigreringen till Azure SQL Database.
    • Contoso kan använda Azure Database Migration Service för att migrera den lokala databasen till Azure SQL Database.
    • Med Software Assurance kan Contoso byta ut befintliga licenser mot rabatterade priser på en databas i SQL Database med hjälp av Azure Hybrid-förmån för SQL Server. Den här metoden kan ge en kostnadsbesparing på upp till 30 procent.
    • SQL Database tillhandahåller säkerhetsfunktioner som Always Encrypted, dynamisk datamaskering, säkerhet på radnivå och IDENTIFIERING av SQL-hot.
  • För programwebbnivån har Contoso valt att använda Azure App Service. Med den här PaaS-tjänsten kan de distribuera programmet med bara några konfigurationsändringar. Contoso använder Visual Studio för att göra ändringen, och de distribuerar två webbappar, en för webbplatsen och en för WCF-tjänsten.
  • För att uppfylla kraven för en DevOps-pipeline använder Contoso Azure DevOps för källkodshantering med Git-lagringsplatser. De använder automatiserade versioner och versioner för att skapa koden och distribuera den till Azure App Service.

Utvärdering av lösningen

Contoso utvärderar den föreslagna designen genom att sätta ihop en för- och nackdelar-lista, enligt följande tabell:

Att tänka på Information
Fördelar SmartHotel360-programkoden kräver inte ändringar för migrering till Azure.

Contoso kan dra nytta av sin investering i Software Assurance med hjälp av Azure Hybrid-förmån för både SQL Server och Windows Server.

Efter migreringen behöver Windows Server 2008 R2 inte stödjas. Mer information finns i Microsofts livscykelpolicy.

Contoso kan konfigurera webbnivån för programmet med flera instanser, så att webbnivån inte längre är en enskild felpunkt.

Databasen är inte längre beroende av åldrande SQL Server 2008 R2.

SQL Database stöder de tekniska kraven. Contoso utvärderade den lokala databasen med hjälp av Data Migration Assistant och fann att den är kompatibel.

Azure SQL Database har inbyggd feltolerans som Contoso inte behöver konfigurera. Detta säkerställer att datanivån inte längre är en felkritisk systemdel.

Om Contoso använder Azure Database Migration Service för att migrera sin databas är infrastrukturen redo för migrering av databaser i stor skala.
Nackdelar Azure App Service stöder endast en programdistribution för varje webbapp. Det innebär att två webbappar måste etableras, en för webbplatsen och en för WCF-tjänsten.

Föreslagen arkitektur

Diagram över den föreslagna arkitekturen.

Migreringsprocessen

  1. Contoso etablerar en Azure SQL hanterad instans och migrerar sedan SmartHotel360-databasen till den med hjälp av Azure Database Migration Service.

  2. Contoso etablerar och konfigurerar webbappar och distribuerar SmartHotel360-programmet till dem.

    Diagram över migreringsprocessen.

Azure-tjänster

Tjänst Beskrivning Kostnad
Azure App Service Migration Assistant En kostnadsfri och enkel väg för att sömlöst migrera .NET-webbprogram från en lokal plats till molnet med minimala eller inga kodändringar. Det är ett nedladdningsbart verktyg, kostnadsfritt.
Data Migration Assistant Contoso använder Data Migration Assistant för att utvärdera och identifiera kompatibilitetsproblem som kan påverka databasfunktionerna i Azure. Data Migration Assistant utvärderar funktionsparitet mellan SQL-källor och mål och rekommenderar prestanda- och tillförlitlighetsförbättringar. Det är ett nedladdningsbart verktyg, kostnadsfritt.
Azure Database Migration Service Azure Database Migration Service möjliggör sömlös migrering från flera databaskällor till Azure-dataplattformar med minimal stilleståndstid. Lär dig mer om regioner som stöds och Database Migration Service- prissättning.
Azure SQL Database En intelligent, fullständigt hanterad och molnbaserad relationsdatabastjänst. Kostnaden baseras på funktioner, dataflöde och storlek. Läs mer.
Azure App Service Hjälper dig att skapa kraftfulla molnprogram som använder en fullständigt hanterad plattform. Prissättningen baseras på storlek, plats och användningstid. Läs mer.
Azure-pipelines Tillhandahåller en pipeline för kontinuerlig integrering och kontinuerlig distribution (CI/CD) för programutveckling. Pipelinen börjar med en Git-lagringsplats för att hantera programkod, ett byggsystem för att producera paket och andra byggartefakter samt ett versionshanteringssystem för att distribuera ändringar i utvecklings-, test- och produktionsmiljöer.

Förutsättningar

För att köra det här scenariot måste Contoso uppfylla följande krav:

Krav Information
Azure-prenumeration Contoso skapade prenumerationer i en tidigare i den här artikelserien. Om du inte har någon Azure-prenumeration kan du skapa ett kostnadsfritt konto.

Om du skapar ett kostnadsfritt konto är du administratör för din prenumeration och kan utföra alla åtgärder.

Om du använder en befintlig prenumeration och inte är administratör måste du be administratören att ge dig ägar- eller deltagarbehörighet.
Azure-infrastruktur Contoso konfigurerar Azure-infrastrukturen enligt beskrivningen i Azure-infrastrukturen för migrering.

Scenariosteg

Contoso genomför migreringen på följande sätt:

  • Steg 1: Utvärdera och migrera webbapparna.. Contoso använder verktyget Azure App Service Migration Assistant för att köra kompatibilitetskontroller före migreringen och migrera sina webbappar till Azure App Service.
  • Steg 2: Etablera en databas i Azure SQL Database. Contoso etablerar en Azure SQL Database-instans. När programwebbplatsen har migrerats till Azure pekar WCF-tjänstwebbappen på den här instansen.
  • Steg 3: Utvärdera databasen. Contoso utvärderar databasen för migrering med hjälp av Data Migration Assistant och migrerar den sedan via Azure Database Migration Service.
  • Steg 4: Konfigurera Azure DevOps. Contoso skapar ett nytt Azure DevOps-projekt och importerar Git-lagringsplatsen.
  • Steg 5: Konfigurera anslutningssträngar. Contoso konfigurerar anslutningssträngar så att webbnivåns webbapp, WCF-tjänstens webbapp och SQL-instansen kan kommunicera.
  • Steg 6: Konfigurera bygg- och versionspipelines i Azure DevOps. Som ett sista steg konfigurerar Contoso bygg- och versionspipelines i Azure DevOps för att skapa programmet och distribuerar dem sedan till två separata webbappar.

Steg 1: Utvärdera och migrera webbappar

Contosos administratörer utvärderar och migrerar sin webbapp med hjälp av verktyget Azure App Service Migration Assistant. De använder utbildningsvägen Migrera ASP.NET till Azure som en guide under processen. Administratörerna utför följande åtgärder:

  • De använder azure App Service migreringsutvärderingsverktyg för att utvärdera eventuella beroenden mellan sina webbappar och för att avgöra om det finns några inkompatibiliteter mellan deras lokala webbappar och vad som stöds på Azure App Service.

  • De laddar ned Azure App Service Migration Assistant och loggar in på sitt Azure-konto.

  • De väljer en prenumeration, en resursgrupp och webbplatsens domännamn.

Steg 2: Etablera en databas i Azure SQL Database

  1. Contosos administratörer bestämmer sig för att skapa en Azure SQL Database-instans.

    Skärmbild som visar länken SQL Database.

  2. De anger ett databasnamn som matchar databasen, SmartHotel.Registration, som körs på den lokala virtuella datorn. De placerar databasen i ContosoRG resursgruppen. Detta är den resursgrupp som används för produktionsresurser i Azure.

    Skärmbild som visar SQL Database instansinformation.

  3. De konfigurerar en ny SQL Server instans, sql-smarthotel-eus2, i den primära regionen.

    Skärmbild av den nya SQL Server-instansen.

  4. De ställer in prisnivån så att den matchar deras server- och databasbehov. De väljer också att spara pengar med Azure Hybrid-förmån eftersom de redan har en SQL Server-licens.

  5. För storleksändring använder de vCore-baserade inköp och anger gränserna för sina förväntade krav.

    Skärmbild av storlekskraven för virtuella kärnor.

  6. De skapar databasinstansen.

    Skärmbild av att skapa en SQL Database-instans.

  7. De öppnar databasen och noterar den information de behöver när de använder Data Migration Assistant för migrering.

    Skärmbild av databasinstansens textfil.

Behöver du mer hjälp?

Steg 3: Utvärdera databasen

Contosos administratörer utvärderar databasen med hjälp av Data Migration Assistant och migrerar den sedan med hjälp av Azure Database Migration Service genom att referera till självstudiekursen för stegvis migrering. De kan utföra onlinemigreringar, offline- och hybridmigreringar (förhandsversion).

I korthet gör administratörerna följande:

  • De använder Data Migration Assistant för att identifiera och lösa eventuella problem med databasmigrering.
  • De skapar en Azure Database Migration Service-instans med en Premium-SKU som är ansluten till det virtuella nätverket.
  • De säkerställer att instansen kan komma åt fjärr-SQL Server via det virtuella nätverket. Detta innebär att alla inkommande portar tillåts från Azure till SQL Server på virtuell nätverksnivå, nätverks-VPN och den dator som är värd för SQL Server.
  • De konfigurerar instansen:
    • Skapa ett migreringsprojekt.
    • Lägg till en källa (lokal databas).
    • Välj ett mål.
    • Välj de databaser som ska migreras.
    • Konfigurera avancerade inställningar.
    • Starta replikeringen.
    • Åtgärda eventuella fel.
    • Utför den slutliga snabbväxlingen.

Steg 4: Konfigurera Azure DevOps

Contoso måste bygga DevOps-infrastrukturen och pipelines för programmet. För att göra det skapar Contoso-administratörerna ett nytt DevOps-projekt, importerar koden och konfigurerar sedan Build and Release-pipelines.

  1. I Contoso Azure DevOps-kontot skapar de ett nytt projekt och ContosoSmartHotelRefactorväljer sedan Git för versionskontroll.

    Skärmbild av att skapa ett nytt projekt i Azure DevOps.

  2. De importerar git-lagringsplatsen som för närvarande innehåller deras programkod. De laddar ned den från den offentliga GitHub-lagringsplatsen.

    Skärmbild av fönstret Importera en Git-lagringsplats.

  3. De ansluter Visual Studio till lagringsplatsen och klonar sedan koden till utvecklardatorn med hjälp av Team Explorer.

    Skärmbild av fönstret Anslut till ett projekt.

  4. De öppnar lösningsfilen för programmet. Webbappen och WCF-tjänsten har separata projekt i filen.

    Skärmbild av Solution Explorer som visar webbapps- och WCF-tjänstprojekten.

Steg 5: Konfigurera anslutningssträngar

Contosos administratörer ser till att webbapparna och databasen kan kommunicera med varandra. Det gör de genom att konfigurera anslutningssträngar i koden och i webbapparna.

  1. I webbappen för WCF-tjänsten, under SHWCF-EUS2Inställningar>Programinställningar, lägger de till en ny anslutningssträng med namnet DefaultConnection.

  2. De hämtar anslutningssträngen SmartHotel-Registration från databasen och uppdaterar den sedan med rätt autentiseringsuppgifter.

    Skärmbild av inställningsfönstret för anslutningssträngen.

  3. I Visual Studio öppnar administratörerna SmartHotel.Registration.wcf projektet från lösningsfilen. I projektet uppdaterar connectionStrings de avsnittet i web.config filen med anslutningssträngen.

    Skärmbild av avsnittet connectionStrings i filen web.config i projektet SmartHotel.Registration.wcf.

  4. De ändrar filavsnittet clientweb.configSmartHotel.Registration.Web att det pekar på WCF-tjänstens nya plats. Det här är URL:en för den WCF-webbapp som är värd för tjänstslutpunkten.

    Skärmbild av klientavsnittet i filen web.config i projektet SmartHotel.Registration.wcf.

  5. Nu när kodändringarna är på plats checkar administratörerna in och synkroniserar dem med hjälp av Team Explorer i Visual Studio.

Steg 6: Konfigurera bygg- och versionspipelines i Azure DevOps

Contosos administratörer konfigurerar nu Azure DevOps för att utföra bygg- och lanseringsprocessen.

  1. I Azure DevOps väljer de Skapa och släppa>ny pipeline.

    Skärmbild av länken Ny pipeline i Azure DevOps.

  2. De väljer Azure Repos Git och i listrutan Lagringsplats väljer de relevant lagringsplats.

    Skärmbild av Git-knappen för Azure Repos och den valda lagringsplatsen.

  3. Under Välj en mall väljer de mallen för sitt bygge ASP.NET .

    Skärmbild av fönstret Välj en mall för att välja mallen ASP.NET.

  4. De använder namnet ContosoSmartHotelRefactor-ASP.NET-CI på bygget och väljer sedan Spara & kö, vilket startar den första versionen.

    Skärmbild av knappen Spara & kö för bygget.

  5. De väljer build-numret för att se processen. När det är klart kan administratörerna se processfeedback och de väljer Artefakter för att granska byggresultatet.

    Skärmbild av build-sidan och länken Artifacts (Artefakter) för granskning av byggresultatet.

    Fönstret Artefaktutforskaren öppnas och mappen drop visar byggresultatet.

    • De två .zip filerna är paketen som innehåller programmen.
    • Dessa .zip filer används i versionspipelinen för distribution till Azure App Service.

    Skärmbild av fönstret Artefaktutforskaren.

  6. De väljer Versioner>+ Ny pipeline.

    Ny pipeline

  7. De väljer distributionsmallen för Azure App Service.

    Skärmbild av mallen Azure App Service distribution.

  8. De namnger versionspipelinen ContosoSmartHotel360Refactor och anger SHWCF-EUS2 i rutan Fasnamn namnet på WCF-webbappen.

    Skärmbild av fasnamnet för WCF-webbappen.

  9. Under stegen väljer de 1 jobb, 1 uppgift för att konfigurera distributionen av WCF-tjänsten.

    Skärmbild av alternativet 1 jobb, 1 aktivitet.

  10. De kontrollerar att prenumerationen har valts och auktoriserats och väljer sedan apptjänstnamnet.

    Skärmbild av att välja apptjänstnamnet.

  11. I pipelinen >Artefakter väljer de + Lägg till en artefakt och väljer sedan för att skapa med pipelinen ContosoSmarthotel360Refactor .

    Skärmbild av knappen Skapa i fönstret Lägg till en artefakt.

  12. Om du vill aktivera utlösaren för kontinuerlig distribution väljer administratörerna blixtikonen på artefakten.

    Skärmbild av blixtikonen på artefakten.

  13. De anger utlösaren för kontinuerlig distribution till Aktiverad.

    Skärmbild som visar utlösaren för kontinuerlig distribution inställd på Aktiverad.

  14. Administratörerna går tillbaka till steg 1-jobbet, 1 uppgift och väljer sedan Distribuera Azure App Service.

    Skärmbild av alternativet för att välja Distribuera Azure App Service.

  15. I Välj en fil eller mapp expanderar de drop-mappen , väljer den SmartHotel.Registration.Wcf.zip fil som skapades under bygget och väljer sedan Spara.

    Skärmbild av fönstret Välj en fil eller mapp för att välja WCF-filen.

  16. De väljerPipeline-faser> och väljer sedan + Lägg till för att lägga till en miljö för SHWEB-EUS2. De väljer en annan Azure App Service-distribution.

    Skärmbild av länken 1 jobb, 1 aktivitet för att lägga till en miljö.

  17. De upprepar processen för att publicera SmartHotel.Registration.Web.zip filen till rätt webbapp och väljer sedan Spara.

    Skärmbild av fönstret Välj en fil eller mapp för att välja webbfilen.

    Versionspipelinen visas enligt följande:

    Skärmbild av sammanfattningen av versionspipelinen.

  18. De går tillbaka till Skapa, väljer Utlösare och markerar sedan kryssrutan Aktivera kontinuerlig integrering . Den här åtgärden aktiverar pipelinen så att när ändringar checkas in i koden sker den fullständiga versionen och versionen.

    Skärmbild som markerar kryssrutan Aktivera kontinuerlig integrering.

  19. De väljer Spara & kö för att köra hela pipelinen. En ny version utlöses, vilket i sin tur skapar den första versionen av programmet till Azure App Service.

    Skärmbild av knappen Spara & kö.

  20. Contoso-administratörerna kan följa processen för att kompilera och lansera pipelinen från Azure DevOps. När bygget är klart startar versionen.

    Skärmbild av förloppet för kompilering och lansering.

  21. När pipelinen är klar har båda platserna distribuerats och programmet är igång och körs online.

    Skärmbild som visar att programmet är igång.

    Programmet har migrerats till Azure.

Rensa efter migrering

Efter migreringen slutför Contoso dessa rensningssteg:

  • De tar bort de lokala virtuella datorerna från vCenter-inventeringen.
  • De tar bort de virtuella datorerna från de lokala säkerhetskopieringsjobben.
  • De uppdaterar sin interna dokumentation för att visa de nya platserna för SmartHotel360-programmet. Dokumentationen visar att databasen körs i Azure SQL Database och klientdelen som körs i två webbappar.
  • De granskar alla resurser som interagerar med de inaktiverade virtuella datorerna och uppdaterar relevanta inställningar eller dokumentation för att återspegla den nya konfigurationen.

Granska distributionen

När resurserna nu har migrerats till Azure måste Contoso operationalisera och skydda sin nya infrastruktur.

Säkerhet

  • Contoso hjälper till att säkerställa att deras nya SmartHotel-Registration databas är säker. Läs mer.
  • Contoso uppdaterar särskilt webbapparna så att de använder SSL med certifikat.

Säkerhetskopior

  • Contoso-teamet granskar säkerhetskopieringskraven för Azure SQL Database. Läs mer.
  • De lär sig också om att hantera SQL Database säkerhetskopior och återställningar. Läs mer om automatiska säkerhetskopieringar.
  • De överväger att implementera redundansgrupper för att tillhandahålla regional redundans för databasen. Läs mer.
  • För motståndskraft överväger de att distribuera webbappen i huvudregionen (East US 2) och den sekundära regionen (Central US). Teamet kan konfigurera Traffic Manager för att säkerställa redundans vid regionala avbrott.

Licensierings- och kostnadsoptimering

  • När alla resurser har distribuerats tilldelar Contoso Azure-taggar baserat på deras infrastrukturplanering.
  • All licensiering är inbyggd i kostnaden för de PaaS-tjänster som Contoso använder. Den här kostnaden dras av från Enterprise-avtal.
  • Contoso använder Azure Cost Management + Billing för att säkerställa att de håller sig inom de budgetar som it-ledningen har fastställt.

Slutsats

I den här artikeln omstrukturerade Contoso SmartHotel360-programmet i Azure genom att migrera programmets virtuella klientdelsdator till två Azure App Service webbappar. Programdatabasen migrerades till Azure SQL Database.