Delen via

Aanbevolen best practices voor implementatie

  • Artikel

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

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

Wanneer u een nieuwe productie-build implementeert, gebruikt u waar mogelijk implementatiesites. Met een standard App Service-planlaag of beter kunt u uw app implementeren in een faseringsomgeving, uw wijzigingen valideren en betrouwbaarheidstests uitvoeren. Wanneer u klaar bent, wisselt u uw faserings- en productiesites om. 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 die zijn aangewezen voor testen, QA en fasering, moet elk van deze vertakkingen continu worden geïmplementeerd in een staging-site. Deze benadering wordt het Gitflow-ontwerp genoemd. Met dit ontwerp 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. 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.

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. U moet de installatiekopieën naar een containerregister pushen en de installatiekopieëntag in de web-app bijwerken.

Voor elke vertakking die u wilt implementeren in een site, stelt u automatisering in om deze taken uit te voeren voor elke doorvoering naar de vertakking.

  1. 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. U kunt het beste niet de meest recente standaardtag gebruiken. Anders is het moeilijk om te traceren welke code momenteel wordt geïmplementeerd, waardoor foutopsporing moeilijker wordt.
  2. Push de getagde afbeelding. Nadat 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.
  3. 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.

Diagram toont de visual sitegebruik die web-app-, containerregister- en opslagplaatsvertakkingen vertegenwoordigt.

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 methode 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 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 principal-informatie. Vervolgens kunt az webapp config container set u de containernaam, tag, register-URL en registerwachtwoord instellen. 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_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

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 hoogwaardige, alleen-lezen inhoudsopslag nodig die ze kunnen uitvoeren met hoge beschikbaarheid. Deze apps kunnen profiteren van het gebruik van lokale cache. Zie het overzicht Azure-app Lokale cache van de service voor meer informatie.

Notitie

Lokale cache wordt niet aanbevolen voor sites voor inhoudsbeheer, zoals WordPress.

Gebruik altijd lokale cache met implementatiesites 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 uw web-app in 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