Best practices voor implementatie

Artikel
06/01/2024

Notitie

Vanaf 1 juni 2024 kunnen nieuw gemaakte App Service-apps een unieke standaardhostnaam genereren die gebruikmaakt van de naamconventie <app-name>-<random-hash>.<region>.azurewebsites.net. Bestaande app-namen blijven ongewijzigd. Voorbeeld:

myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Zie Unieke standaardhostnaam voor App Service-resource voor meer informatie.

Elk ontwikkelteam heeft unieke vereisten die het implementeren van een efficiënte implementatiepijplijn voor elke cloudservice lastig maken. In dit artikel worden de drie belangrijkste onderdelen van de implementatie in App Service geïntroduceerd: implementatiebronnen, build-pijplijnen en implementatiemechanismen. Dit artikel bevat ook enkele aanbevolen procedures en tips voor specifieke taalstacks.

Implementatieonderdelen

Implementatiebron

Een implementatiebron is de locatie van uw toepassingscode. Voor productie-apps is de implementatiebron meestal een opslagplaats die wordt gehost door software voor versiebeheer, zoals GitHub, BitBucket of Azure-opslagplaatsen. Voor ontwikkelings- en testscenario's kan de implementatiebron een project op uw lokale computer zijn.

Build-pipeline

Zodra u een implementatiebron hebt gekozen, moet u een build-pijplijn kiezen. Een build-pijplijn leest uw broncode uit de implementatiebron en voert een reeks stappen uit (zoals het compileren van code, het minificeren van HTML en JavaScript, het uitvoeren van tests en verpakkingsonderdelen) om de toepassing in een uitvoerbare status op te halen. De specifieke opdrachten die door de build-pijplijn worden uitgevoerd, zijn afhankelijk van uw taalstack. Deze bewerkingen kunnen worden uitgevoerd op een buildserver, zoals Azure Pipelines, of lokaal worden uitgevoerd.

Implementatiemechanisme

Het implementatiemechanisme is de actie die wordt gebruikt om uw ingebouwde toepassing in de map /home/site/wwwroot van uw web-app te plaatsen. De map /wwwroot is een gekoppelde opslaglocatie die wordt gedeeld door alle exemplaren van uw web-app. Wanneer het implementatiemechanisme uw toepassing in deze map plaatst, ontvangen uw exemplaren een melding om de nieuwe bestanden te synchroniseren. App Service ondersteunt de volgende implementatiemechanismen:

Kudu-eindpunten: Kudu is het opensource-hulpprogramma voor ontwikkelaarsproductiviteit dat wordt uitgevoerd als een afzonderlijk proces in Windows App Service en als een tweede container in Linux App Service. Kudu verwerkt continue implementaties en biedt HTTP-eindpunten voor implementatie, zoals zipdeploy/.
FTP en WebDeploy: Met uw site- of gebruikersreferenties kunt u bestanden uploaden via FTP of WebDeploy. Deze mechanismen lopen niet door Kudu.

Implementatiehulpprogramma's zoals Azure Pipelines, Jenkins en editor-invoegtoepassingen gebruiken een van deze implementatiemechanismen.

Implementatiesites gebruiken

Gebruik waar mogelijk implementatiesites bij het implementeren van een nieuwe productie-build. Wanneer u een Standard App Service Plan-laag of beter gebruikt, kunt u uw app implementeren in een faseringsomgeving, uw wijzigingen valideren en betrouwbaarheidstests uitvoeren. Wanneer u klaar bent, kunt u uw faserings- en productiesites wisselen. Met de wisselbewerking worden de benodigde werkrolexemplaren opgewarmd zodat deze overeenkomen met uw productieschaal, waardoor downtime wordt geëlimineerd.

Code continu implementeren

Als uw project vertakkingen heeft aangewezen voor testen, QA en fasering, moet elk van deze vertakkingen continu worden geïmplementeerd in een staging-site. (Dit staat bekend als de Gitflow-ontwerp.) Hierdoor kunnen uw belanghebbenden de geïmplementeerde vertakking eenvoudig beoordelen en testen.

Continue implementatie mag nooit worden ingeschakeld voor uw productiesite. In plaats daarvan moet uw productiebranch (vaak hoofd) worden geïmplementeerd op een niet-productiesite. Wanneer u klaar bent om de basisvertakking vrij te geven, wisselt u deze in de productiesite. In plaats van te implementeren in productie, voorkomt u downtime en kunt u de wijzigingen terugdraaien door opnieuw te wisselen.

Diagram met de stroom tussen de dev-, faserings- en main-vertakkingen en de sites waarop ze zijn geïmplementeerd.

Continu containers implementeren

Voor aangepaste containers van Docker of andere containerregisters implementeert u de installatiekopieën in een staging-site en wisselt u over naar productie om downtime te voorkomen. De automatisering is complexer dan code-implementatie, omdat u de installatiekopieën naar een containerregister moet pushen en de installatiekopieëntag in de web-app moet bijwerken.

Voor elke vertakking die u wilt implementeren in een site, stelt u automatisering in om het volgende te doen voor elke doorvoering naar de vertakking.

Bouw en tag de installatiekopieën. Als onderdeel van de build-pijplijn tagt u de installatiekopieën met de git-doorvoer-id, tijdstempel of andere identificeerbare informatie. Het is raadzaam om de standaardtag 'nieuwste' niet te gebruiken. Anders is het moeilijk om te traceren welke code momenteel wordt geïmplementeerd, waardoor foutopsporing veel moeilijker wordt.
Push de getagde afbeelding. Zodra de installatiekopie is gemaakt en gelabeld, pusht de pijplijn de installatiekopie naar het containerregister. In de volgende stap haalt de implementatiesite de gelabelde installatiekopie op uit het containerregister.
Werk de implementatiesite bij met de nieuwe installatiekopieëntag. Wanneer deze eigenschap wordt bijgewerkt, wordt de site automatisch opnieuw opgestart en wordt de nieuwe containerinstallatiekopie opgehaald.

Visual gebruik van sleuf

Hieronder vindt u voorbeelden voor algemene automatiseringsframeworks.

Azure DevOps gebruiken

App Service heeft ingebouwde continue levering voor containers via het Deployment Center. Navigeer naar uw app in Azure Portal en selecteer Implementatiecentrum onder Implementatie. Volg de instructies om uw opslagplaats en vertakking te selecteren. Hiermee configureert u een DevOps-build- en release-pijplijn om uw container automatisch te bouwen, taggen en implementeren wanneer nieuwe doorvoeringen naar de geselecteerde vertakking worden gepusht.

GitHub Actions gebruiken

U kunt uw containerimplementatie ook automatiseren met GitHub Actions. Het onderstaande werkstroombestand bouwt en tagt de container met de doorvoer-id, pusht deze naar een containerregister en werkt de opgegeven web-app bij met de nieuwe installatiekopieëntag.

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 }}'

Andere automatiseringsproviders gebruiken

De stappen die eerder worden vermeld, zijn van toepassing op andere automatiseringshulpprogramma's, zoals CircleCI of Travis CI. U moet echter de Azure CLI gebruiken om de implementatiesites bij te werken met nieuwe installatiekopieëntags in de laatste stap. Als u de Azure CLI in uw automatiseringsscript wilt gebruiken, genereert u een service-principal met behulp van de volgende opdracht.

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

Meld u in uw script aan met behulp van az login --service-principalde gegevens van de principal. Vervolgens kunt az webapp config container set u de containernaam, tag, register-URL en registerwachtwoord instellen. Hieronder vindt u enkele nuttige koppelingen om uw container-CI-proces samen te stellen.

Aanmelden bij Azure CLI on Circle CI

Taalspecifieke overwegingen

Java

Gebruik de Kudu zipdeploy/ API voor het implementeren van JAR-toepassingen en wardeploy/ voor WAR-apps. Als u Jenkins gebruikt, kunt u deze API's rechtstreeks in uw implementatiefase gebruiken. Zie dit artikel voor meer informatie.

Knooppunt

Kudu voert standaard de buildstappen uit voor uw Node-toepassing (npm install). Als u een buildservice zoals Azure DevOps gebruikt, is de Kudu-build niet nodig. Als u de Kudu-build wilt uitschakelen, maakt u een app-instelling, SCM_DO_BUILD_DURING_DEPLOYMENTmet de waarde .false

.NET

Kudu voert standaard de buildstappen voor uw .NET-toepassing (dotnet build) uit. Als u een buildservice zoals Azure DevOps gebruikt, is de Kudu-build niet nodig. Als u de Kudu-build wilt uitschakelen, maakt u een app-instelling, SCM_DO_BUILD_DURING_DEPLOYMENTmet de waarde .false

Andere overwegingen bij de implementatie

Lokale cache

Azure-app Service-inhoud wordt opgeslagen in Azure Storage en wordt op een duurzame manier weergegeven als een inhoudsshare. Sommige apps hebben echter alleen een hoogwaardige, alleen-lezen inhoudsopslag nodig die ze kunnen uitvoeren met hoge beschikbaarheid. Deze apps kunnen profiteren van het gebruik van lokale cache. Lokale cache wordt niet aanbevolen voor sites voor inhoudsbeheer, zoals WordPress.

Gebruik altijd lokale cache in combinatie met implementatiesites om downtime te voorkomen. Zie deze sectie voor informatie over het gebruik van deze functies samen.

Hoog CPU- of geheugengebruik

Als uw App Service-plan meer dan 90% van de beschikbare CPU of het geheugen gebruikt, kan de onderliggende virtuele machine problemen hebben met het verwerken van uw implementatie. Wanneer dit gebeurt, schaalt u het aantal exemplaren tijdelijk op om de implementatie uit te voeren. Zodra de implementatie is voltooid, kunt u het aantal exemplaren retourneren naar de vorige waarde.

Ga naar App Service Diagnostics voor meer informatie over aanbevolen procedures om praktische best practices te vinden die specifiek zijn voor uw resource.

Navigeer naar uw web-app in Azure Portal.
Selecteer in het linkernavigatievenster problemen vaststellen en oplossen , waarmee App Service Diagnostics wordt geopend.
Kies de startpaginategel Aanbevolen procedures .
Selecteer Aanbevolen procedures voor beschikbaarheid en prestaties of aanbevolen procedures voor optimale configuratie om de huidige status van uw app te bekijken met betrekking tot deze aanbevolen procedures.

U kunt deze koppeling ook gebruiken om App Service Diagnostics rechtstreeks te openen voor uw resource: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.

Meer resources

Naslaginformatie over omgevingsvariabelen en app-instellingen

Delen via