Bästa metoder för distribution

Varje utvecklingsteam har unika krav som kan göra det svårt att implementera en effektiv distributionspipeline för alla molntjänster. Den här artikeln beskriver de tre huvudkomponenterna i distributionen till App Service: distributionskällor, byggpipelines och distributionsmekanismer. Den här artikeln beskriver även några metodtips och tips för specifika språkstackar.

Distributionskomponenter

Distributionskälla

En distributionskälla är platsen för programkoden. För produktionsappar är distributionskällan vanligtvis en lagringsplats som hanteras av programvara för versionskontroll, till exempel GitHub, BitBucket eller Azure Repos. För utvecklings- och testscenarier kan distributionskällan vara ett projekt på den lokala datorn.

Bygg-pipeline

När du har bestämt dig för en distributionskälla är nästa steg att välja en bygg-pipeline. En byggpipeline läser källkoden från distributionskällan och kör en serie steg (till exempel kompilering av kod, minifiera HTML och JavaScript, köra tester och paketeringskomponenter) för att få programmet i ett körbart tillstånd. De specifika kommandon som körs av bygg-pipelinen beror på din språkstack. Dessa åtgärder kan köras på en byggserver, till exempel Azure Pipelines, eller köras lokalt.

Distributionsmekanism

Distributionsmekanismen är den åtgärd som används för att placera ditt inbyggda program i katalogen /home/site/wwwroot i webbappen. Katalogen /wwwroot är en monterad lagringsplats som delas av alla instanser av webbappen. När distributionsmekanismen placerar ditt program i den här katalogen får dina instanser ett meddelande om att synkronisera de nya filerna. App Service stöder följande distributionsmekanismer:

• Kudu-slutpunkter: Kudu är produktivitetsverktyget för utvecklare med öppen källkod som körs som en separat process i Windows App Service och som en andra container i Linux App Service. Kudu hanterar kontinuerliga distributioner och tillhandahåller HTTP-slutpunkter för distribution, till exempel zipdeploy/.
• FTP och WebDeploy: Med din webbplats eller dina användarautentiseringsuppgifter kan du ladda upp filer via FTP eller WebDeploy. Dessa mekanismer går inte igenom Kudu.

Distributionsverktyg som Azure Pipelines, Jenkins och redigeringsprogram använder någon av dessa distributionsmekanismer.

Använda distributionsfack

Använd distributionsplatser när det är möjligt när du distribuerar en ny produktionsversion. När du använder en Standard App Service-plannivå eller bättre kan du distribuera din app till en mellanlagringsmiljö, verifiera ändringarna och göra röktester. När du är klar kan du byta mellanlagrings- och produktionsfack. Växlingsåtgärden värmer upp de nödvändiga arbetsinstanserna så att de matchar produktionsskalan, vilket eliminerar driftstopp.

Distribuera kod kontinuerligt

Om projektet har utsett grenar för testning, QA och mellanlagring bör var och en av dessa grenar distribueras kontinuerligt till ett mellanlagringsfack. (Detta kallas för Gitflow-design.) På så sätt kan dina intressenter enkelt utvärdera och testa den distribuerade grenen.

Kontinuerlig distribution bör aldrig aktiveras för din produktionsplats. I stället bör din produktionsgren (ofta huvudgren) distribueras till en icke-produktionsplats. När du är redo att släppa basgrenen byter du ut den till produktionsplatsen. Om du byter till produktion – i stället för att distribuera till produktion – förhindrar du stilleståndstid och gör att du kan återställa ändringarna genom att byta igen.

Distribuera containrar kontinuerligt

För anpassade containrar från Docker eller andra containerregister distribuerar du avbildningen till ett mellanlagringsfack och byter till produktion för att förhindra driftstopp. Automatiseringen är mer komplex än koddistribution eftersom du måste skicka avbildningen till ett containerregister och uppdatera avbildningstaggen på webbappen.

För varje gren som du vill distribuera till ett fack konfigurerar du automatisering för att göra följande för varje incheckning till grenen.

1. Skapa och tagga avbildningen. Som en del av bygg-pipelinen taggar du avbildningen med git-inchecknings-ID, tidsstämpel eller annan identifierbar information. Det är bäst att inte använda standardtaggen "senaste". Annars är det svårt att spåra vilken kod som för närvarande distribueras, vilket gör felsökningen mycket svårare.
2. Push-överför den taggade bilden. När avbildningen har skapats och taggats skickar pipelinen avbildningen till vårt containerregister. I nästa steg hämtar distributionsfacket den taggade avbildningen från containerregistret.
3. Uppdatera distributionsfacket med den nya avbildningstaggen. När den här egenskapen uppdateras startar webbplatsen automatiskt om och hämtar den nya containeravbildningen.

Det finns exempel nedan för vanliga automatiseringsramverk.

Använda Azure DevOps

App Service har inbyggd kontinuerlig leverans för containrar via Distributionscenter. Gå till din app i Azure-portalen och välj Distributionscenter under Distribution. Följ anvisningarna för att välja lagringsplats och gren. Detta konfigurerar en DevOps-bygg- och versionspipeline för att automatiskt skapa, tagga och distribuera din container när nya incheckningar skickas till den valda grenen.

Använda GitHub Actions

Du kan också automatisera containerdistributionen med GitHub Actions. Arbetsflödesfilen nedan skapar och taggar containern med inchecknings-ID:t, push-överför den till ett containerregister och uppdaterar den angivna webbappen med den nya avbildningstaggen.

on:
  push:
    branches:
    - <your-branch-name>

name: Linux_Container_Node_Workflow

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    # checkout the repo
    - name: 'Checkout GitHub Action'
      uses: actions/checkout@main

    - uses: azure/docker-login@v1
      with:
        login-server: contoso.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}

    - run: |
        docker build . -t contoso.azurecr.io/nodejssampleapp:${{ github.sha }}
        docker push contoso.azurecr.io/nodejssampleapp:${{ github.sha }} 

    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'node-rnc'
        publish-profile: ${{ secrets.azureWebAppPublishProfile }}
        images: 'contoso.azurecr.io/nodejssampleapp:${{ github.sha }}'

Använda andra automationsprovidrar

Stegen som anges tidigare gäller för andra automatiseringsverktyg som CircleCI eller Travis CI. Du måste dock använda Azure CLI för att uppdatera distributionsplatserna med nya avbildningstaggar i det sista steget. Om du vill använda Azure CLI i automationsskriptet genererar du ett huvudnamn för tjänsten med hjälp av följande kommando.

az ad sp create-for-rbac --name "myServicePrincipal" --role contributor \
   --scopes /subscriptions/{subscription}/resourceGroups/{resource-group} \
   --sdk-auth

I skriptet loggar du in med hjälp av az login --service-principaloch anger huvudnamnets information. Du kan sedan använda az webapp config container set för att ange containerns namn, tagg, register-URL och registerlösenord. Nedan visas några användbara länkar som du kan använda för att konstruera din CI-containerprocess.

• Logga in på Azure CLI på Circle CI

Språkspecifika överväganden

Java

Använd Kudu zipdeploy/ API för att distribuera JAR-program och wardeploy/ för WAR-appar. Om du använder Jenkins kan du använda dessa API:er direkt i distributionsfasen. Mer information finns i denna artikel.

Nod

Som standard kör Kudu byggstegen för node-programmet (npm install). Om du använder en byggtjänst som Azure DevOps är Kudu-versionen onödig. Om du vill inaktivera Kudu-versionen skapar du en appinställning, , SCM_DO_BUILD_DURING_DEPLOYMENTmed värdet false.

.NET

Som standard kör Kudu byggstegen för ditt .NET-program (dotnet build). Om du använder en byggtjänst som Azure DevOps är Kudu-versionen onödig. Om du vill inaktivera Kudu-versionen skapar du en appinställning, , SCM_DO_BUILD_DURING_DEPLOYMENTmed värdet false.

Andra distributionsöverväganden

Lokal cache

Azure App Service-innehåll lagras i Azure Storage och visas på ett hållbart sätt som en innehållsresurs. Vissa appar behöver dock bara ett skrivskyddat innehållsarkiv med höga prestanda som de kan köra med hög tillgänglighet. Dessa appar kan dra nytta av att använda lokal cache. Lokal cache rekommenderas inte för innehållshanteringswebbplatser som WordPress.

Använd alltid lokal cache tillsammans med distributionsplatser för att förhindra stilleståndstid. Se det här avsnittet för information om hur du använder dessa funktioner tillsammans.

Hög CPU- eller minnesanvändning

Om apptjänstplanen använder över 90 % av den tillgängliga processorn eller minnet kan den underliggande virtuella datorn ha problem med att bearbeta distributionen. När detta inträffar skalar du tillfälligt upp antalet instanser för att utföra distributionen. När distributionen är klar kan du returnera instansantalet till dess tidigare värde.

Mer information om metodtips finns i App Service Diagnostics för att ta reda på lämpliga metodtips som är specifika för din resurs.

• Gå till din webbapp i Azure-portalen.
• Välj i Diagnostisera och lös problem i det vänstra navigeringsfältet, som öppnar App Service Diagnostics.
• Välj panelen Metodtips på startsidan.
• Välj Metodtips för tillgänglighet och prestanda eller metodtips för optimal konfiguration för att visa appens aktuella tillstånd när det gäller dessa metodtips.

Du kan också använda den här länken för att öppna App Service Diagnostics för din resurs direkt: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.

Fler resurser

Referens för miljövariabler och appinställningar