Etablera och distribuera mikrotjänster förutsägbart i Azure

Den här självstudien visar hur du etablerar och distribuerar ett program som består av mikrotjänster i Azure App Service som en enda enhet och på ett förutsägbart sätt med JSON-resursgruppmallar och PowerShell-skript.

Vid etablering och distribution av storskaliga program som består av mycket frikopplade mikrotjänster är repeterbarhet och förutsägbarhet avgörande för framgång. Azure App Service kan du skapa mikrotjänster som omfattar webbappar, mobila backend-datorer och API-appar. Med Azure Resource Manager kan du hantera alla mikrotjänster som en enhet, tillsammans med resursberoenden som inställningar för databas och källkontroll. Nu kan du även distribuera ett sådant program med JSON-mallar och enkla PowerShell-skript.

Vad du ska göra

I självstudien distribuerar du ett program som innehåller:

  • Två App Service appar (d.v.s. två mikrotjänster)
  • En SQL Database
  • Appinställningar, anslutningssträngar och källkontroll
  • Application Insights, aviseringar, inställningar för automatisk skalning

Verktyg som du kommer att använda

I den här självstudien använder du följande verktyg. Eftersom det inte är någon omfattande diskussion om verktyg ska jag hålla mig till scenariot från början till slut och bara ge dig en kort introduktion till var och en och där du kan hitta mer information om dem.

Azure Resource Manager-mallar (JSON)

Varje gång du skapar en app i Azure App Service till exempel använder Azure Resource Manager en JSON-mall för att skapa hela resursgruppen med komponentresurserna. En komplex mall från Azure Marketplace kan innehålla databasen, lagringskontona, App Service-planen, själva appen, aviseringsregler, appinställningar, inställningar för automatisk skalning med mera och alla dessa mallar är tillgängliga för dig via PowerShell. Mer information om Azure Resource Manager-mallar finns i Redigera Azure Resource Manager mallar

Azure SDK 2.6 för Visual Studio

Den senaste SDK:n innehåller förbättringar av Resource Manager mallstöd i JSON-redigeraren. Du kan använda det här för att snabbt skapa en resursgruppsmall från grunden eller öppna en befintlig JSON-mall (till exempel en nedladdad gallerimall) för modifiering, fylla i parameterfilen och även distribuera resursgruppen direkt från en Azure-resursgruppslösning.

Mer information finns i Azure SDK 2.6 för Visual Studio.

Azure PowerShell 0.8.0 eller senare

Från och med version 0.8.0 Azure PowerShell installationen även Azure Resource Manager-modulen utöver Azure-modulen. Med den här nya modulen kan du skripta distributionen av resursgrupper.

Mer information finns i Använda Azure PowerShell med Azure Resource Manager

Azure Resource Explorer

Med det här förhandsgranskningsverktyget kan du utforska JSON-definitionerna för alla resursgrupper i din prenumeration och de enskilda resurserna. I verktyget kan du redigera JSON-definitionerna för en resurs, ta bort en hel hierarki med resurser och skapa nya resurser. Informationen som är lättillgänglig i det här verktyget är mycket användbar för mallskapning eftersom den visar vilka egenskaper du behöver ange för en viss typ av resurs, rätt värden osv. Du kan till och med skapa en resursgrupp i Azure Portal och sedan granska dess JSON-definitioner i utforskarverktyget för att hjälpa dig att skapa en mall för resursgruppen.

Distribuera till Azure (knapp)

Om du använder GitHub för källkontroll kan du placera knappen Deploy to Azure (Distribuera till Azure) i readme-enheten. MD, som möjliggör ett nyckelnyckelsdistributionsgränssnitt till Azure. Du kan göra detta för en enkel app, men du kan utöka detta för att aktivera distribution av en hel resursgrupp genom att placera en azuredeploy.json-fil i lagringsplatsens rot. Den här JSON-filen, som innehåller resursgruppmallen, används av knappen Distribuera till Azure för att skapa resursgruppen. Ett exempel finns i ToDoApp-exemplet , som du kommer att använda i den här självstudien.

Hämta exempelresursgruppmallen

Så nu ska vi gå direkt till den.

  1. Gå till ToDoApp-App Service exempel.

  2. I readme.md du på Distribuera till Azure.

  3. Du kommer till webbplatsen deploy-to-azure och uppmanas att ange distributionsparametrar. Observera att de flesta fält fylls i med namnet på lagringsplatsen och några slumpmässiga strängar åt dig. Du kan ändra alla fält om du vill, men det enda du behöver ange är SQL Server administratörsinloggningen och lösenordet. Klicka sedan på Nästa.

    Shows the input deployment parameters on the deploy-to-azure site.

  4. Klicka sedan på Distribuera för att starta distributionsprocessen. När processen har slutförts klickar du på länken http://todoappXXXX.azurewebsites.net för att bläddra i det distribuerade programmet.

    Shows your application's deployment process.

    Användargränssnittet skulle vara lite långsamt när du först bläddrar till det eftersom apparna precis har börjat, men övertyga dig själv att det är ett fullt funktionellt program.

  5. Gå tillbaka till sidan Distribuera och klicka på länken Hantera för att se det nya programmet i Azure Portal.

  6. Klicka på länken resursgrupp i listrutan Essentials. Observera också att appen redan är ansluten till lagringsplatsen GitHub under Externa Project.

    Shows the Resource group link in the Essentials dropdown section.

  7. Observera att det redan finns två appar och en SQL Database i resursgruppen på resursgruppsbladet.

    Shows the resources available in your resource group.

Allt som du nyss såg på några minuter är ett fullständigt distribuerat program med två mikrotjänster, med alla komponenter, beroenden, inställningar, databas och kontinuerlig publicering, konfigurerade av en automatiserad orkestrering i Azure Resource Manager. Allt detta gjordes med två saker:

  • Knappen Distribuera till Azure
  • azuredeploy.json i lagringsplatsens rot

Du kan distribuera samma program tiotals, hundratals eller tusentals gånger och ha exakt samma konfiguration varje gång. Repeterbarheten och förutsägbarheten i den här metoden gör att du enkelt och enkelt kan distribuera storskaliga program.

Granska (eller redigera) AZUREDEPLOY. JSON

Nu ska vi titta på hur GitHub lagringsplatsen har ställts in. Du kommer att använda JSON-redigeraren i Azure .NET SDK, så om du inte redan har installerat Azure .NET SDK 2.6 gör du det nu.

  1. Klona ToDoApp-lagringsplatsen med ditt favoritverktyg för git. I skärmbilden nedan gör jag detta i Team Explorer i Visual Studio 2013.

    Shows how to use a git tool to clone the ToDoApp repository.

  2. Från lagringsplatsens rot öppnar du azuredeploy.json i Visual Studio. Om du inte ser fönstret JSON-disposition måste du installera Azure .NET SDK.

    Shows the JSON Outline pane in Visual Studio.

Jag kommer inte att beskriva varje detalj i JSON-formatet, men avsnittet Fler resurser innehåller länkar för att lära mig resursgruppens mallspråk. Här ska jag bara visa de intressanta funktioner som kan hjälpa dig att komma igång med att skapa en egen anpassad mall för appdistribution.

Parametrar

Ta en titt på parameteravsnittet för att se att de flesta av dessa parametrar är vad knappen Distribuera till Azure uppmanar dig att ange. Webbplatsen bakom knappen Distribuera till Azure fyller i indatagränssnittet med hjälp av parametrarna som definierats i azuredeploy.json. De här parametrarna används i resursdefinitionerna, till exempel resursnamn, egenskapsvärden osv.

Resurser

I resursnoden kan du se att 4 resurser på den översta nivån har definierats, inklusive en SQL Server-instans, en App Service-plan och två appar.

App Service-plan

Vi börjar med en enkel resurs på rotnivå i JSON. I JSON-dispositionen klickar du på App Service plan med namnet [hostingPlanName] för att markera motsvarande JSON-kod.

Shows the [hostingPlanName] section of the JSON code.

Observera att type elementet anger strängen för en App Service-plan (det kallades för en servergrupp för länge, länge sedan) och att andra element och egenskaper fylls i med de parametrar som definierats i JSON-filen och den här resursen har inga kapslade resurser.

Anteckning

Observera också att värdet apiVersion för talar om för Azure vilken version av REST API att använda JSON-resursdefinitionen med, och det kan påverka hur resursen ska formateras i {}.

SQL Server

Klicka sedan på den SQL Server med namnet SQLServer i JSON-dispositionen.

Shows the SQL Server resource named SQLServer in the JSON Outline.

Observera följande om den markerade JSON-koden:

  • Användningen av parametrar säkerställer att de skapade resurserna namnges och konfigureras på ett sätt som gör dem konsekventa med varandra.

  • SQLServer-resursen har två kapslade resurser som var och en har ett annat värde för type.

  • De kapslade resurserna i “resources”: […], där databasen och brandväggsreglerna definieras, dependsOn har ett -element som anger resurs-ID:t för SQLServer-resursen på rotnivå. Detta meddelar Azure Resource Manager, "innan du skapar den här resursen måste den andra resursen redan finnas; och om den andra resursen definieras i mallen skapar du den först".

    Anteckning

    Detaljerad information om hur du använder funktionen finns resourceId() i Azure Resource Manager Template Functions.

  • Effekten av elementet är dependsOn att Azure Resource Manager veta vilka resurser som kan skapas parallellt och vilka resurser som måste skapas sekventiellt.

App Service-app

Nu ska vi gå vidare till själva apparna, vilket är mer komplicerat. Klicka på appen [variables('apiSiteName')] i JSON-konturen för att markera dess JSON-kod. Du kommer att märka att saker och ting blir mycket mer intressanta. För det här ändamålet ska jag prata om funktionerna en i varje:

Rotresurs

Appen är beroende av två olika resurser. Det innebär att Azure Resource Manager skapar appen först efter att både App Service-planen och SQL Server-instansen har skapats.

Shows the app dependencies on the App Service plan and the SQL Server instance.

Appinställningar

Appinställningarna definieras också som en kapslad resurs.

Shows the app settings defined as a nested resource in the JSON code.

I elementet properties för config/appsettingshar du två appinställningar i formatet "<name>" : "<value>".

  • PROJECTär en KUDU-inställning som talar om för Azure-distribution vilket projekt som ska användas i en Visual Studio projekt. Jag visar dig senare hur källkontrollen har konfigurerats, men eftersom ToDoApp-koden finns i en Visual Studio lösning för flera projekt behöver vi den här inställningen.
  • clientUrl är helt enkelt en appinställning som programkoden använder.
Anslutningssträngar

Anslutningssträngarna definieras också som en kapslad resurs.

Shows how the connection strings are defined as a nested resource in the JSON code.

I elementet properties för definieras config/connectionstringsvarje anslutningssträng också som ett name:value-par med det specifika formatet "<name>" : {"value": "…", "type": "…"}. För elementet type är möjliga värden MySql, SQLServer, SQLAzureoch Custom.

Tips

Om du vill ha en slutgiltig lista över anslutningssträngstyperna kör du följande kommando i Azure PowerShell: [Enum]::GetNames("Microsoft.WindowsAzure.Commands.Utilities.Websites.Services.WebEntities.DatabaseType")

Källkontroll

Inställningarna för källkontroll definieras också som en kapslad resurs. Azure Resource Manager använder den här resursen för att konfigurera kontinuerlig publicering (IsManualIntegrationse varning om senare) och även för att starta distributionen av programkod automatiskt under bearbetningen av JSON-filen.

Shows how the source control settings are defined as a nested resource in the JSON code.

RepoUrl och branch bör vara ganska intuitivt och peka på Git-lagringsplatsen och namnet på den gren som ska publiceras från. Dessa definieras återigen av indataparametrar.

Observera i elementet dependsOn att, förutom själva appresursen, också sourcecontrols/web är beroende av config/appsettings och config/connectionstrings. Det beror på att sourcecontrols/web när har konfigurerats försöker Azure-distributionsprocessen automatiskt distribuera, skapa och starta programkoden. Genom att infoga det här beroendet kan du därför se till att programmet har åtkomst till de appinställningar och anslutningssträngar som krävs innan programkoden körs.

Anteckning

Observera också att IsManualIntegration är inställt på true. Den här egenskapen är nödvändig i den här självstudien eftersom du inte faktiskt äger GitHub-lagringsplatsen och därför inte kan bevilja behörighet till Azure för att konfigurera kontinuerlig publicering från ToDoApp (dvs. skicka automatiska uppdateringar av lagringsplatsen till Azure). Du kan bara använda standardvärdet false för den angivna lagringsplatsen om du har konfigurerat ägarens GitHub autentiseringsuppgifter i Azure Portal tidigare. Med andra ord, om du tidigare har ställt in källkontroll till GitHub eller BitBucket för en app i Azure-portalen, med dina autentiseringsuppgifter, kommer Azure ihåg autentiseringsuppgifterna och använda dem när du distribuerar appar från GitHub eller BitBucket i framtiden. Men om du inte redan har gjort detta misslyckas distributionen av JSON-mallen när Azure Resource Manager försöker konfigurera appens inställningar för källkontroll eftersom den inte kan logga in på GitHub eller BitBucket med lagringsplatsens ägares autentiseringsuppgifter.

Jämför JSON-mallen med distribuerad resursgrupp

Här kan du gå igenom alla appens blad i Azure Portal, men det finns ett annat verktyg som är lika användbart, om inte mer. Gå till Azure Resource Explorer förhandsgranskningsverktyget, som ger dig en JSON-representation av alla resursgrupper i dina prenumerationer, eftersom de faktiskt finns i Azure-backend. Du kan också se hur resursgruppens JSON-hierarki i Azure motsvarar hierarkin i mallfilen som används för att skapa den.

När jag till exempel går till Azure Resource Explorer-verktyget och expanderar noderna i utforskaren kan jag se resursgruppen och de resurser på rotnivå som samlas in under deras respektive resurstyper.

View the resource group and root-level resources in the expanded Azure Resources Explorer tool.

Om du går nedåt i en app bör du kunna se information om appkonfigurationen som liknar skärmbilden nedan:

Drill down to view the configuration details in the app.

Återigen bör de kapslade resurserna ha en hierarki som liknar dem i JSON-mallfilen, och du bör se appinställningar, anslutningssträngar osv. som återspeglas korrekt i JSON-fönstret. Frånvaron av inställningar här kan tyda på ett problem med JSON-filen och kan hjälpa dig att felsöka JSON-mallfilen.

Distribuera resursgruppsmallen själv

Knappen Distribuera till Azure är bra, men du kan bara distribuera resursgruppmallen i azuredeploy.json om du redan har push-distribuerat azuredeploy.json till GitHub. Azure .NET SDK innehåller också verktyg som du kan använda för att distribuera valfri JSON-mallfil direkt från den lokala datorn. Följ stegen nedan för att göra detta:

  1. I Visual Studio klickar du på>ArkivNytt>Project.

  2. Klicka på Visual C#>CloudAzure-resursgrupp> och sedan på OK.

    Create a new project as an Azure Resource Group in the Azure .NET SDK.

  3. I Välj Azure-mall väljer du Tom mall och klickar på OK.

  4. Dra azuredeploy.json till mappen Mall i det nya projektet.

    Shows the result of dragging the azuredeploy.json file into the Template folder of your project.

  5. Från Solution Explorer du den kopierade azuredeploy.json-kopian.

  6. För demonstrationens skull ska vi lägga till några Application Insight-standardresurser i vår JSON-fil genom att klicka på Lägg till resurs. Om du bara är intresserad av att distribuera JSON-filen går du vidare till stegen för att distribuera.

    Shows the Add Resource button you can use to add standard Application Insight resources to your JSON file.

  7. Välj Program Insights för Web Apps och kontrollera sedan att en befintlig App Service plan och app har valts och klicka sedan på Lägg till.

    Shows the selection of Application Insights for Web Apps, Name, App Service Plan, and Web App.

    Nu kan du se flera nya resurser som, beroende på resursen och vad den gör, har beroenden av antingen App Service eller appen. De här resurserna aktiveras inte av deras befintliga definition och du kommer att ändra det.

    View the new resources that have dependencies on the App Service plan or app.

  8. I JSON-dispositionen klickar du på appInsights AutoScale för att markera dess JSON-kod. Det här är skalningsinställningen för din App Service plan.

  9. I den markerade JSON-koden letar du upp location egenskaperna enabled och och anger dem enligt nedan.

    Shows the location and enabled properties in the appInsights AutoScale JSON code and the values you should set them to.

  10. I JSON-dispositionen klickar du på CPUHög appInsights för att markera dess JSON-kod. Det här är en avisering.

  11. Leta upp location egenskaperna isEnabled och och ange dem enligt nedan. Gör samma sak för de andra tre aviseringarna (lila glödlampa).

    Shows the location and isEnabled properties in the CPUHigh appInsights JSON code and the values you should set them to.

  12. Nu är du redo att distribuera. Högerklicka på projektet och välj DistribueraNy>distribution.

    Shows how to deploy your new project.

  13. Logga in på ditt Azure-konto om du inte redan har gjort det.

  14. Välj en befintlig resursgrupp i din prenumeration eller skapa en ny, välj azuredeploy.json och klicka sedan på Redigera parametrar.

    Shows how to edit the parameters in the azuredeploy.json file.

    Nu kan du redigera alla parametrar som definierats i mallfilen i en bra tabell. Parametrar som definierar standardvärden har redan sina standardvärden, och parametrar som definierar en lista över tillåtna värden visas som listrutan.

    Shows parameters that define a list of allowed values as dropdown lists.

  15. Fyll i alla tomma parametrar och använd lagringsplatsens GitHub för ToDoApp irepoUrl. Klicka sedan på Spara.

    Shows the newly filled parameters for the azuredeploy.json file.

    Anteckning

    Autoskalning är en funktion som erbjuds på standardnivån eller högre, och aviseringar på plannivå erbjuds på Basic-nivå eller högre. Du måste ställa in SKU-parameternStandard eller Premium för att se alla dina nya App Insights-resurser lysa upp.

  16. Klicka på Distribuera. Om du har valt Spara lösenord sparas lösenordet i parameterfilen i oformaterad text. Annars uppmanas du att ange databaslösenordet under distributionsprocessen.

Klart! Nu behöver du bara gå till Azure Portal och Azure Resource Explorer för att se de nya aviseringarna och autoskalningsinställningarna som lagts till i ditt JSON-distribuerade program.

Stegen i det här avsnittet har huvudsakligen utfört följande:

  1. Förberedde mallfilen
  2. Skapat en parameterfil som ska användas med mallfilen
  3. Distribuerade mallfilen med parameterfilen

Det sista steget görs enkelt med en PowerShell-cmdlet. Om du vill Visual Studio du gjorde när programmet distribuerades öppnar du Scripts\Deploy-AzureResourceGroup.ps1. Det finns mycket kod där, men jag ska bara markera all relevant kod som du behöver för att distribuera mallfilen med parameterfilen.

Shows the pertinent code in the script that you need use to deploy the template file with the parameter file.

Den sista cmdleten, New-AzureResourceGroup, är den som faktiskt utför åtgärden. Allt detta bör visa dig att med hjälp av verktyg är det relativt enkelt att distribuera molnprogrammet förutsägbart. Varje gång du kör cmdleten på samma mall med samma parameterfil får du samma resultat.

Sammanfattning

I DevOps är repeterbarhet och förutsägbarhet nycklar till en lyckad distribution av ett storskaligt program som består av mikrotjänster. I den här självstudien har du distribuerat ett program med två mikrotjänster till Azure som en enskild resursgrupp med hjälp av Azure Resource Manager mallen. Förhoppningsvis har den gett dig den kunskap du behöver för att börja konvertera ditt program i Azure till en mall och kan etablera och distribuera det förutsägbart.

Fler resurser

Nästa steg

Mer information om JSON-syntaxen och -egenskaperna för resurstyper som distribueras i den här artikeln finns i: