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 för distribution till Serviço de Aplicativo: distributionskällor, bygg-pipelines och distributionsmekanismer. Den här artikeln beskriver också några metodtips och tips för specifika språkstackar.
Distributionskomponenter
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. Serviço de Aplicativo stöder även OneDrive- och Dropbox-mappar som distributionskällor. Molnmappar kan göra det enkelt att komma igång med Serviço de Aplicativo, men det rekommenderas vanligtvis inte att använda den här källan för produktionsprogram på företagsnivå.
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 bygg-pipeline läser källkoden från distributionskällan och kör en serie steg (som att kompilera kod, minimera HTML och JavaScript, köra tester och paketera komponenter) för att få programmet i ett körbart tillstånd. De specifika kommandon som körs av bygg-pipelinen beror på din språkstack. Dessa åtgärder kan köras på en byggserver, till exempel Azure Pipelines, eller köras lokalt.
Distributionsmekanism
Distributionsmekanismen är den åtgärd som används för att placera det inbyggda programmet i katalogen /home/site/wwwroot för 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. Serviço de Aplicativo stöder följande distributionsmekanismer:
- Kudu-slutpunkter: Kudu är utvecklarproduktivitetsverktyget med öppen källkod som körs som en separat process i Windows Serviço de Aplicativo och som en andra container i Linux Serviço de Aplicativo. 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 plugin-program för redigeringsprogram använder någon av dessa distributionsmekanismer.
Använda distributionsfack
När det är möjligt kan du använda distributionsfack när du distribuerar en ny produktionsversion. När du använder en Standard Serviço de Aplicativo-plannivå eller bättre kan du distribuera appen till en mellanlagringsmiljö, validera ändringarna och göra röktester. När du är klar kan du växla mellanlagrings- och produktionsplatser. Växlingsåtgärden värmer upp de nödvändiga arbetsinstanserna så att de matchar produktionsskalan, vilket eliminerar stilleståndstiden.
Distribuera kod kontinuerligt
Om ditt projekt har utsett grenar för testning, kvalitetskontroll och mellanlagring bör var och en av dessa grenar distribueras kontinuerligt till en mellanlagringsplats. (Detta kallas Gitflow-design.) På så sätt kan dina intressenter enkelt utvärdera och testa den distribuerade grenen.
Kontinuerlig distribution bör aldrig aktiveras för produktionsplatsen. I stället bör din produktionsgren (ofta huvudgren) distribueras till en icke-produktionsplats. När du är redo att släppa basgrenen växlar du den till produktionsplatsen. Om du byter till produktion , i stället för att distribuera till produktion, förhindrar du driftstopp och gör att du kan återställa ändringarna genom att växla igen.
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 eftersom du måste skicka avbildningen till ett containerregister och uppdatera avbildningstaggen på webbappen.
För varje gren som du vill distribuera till en plats konfigurerar du automation för att göra följande för varje incheckning till -grenen.
- 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 standardtaggen "senaste". Annars är det svårt att spåra vilken kod som för närvarande distribueras, vilket gör felsökningen mycket svårare.
- Push-överför den taggade bilden. När avbildningen har skapats och taggats skickar pipelinen avbildningen till vårt containerregister. I nästa steg hämtar distributionsfacket den taggade avbildningen från containerregistret.
- Uppdatera distributionsfacket med den nya avbildningstaggen. När den här egenskapen uppdateras startar webbplatsen automatiskt om och hämtar den nya containeravbildningen.
Det finns exempel nedan för vanliga automatiseringsramverk.
Använda Azure DevOps
Serviço de Aplicativo har inbyggd kontinuerlig leverans för containrar via Distributionscenter. Gå till din app i Azure-Portal och välj Distributionscenter under Distribution. Följ anvisningarna för att välja lagringsplats och gren. Detta konfigurerar en DevOps-bygg- och versionspipeline 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 nedan skapar och taggar containern med inchecknings-ID:t, push-överför den till ett containerregister och uppdaterar det angivna platsfacket med den nya avbildningstaggen.
name: Build and deploy a container image to Azure Web Apps
on:
push:
branches:
- <your-branch-name>
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@main
-name: Authenticate using a Service Principal
uses: azure/actions/login@v1
with:
creds: ${{ secrets.AZURE_SP }}
- uses: azure/container-actions/docker-login@v1
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_PASSWORD }}
- name: Build and push the image tagged with the git commit hash
run: |
docker build . -t contoso/demo:${{ github.sha }}
docker push contoso/demo:${{ github.sha }}
- name: Update image tag on the Azure Web App
uses: azure/webapps-container-deploy@v1
with:
app-name: '<your-webapp-name>'
slot-name: '<your-slot-name>'
images: 'contoso/demo:${{ github.sha }}'
Använda andra automationsleverantörer
Stegen som angavs 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 ditt automatiseringsskript 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 hjälp av az login --service-principaloch anger huvudkontots information. Du kan sedan använda az webapp config container set för att ange containernamn, tagg, register-URL och registerlösenord. Nedan visas några användbara länkar som du kan använda för att skapa ci-processen för containern.
Language-Specific överväganden
Java
Använd Kudu zipdeploy/ API för att distribuera JAR-program och wardeploy/ för WAR-appar. Om du använder Jenkins kan du använda dessa API:er direkt i distributionsfasen. Mer information finns i den här artikeln.
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_DEPLOYMENT, med 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_DEPLOYMENT, med värdet false.
Andra distributionsöverväganden
Lokal cache
Служба приложений Azure innehåll lagras i Azure Storage och visas på ett hållbart sätt som en innehållsresurs. Men vissa appar behöver 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. Lokal cache rekommenderas inte för webbplatser för innehållshantering, till exempel WordPress.
Använd alltid lokal cache tillsammans med distributionsfack för att förhindra driftstopp. Se det här avsnittet för information om hur du använder dessa funktioner tillsammans.
Hög CPU- eller minnesanvändning
Om din Serviço de Aplicativo-plan använder över 90 % av den tillgängliga processorn eller minnet kan den underliggande virtuella datorn ha problem med att bearbeta distributionen. När detta 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 om metodtips finns i Serviço de Aplicativo Diagnostik för att ta reda på användbara metodtips som är specifika för din resurs.
- Gå till webbappen i Azure-Portal.
- Klicka på Diagnostisera och lösa problem i det vänstra navigeringsfältet, som öppnas Serviço de Aplicativo Diagnostik.
- Välj panelen Metodtips för startsidan.
- Klicka på Metodtips för tillgänglighetsprestanda & eller Metodtips för optimal konfiguration för att visa appens aktuella tillstånd i fråga om dessa metodtips.
Du kan också använda den här länken för att öppna Serviço de Aplicativo Diagnostik direkt för din resurs: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.