Distribuera Python-webbappar till App Service med hjälp av GitHub Actions (Linux)

Den här artikeln beskriver hur du använder ci/CD-plattformen (continuous integration and continuous delivery) i GitHub Actions för att distribuera en Python-webbapp till Azure App Service i Linux. Ditt GitHub Actions-arbetsflöde bygger automatiskt koden och distribuerar den till App Service-instansen vid varje incheckning i lagringsplatsen. Du kan lägga till annan automatisering i ditt GitHub Actions-arbetsflöde, till exempel testskript, säkerhetskontroller och distribution av flera funktioner.

Skapa lagringsplats för appkod

För att slutföra procedurerna i den här artikeln behöver du en Python-webbapp som har checkats in på en GitHub-lagringsplats.

• Befintlig app: Om du vill använda en befintlig Python-webbapp kontrollerar du att appen har checkats in på en GitHub-lagringsplats.

• Ny app: Om du behöver en ny Python-webbapp kan du förgrena https://github.com/Microsoft/python-sample-vscode-flask-tutorial och klona GitHub-lagringsplatsen. Exempelkoden stöder handledningen Flask i Visual Studio Code och tillhandahåller en fungerande Python-applikation.

Skapa en App Service-målinstans

Det snabbaste sättet att skapa en App Service-instans är att använda Azures kommandoradsgränssnitt (CLI) via det interaktiva Azure Cloud Shell. Cloud Shell innehåller Git och Azure CLI. I följande procedur använder du kommandot az webapp up för att både skapa App Service-instansen och göra den första distributionen av din app.

1. Logga in på Azure Portal på https://portal.azure.com.

2. Öppna Azure CLI genom att välja alternativet Cloud Shell i portalens verktygsfält:

   

3. I Cloud Shell väljer du bash-alternativet på den nedrullningsbara menyn:

   

4. I Cloud Shell klonar du lagringsplatsen med hjälp av git-kloningskommandot .

   Tips/Råd

   Om du vill klistra in kommandon eller text i Cloud Shell använder du kortkommandot Ctrl+Skift+V eller högerklickar och väljer Klistra in på snabbmenyn.

   • För Flask-exempelappen kan du använda följande kommando. Ersätt <github-user>-delen med namnet på det GitHub-konto där du förgrenade lagringsplatsen.

     git clone https://github.com/<github-user>/python-sample-vscode-flask-tutorial.git
     

   • Om din app finns på en annan lagringsplats konfigurerar du GitHub Actions för den specifika lagringsplatsen. <github-user> Ersätt delen med namnet på det GitHub-konto där du förgrenade lagringsplatsen och ange det faktiska lagringsplatsens namn i <repo-name> platshållaren:

     git clone https://github.com/<github-user>/<repo-name>.git
     

   Anmärkning

   Cloud Shell backas upp av ett Azure Storage-konto i en resursgrupp med namnet cloud-shell-storage-your-region<>. Lagringskontot innehåller en bild av Cloud Shell-filsystemet som lagrar den klonade lagringsplatsen. Det finns en liten kostnad för det här lagringsutrymmet. Du kan ta bort lagringskontot när du har slutfört den här artikeln, tillsammans med andra resurser som du skapar.

5. I Cloud Shell ändrar du katalogen till lagringsplatsmappen för din Python-app, så kommandot az webapp up identifierar appen som Python. För Flask-exempelappen använder du följande kommando:

   cd python-sample-vscode-flask-tutorial
   

6. I Cloud Shell använder du kommandot az webapp up för att skapa en App Service-instans och göra den första distributionen för din app:

   az webapp up --name <app-service-name> --runtime "PYTHON:3.9"
   

   • <app-service-name> För platshållaren anger du ett App Service-namn som är unikt i Azure. Namnet måste vara 3–60 tecken långt och får endast innehålla bokstäver, siffror och bindestreck. Namnet måste börja med en bokstav och sluta med en bokstav eller siffra.

   • Om du vill ha en lista över tillgängliga körmiljöer i systemet använder du kommandot az webapp list-runtimes.

   • När du anger körningsvärdet i kommandot använder du PYTHON:X.Y formatet, där X.Y är Python-huvudversionen och delversionen.

   • Du kan också ange regionplatsen för App Service-instansen med hjälp av parametern --location . Använd kommandot az account list-locations --output table för att få en lista över tillgängliga platser.

7. Om din app har ett anpassat startskript använder du kommandot az webapp config för att initiera skriptet.

   • Om din app inte har något anpassat startskript fortsätter du till nästa steg.

   • För Flask-exempelappen måste du komma åt startskriptet i filenstartup.txt genom att köra följande kommando:

     az webapp config set \
        --resource-group <resource-group-name> \
        --name <app-service-name> \
        --startup-file startup.txt
     

     Ange resursgruppens namn och App Service-instansens namn i <resource-group-name> och <app-service-name> platshållare. Om du vill hitta resursgruppens namn kontrollerar du utdata från föregående az webapp up kommando. Resursgruppens namn innehåller Azure-kontonamnet följt av suffixet _rg , som i <azure-account-name>_rg_.

8. Om du vill visa appen som körs öppnar du en webbläsare och går till distributionsslutpunkten för din App Service-instans. Ersätt platshållaren med apptjänstens instansnamn i följande URL <app-service-name> :

   http://<app-service-name>.azurewebsites.net
   

   Om du ser en allmän sida väntar du några sekunder på att App Service-instansen ska starta och uppdaterar sidan.

   • Om du fortsätter att se en allmän sida bekräftar du att du har distribuerat från rätt mapp.
   • För Flask-exempelappen bekräftar du att du har distribuerat från mappen python-sample-vscode-flask-tutorial . Kontrollera också att du har angett startkommandot korrekt.

Konfigurera kontinuerlig distribution i App Service

I nästa procedur konfigurerar du kontinuerlig leverans (CD), vilket innebär att en ny koddistribution sker när ett arbetsflöde utlöses. Utlösaren i artikelexemplet är en ändring av huvudgrenen för lagringsplatsen, till exempel med en pull-begäran (PR).

1. I Cloud Shell bekräftar du att du är i rotkatalogen för systemet (~) och inte i en appundermapp, till exempel python-sample-vscode-flask-tutorial.

2. Lägg till GitHub Actions med kommandot az webapp deployment github-actions add . Ersätt eventuella platshållare med dina specifika värden:

   az webapp deployment github-actions add \
     --repo "<github-user>/<github-repo>" \
     --resource-group <resource-group-name> \
     --branch <branch-name> \
     --name <app-service-name> \
     --login-with-github
   

   • Parametern --login-with-github använder en interaktiv metod för att hämta en personlig åtkomsttoken. Följ anvisningarna och slutför autentiseringen.

   • Om systemet stöter på en befintlig arbetsflödesfil med samma App Service-instansnamn följer du anvisningarna för att välja om arbetsflödet ska skrivas över. Du kan använda parametern --force med kommandot för att automatiskt skriva över eventuella motstridiga arbetsflöden.

   Kommandot add slutför följande uppgifter:

   • Skapar en ny arbetsflödesfil på .github/workflows/<workflow-name>.yml sökväg på lagringsplatsen. Filnamnet innehåller namnet på din App Service-instans.
   • Hämtar en publiceringsprofil med hemligheter för din App Service-instans och lägger till den som en GitHub-åtgärdshemlighet. Namnet på hemligheten börjar med AZUREAPPSERVICE_PUBLISHPROFILE_. Den här hemligheten refereras till i arbetsflödesfilen.

3. Hämta information om en distributionskonfiguration för källkontroll med kommandot az webapp deployment source show . Ersätt platshållarparametrarna med dina specifika värden:

   az webapp deployment source show \
     --name <app-service-name> \
     --resource-group <resource-group-name>
   

4. Bekräfta värdena för egenskaperna repoUrl och branch i kommandots utdata. Dessa värden ska matcha de värden som du angav med add kommandot .

Granska GitHub-arbetsflöde och åtgärder

En arbetsflödesdefinition anges i en YAML-fil (.yml) i sökvägen /.github/workflows/ i lagringsplatsen. Den här YAML-filen innehåller de olika steg och parametrar som utgör arbetsflödet, en automatiserad process som är associerad med en GitHub-lagringsplats. Du kan skapa, testa, paketera, släppa och distribuera alla projekt på GitHub med ett arbetsflöde.

Varje arbetsflöde består av ett eller flera jobb och varje jobb är en uppsättning steg. Varje steg är ett gränssnittsskript eller en åtgärd. Varje jobb har ett åtgärdsavsnitt i arbetsflödesfilen.

När det gäller arbetsflödet som konfigurerats med din Python-kod för distribution till Azure App Service har arbetsflödet följande åtgärder:

Arbetsflödesmallen som används för att skapa arbetsflödet är Azure/actions-workflow-samples.

Arbetsflödet utlöses vid push-händelser till den angivna grenen. Händelsen och grenen definieras i början av arbetsflödesfilen. Följande kodfragment visar till exempel att arbetsflödet utlöses vid push-händelser till huvudgrenen :

on:
  push:
    branches:
    - main

OAuth-auktoriserade appar

När du konfigurerar kontinuerlig distribution godkänner du Azure App Service som en auktoriserad OAuth-app för ditt GitHub-konto. App Service använder den auktoriserade åtkomsten för att skapa en YAML-fil för GitHub-åtgärder på sökvägen .github/workflows/<workflow-name>.yml i ditt repo.

Om du vill se dina auktoriserade appar och återkalla behörigheter under dina GitHub-konton går du till Inställningar>Integrations/Program:

Publicera profilhemlighet för arbetsflöde

I .github/workflows/<workflow-name>.yml arbetsflödesfilen som lagts till i ditt repo finns det en platshållare för publiceringsprofilens autentiseringsuppgifter som krävs för arbetsflödets distributionsjobb. Publiceringsprofilinformationen lagras krypterad på lagringsplatsen.

Om du vill visa hemligheten går du till Inställningar>Säkerhetshemlighet>och variabler>Åtgärder:

I den här artikeln autentiserar sig GitHub-åtgärden med autentiseringsuppgifter för en publiceringsprofil. Det finns andra sätt att autentisera, till exempel med tjänstens huvudnamn eller OpenID Connect. Mer information finns i Distribuera till App Service med GitHub Actions.

Kör och testa arbetsflöde

Det sista steget är att testa arbetsflödet genom att göra en ändring i lagringsplatsen.

1. I en webbläsare går du till din förgrening av exempellagringsplatsen (eller lagringsplatsen du använde) och väljer den gren som du anger som en del av utlösaren:

   

2. Gör en liten ändring i python-webbappen.

   I Flask-självstudien, här är en enkel ändring:

   1. Gå till filen /hello-app/templates/home.html för utlösargrenen.
   2. Välj Redigera (penna).
   3. Leta upp utskriftsuttrycket <p> i redigeraren och lägg till texten "Omdistribuerad!"

3. Kommittera förändringen direkt till grenen du arbetar i.

   1. I redigeraren väljer du Checka in ändringar längst upp till höger. Fönstret Genomför ändringar öppnas.
   2. I fönstret Genomför ändringar ändrar du incheckningsmeddelandet efter behov och väljer Genomför ändringar.

   Incheckningsprocessen utlöser GitHub Actions-arbetsflödet.

Du kan också utlösa arbetsflödet manuellt:

1. Gå till fliken Åtgärder i lagringsplatsen som konfigurerats för kontinuerlig distribution.

2. Välj arbetsflödet i listan över arbetsflöden och välj sedan Kör arbetsflöde.

Felsöka misslyckat arbetsflöde

Du kan kontrollera statusen för ett arbetsflöde på fliken Åtgärder för app-lagringsplatsen. När du undersöker arbetsflödesfilen som skapades i den här artikeln visas två jobb: skapa och distribuera. Som en påminnelse baseras arbetsflödet på mallen Azure/actions-workflow-samples .

För ett misslyckat jobb kan du titta på utdata från jobbaktiviteter för att få en indikation på felet.

Här följer några vanliga problem att undersöka:

• Om appen misslyckas på grund av ett beroende som saknas bearbetas inte din requirements.txt fil under distributionen. Det här beteendet inträffar om du har skapat webbappen direkt på portalen i stället för att använda az webapp up kommandot som du ser i den här artikeln.

• Om du har etablerat apptjänsten via portalen kanske inte inställningen för byggåtgärden SCM_DO_BUILD_DURING_DEPLOYMENT har angetts. Den här inställningen måste vara inställd på true. Kommandot az webapp up anger byggåtgärden automatiskt.

• Om du ser ett felmeddelande om tidsgränsen för TLS-handskakning kör du arbetsflödet manuellt genom att välja Utlösa automatisk distribution på fliken Åtgärder på app-lagringsplatsen. Du kan avgöra om tidsgränsen är ett tillfälligt problem.

• Om du konfigurerar kontinuerlig distribution för containerappen enligt den här artikeln skapas den första arbetsflödesfilen .github/workflows/<workflow-name>.yml automatiskt åt dig. Om du har ändrat filen tar du bort ändringarna för att se om de orsakar felet.

Kör skript efter distributionen

Ett skript efter distributionen kan utföra flera uppgifter, till exempel att definiera miljövariabler som förväntas av appkoden. Du lägger till skriptet som en del av appkoden och kör skriptet med hjälp av startkommandot.

Om du vill undvika hårdkodade variabelvärden i yaml-filen för arbetsflödet kan du överväga att konfigurera variablerna i GitHub och referera till variabelnamnen i skriptet. Du kan skapa krypterade hemligheter för en lagringsplats eller för en miljö (kontolagringsplats). Mer information finns i Använda hemligheter i GitHub Actions.

Granska Överväganden för Django

Som tidigare nämnts i den här artikeln kan du använda GitHub Actions för att distribuera Django-appar till Azure App Service i Linux om du använder en separat databas. Du kan inte använda en SQLite-databas eftersom App Service låser filen db.sqlite3 , vilket förhindrar både läsningar och skrivningar. Det här beteendet påverkar inte en extern databas.

Artikeln Konfigurera Python-app på App Service – Startprocess för container beskriver hur App Service automatiskt letar efter en wsgi.py fil i din appkod, som vanligtvis innehåller appobjektet. När du använde webapp config set kommandot för att ange startkommandot använde du parametern --startup-file för att ange filen som innehåller appobjektet. Kommandot webapp config set är inte tillgängligt i åtgärden webapps-deploy. I stället kan du använda parametern startup-command för att ange startkommandot. Följande kod visar till exempel hur du anger startkommandot i arbetsflödesfilen:

startup-command: startup.txt

När du använder Django vill du vanligtvis migrera datamodellerna med hjälp python manage.py migrate av kommandot när du har distribuerat appkoden. Du kan köra kommandot migrering i ett skript efter distributionen.

Inaktivera GitHub Actions

Genom att koppla bort GitHub Actions från din App Service-instans kan du omkonfigurera appdistributionen. Du kan välja vad som händer med arbetsflödesfilen när du har kopplat från och om du vill spara eller ta bort filen.

az webapp deployment github-actions remove \
  --repo "<github-username>/<github-repo>" \
  --resource-group <resource-group-name> \
  --branch <branch-name> \
  --name <app-service-name> \
  --login-with-github

Rensa resurser

Om du vill undvika att debiteras för de Azure-resurser som skapas i den här artikeln tar du bort resursgruppen som innehåller App Service-instansen och App Service-planen.

az group delete --name <resource-group-name>

Ta bort lagringskonto

Om du vill ta bort lagringskontot som underhåller filsystemet för Cloud Shell, som medför en liten månatlig avgift, tar du bort resursgruppen som börjar med cloud-shell-storage-. Om du är den enda användaren i gruppen är det säkert att ta bort resursgruppen. Om det finns andra användare kan du ta bort ett lagringskonto i resursgruppen.

Uppdatera GitHub-konto och lagringsplats

Om du tar bort Azure-resursgruppen kan du överväga att göra följande ändringar i GitHub-kontot och lagringsplatsen som var ansluten för kontinuerlig distribution:

• I applagringsplatsen tar du bort filen .github/workflows/<workflow-name>.yml .
• I inställningarna för applagringsplatsen tar du bort den AZUREAPPSERVICE_PUBLISHPROFILE_ hemlighetsnyckel som skapats för arbetsflödet.
• I inställningarna för GitHub-kontot tar du bort Azure App Service som en auktoriserad Oauth-app för ditt GitHub-konto.

Relaterat innehåll

• Vanliga lagringsplatser och arbetsflöden för GitHub Actions
• Kommandoreferens – az webapp driftsättning GitHub-åtgärder