Dela via

Bästa metoder för distribution

  • Artikel

Kommentar

Från och med den 1 juni 2024 kan nyligen skapade App Service-appar generera ett unikt standardvärdnamn som använder namngivningskonventionen <app-name>-<random-hash>.<region>.azurewebsites.net. Befintliga appnamn förblir oförändrade. Till exempel:

myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Mer information finns i Unikt standardvärdnamn för App Service-resurs.

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.

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 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 specifika kommandon som körs av bygg-pipelinen beror på din språkstack. 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änder du distributionsfack när det är möjligt när du distribuerar en ny produktionsversion. Med 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 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. Med den här designen 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.

Diagram som visar flödet mellan grenarna Dev, Staging och Main och de platser som de distribueras till.

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. 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. 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 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 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.

Diagrammet visar det visuella platsanvändningsobjektet som representerar grenarna Webbapp, Container Registry och lagringsplats.

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 Portal. 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ända GitHub Actions

Du kan också automatisera containerdistributionen med GitHub Actions. Arbetsflödesfilen skapar och taggar containern med inchecknings-ID:t, skickar 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 och az login --service-principalanger 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-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

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

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

Kommentar

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 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 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 webbappen i Azure Portal.

  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