Metodtips 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 Azure App Service: distributionskällor, byggpipelines och distributionsmekanismer. Den här artikeln beskriver även några metodtips och tips för specifika språkstackar.

Distributionskomponenter

I det här avsnittet beskrivs de tre huvudkomponenterna för distribution till App Service.

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.

Byggkedja

När du har bestämt dig för en distributionskälla är nästa steg att välja en byggprocess. En byggpipeline läser källkoden från distributionskällan och kör en serie steg för att få programmet i ett körbart tillstånd.

Stegen kan vara att kompilera kod, minimera HTML och JavaScript, köra tester och paketera komponenter. De kommandon som körs av byggpipelinen beror på den specifika språkstacken. Du kan köra dessa åtgärder på en byggserver, till exempel Azure Pipelines eller 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. Den körs 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

När det är möjligt, använd distributionsplatser när du distribuerar en ny produktionsversion. Med en Standard App Service-plan eller bättre kan du distribuera din app till en testmiljö, validera ändringarna och göra småtester. När du är klar byter du mellanlagrings- och produktionsplatser. Växlingsåtgärden värmer upp de arbetsinstanser som krävs för att matcha produktionsskalan, vilket eliminerar driftstopp.

Distribuera kod kontinuerligt

Om projektet har grenar avsedda för testning, QA och mellanlagring bör var och en av dessa grenar distribueras kontinuerligt till en mellanlagringsplats. Den här metoden kallas Gitflow-design. Den här designen gör att dina intressenter enkelt kan utvärdera och testa den utplacerade 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 leverera 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 bilden till en stagingmiljö och växlar till produktionsmiljön för att förhindra driftstopp. Automatiseringen är mer komplex än koddistribution. 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 utföra dessa uppgifter för varje incheckning till grenen.

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

Den här artikeln innehåller exempel på vanliga automatiseringsramverk.

Använda Azure DevOps

App Service har inbyggd kontinuerlig leverans för containrar via Distributionscenter. Gå till din app i Azure-portalen. Under Distribution väljer du Distributionscenter. Följ anvisningarna för att välja lagringsplats och gren. Den här metoden konfigurerar en DevOps build-and-release-pipeline för att automatiskt skapa, tagga och distribuera din container när nya incheckningar skickas till den valda grenen.

Använd GitHub Actions

Du kan också automatisera containerdistributionen med GitHub Actions. Arbetsflödesfilen bygger och taggar containern med commit-ID, pushar den till ett containrarregister och uppdaterar den specificerade webappen med den nya image-taggen.

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 ditt skript loggar du in med az login --service-principal och tillhandahåller huvudinformationen. Du kan sedan använda az webapp config container set för att ange containerns namn, tagg, register-URL och registerlösenord. Mer information finns i Så här loggar du in på Azure CLI på Circle CI.

Språkspecifika överväganden

Tänk på följande överväganden för Java-, Node- och .NET-implementeringar.

Java

Använd Kudu zipdeploy-API :et för att distribuera JAR-program. Använd wardeploy för WAR-appar. Om du använder Jenkins kan du använda dessa API:er direkt i distributionsfasen. Mer information finns i Distribuera till Azure App Service med Jenkins.

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-sammanställningen skapar du en appinställning med namnet SCM_DO_BUILD_DURING_DEPLOYMENT och värdet false.

.NÄT

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-sammanställningen skapar du en appinställning med namnet SCM_DO_BUILD_DURING_DEPLOYMENT och värdet false.

Andra distributionsöverväganden

Andra överväganden är lokal cache och hög cpu eller minne.

lokalt cacheminne

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. Mer information finns i Översikt över lokal cache i Azure App Service.

Anmärkning

Lokal cache rekommenderas inte för innehållshanteringswebbplatser som WordPress.

Använd alltid lokal cache med distributionsplatser för att förhindra driftstopp. Information om hur du använder dessa funktioner tillsammans finns i Metodtips.

Hög cpu- eller minnesanvändning

Om din App Service-plan använder över 90% av tillgänglig processor eller minne kan den underliggande virtuella datorn ha problem med att bearbeta distributionen. När den här situationen inträffar skalar du tillfälligt upp antalet instanser för att utföra distributionen. När distributionen är klar kan du returnera antalet instanser till dess tidigare värde.

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

1. Gå till din webbapp i Azure-portalen.

2. Välj Diagnostisera och lös problem i det vänstra navigeringsfältet, som öppnar App Service Diagnostics.

3. Välj Tillgänglighet och prestanda eller utforska andra alternativ, till exempel Analys av hög CPU-användning.

   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.

Relaterat innehåll

• Referens för miljövariabler och appinställningar