Best practices voor implementatie

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 Azure-app Service geïntroduceerd: implementatiebronnen, build-pijplijnen en implementatiemechanismen. Dit artikel bevat ook enkele aanbevolen procedures en tips voor specifieke taalstacks.

Implementatieonderdelen

In deze sectie worden de drie belangrijkste onderdelen beschreven voor implementatie in App Service.

Implementatiebron

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

Bouwpijplijn

Nadat u een implementatiebron hebt gekozen, is de volgende stap het kiezen van een build-pijplijn. Een build-pijplijn leest uw broncode uit de implementatiebron en voert een reeks stappen uit om de toepassing in een uitvoerbare status op te halen.

Stappen kunnen bestaan uit het compileren van code, het minificeren van HTML en JavaScript, het uitvoeren van tests en het verpakken van onderdelen. De specifieke opdrachten die door de build-pijplijn worden uitgevoerd, zijn afhankelijk van uw taalstack. U kunt deze bewerkingen uitvoeren op een buildserver, zoals Azure Pipelines, of lokaal.

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. Het wordt uitgevoerd 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 implementatieslots wanneer u een nieuwe productie-build implementeert. Met een Standard App Service-planlaag of beter kunt u uw app implementeren in een stagingomgeving, uw wijzigingen valideren en rooktesten uitvoeren. Wanneer u klaar bent, wisselt u uw faserings- en productiesites om. Met de wisselbewerking worden de benodigde werkprocessen opgewarmd om aan te sluiten bij uw productieschaal, waardoor downtime wordt geëlimineerd.

Code continu implementeren

Als uw project vertakkingen heeft die zijn aangewezen voor testen, QA en staging, moet elk van deze vertakkingen continu worden geïmplementeerd in een staging-slot. Deze benadering wordt het Gitflow-ontwerp genoemd. Met dit ontwerp kunnen uw betrokkenen de geïmplementeerde tak eenvoudig beoordelen en testen.

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

Containers continu implementeren

Voor aangepaste containers van Docker of andere containerregisters, implementeert u de containerimage in een staging-slot en rolt u deze uit naar productie om downtime te voorkomen. De automatisering is complexer dan code-implementatie. U moet de image naar een containerregister pushen en de imagetag in de webapp bijwerken.

Voor elke vertakking die u wilt implementeren in een slot, stelt u automatisering in om deze taken uit te voeren bij elke commit naar de vertakking.

1. Bouw en tag de afbeelding. Als onderdeel van de build-pijplijn tagt u de image met de git commit-ID, tijdstempel of andere identificeerbare informatie. Het is het beste om de standaardtag laatst niet te gebruiken. Anders is het moeilijk om te traceren welke code momenteel wordt geïmplementeerd, waardoor foutopsporing moeilijker wordt.
2. Upload de gelabelde afbeelding. Nadat de installatiekopie is gemaakt en gelabeld, verplaatst de pijplijn de installatiekopie naar het containerregister. In de volgende stap haalt het implementatieslot de gelabelde image op uit het containerregister.
3. Werk het implementatieslot bij met de nieuwe imagetag. Wanneer deze eigenschap wordt bijgewerkt, start de site automatisch opnieuw op en haalt de nieuwe containerafbeelding op.

Dit artikel bevat 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. Selecteer onder ImplementatieImplementatiecenter. Volg de instructies om uw opslagplaats en vertakking te selecteren. Met deze aanpak configureert u een DevOps-build- en release-pipeline om uw container automatisch te bouwen, taggen en in te zetten wanneer nieuwe commits naar uw geselecteerde branch worden gepusht.

GitHub Actions gebruiken

U kunt uw containerimplementatie ook automatiseren met GitHub Actions. Het werkstroombestand bouwt en tagt de container met de commit-ID, pusht deze naar een containerregister en werkt de opgegeven web-app bij met de nieuwe imagetag.

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 implementatieslots bij te werken met nieuwe afbeeldingtags 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-principal de belangrijkste informatie. Vervolgens kunt u az webapp config container set gebruiken om de containernaam, tag, register-URL en registerwachtwoord in te stellen. Zie Aanmelden bij de Azure CLI in Circle CI voor meer informatie.

Taalspecifieke overwegingen

Houd rekening met de volgende overwegingen voor Java-, Node- en .NET-implementaties.

Java

Gebruik de Kudu zipdeploy-API voor het implementeren van JAR-toepassingen. Gebruik wardeploy voor WAR-apps. Als u Jenkins gebruikt, kunt u deze API's rechtstreeks in uw implementatiefase gebruiken. Zie Implementeren in Azure-app Service met Jenkins 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_DEPLOYMENT, met 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_DEPLOYMENT, met de waarde false.

Andere overwegingen bij de implementatie

Andere overwegingen zijn lokale cache en hoge CPU of geheugen.

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 hoogpresterende, alleen-lezen inhoudsopslag nodig die ze kunnen gebruiken met hoge beschikbaarheid. Deze apps kunnen profiteren van het gebruik van lokale cache. Zie voor meer informatie het overzicht van de lokale cache van Azure App Service.

Gebruik altijd lokale cache met implementatieslots om downtime te voorkomen. Zie Best practices voor meer informatie over het gebruik van deze functies.

Hoog CPU- of geheugengebruik

Als uw App Service-plan meer dan 90% van de beschikbare CPU of het geheugen gebruikt, kan het zijn dat de onderliggende virtuele machine problemen heeft met het verwerken van uw implementatie. Wanneer deze situatie zich voordoet, kunt u het aantal exemplaren tijdelijk omhoog schalen om de implementatie uit te voeren. Nadat de implementatie is voltooid, kunt u het aantal exemplaren retourneren naar de vorige waarde.

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

1. Navigeer naar de web-app in het Azure portal.

2. Selecteer Diagnose en los problemen op in de linkernavigatiebalk, waarmee App Service Diagnostics wordt geopend.

3. Kies Beschikbaarheid en prestaties of verken andere opties, zoals Een hoge CPU-analyse.

   Bekijk de huidige status van uw app 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.

Gerelateerde inhoud

• Naslaginformatie over omgevingsvariabelen en app-instellingen