Använda CI/CD med GitHub Actions för att distribuera en Python-webbapp till Azure App Service på Linux

Artikel
10/23/2023

Använd plattformen För kontinuerlig integrering och kontinuerlig leverans av GitHub Actions (CI/CD) för att distribuera en Python-webbapp till Azure App Service på Linux. Ditt GitHub Actions-arbetsflöde skapar automatiskt koden och distribuerar den till App Service när det sker en incheckning till 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 en lagringsplats för din appkod

Om du redan har en Python-webbapp att använda kontrollerar du att den har checkats in på en GitHub-lagringsplats.

Om du behöver en app att arbeta med kan du förgrena och klona lagringsplatsen på https://github.com/Microsoft/python-sample-vscode-flask-tutorial. Koden kommer från självstudiekursen Flask i Visual Studio Code.

Kommentar

Om din app använder Django och en SQLite-databas fungerar den inte för den här självstudien. Om din Django-app använder en separat databas som PostgreSQL kan du använda den med den här självstudien. Mer information om Django finns i överväganden för Django senare i den här artikeln.

Skapa Azure App Service-målet

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 steg använder du az webapp upp till att både skapa App Service och göra den första distributionen av din app.

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

Steg 2. Öppna Azure CLI genom att välja Cloud Shell-ikonen i portalverktygsfältet.

Steg 3. I Cloud Shell väljer du Bash i listrutan.

Steg 4. I Cloud Shell klonar du lagringsplatsen med git-klon. Om du till exempel använder Flask-exempelappen är kommandot:

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

Ersätt <github-user> med namnet på det GitHub-konto där du förgrenade lagringsplatsen. Om du använder en annan app-lagringsplats är den här lagringsplatsen där du konfigurerar GitHub Actions.

Kommentar

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

Dricks

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

Steg 5. I Cloud Shell ändrar du katalogen till den lagringsplatsmapp som har python-appen så att kommandot az webapp up identifierar appen som Python. Till exempel för Flask-exempelappen:

cd python-sample-vscode-flask-tutorial

Steg 6. I Cloud Shell använder du az webapp up för att skapa en App Service och först distribuera din app.

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

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

Använd az webapp list-runtimes för att hämta en lista över tillgängliga körningar. PYTHON|X.Y Använd formatet, där X.Y är Python-versionen.

Du kan också ange platsen för App Service med parametern --location . az account list-locations --output table Använd kommandot för att hämta en lista över tillgängliga platser.

Steg 7. Om appen använder ett anpassat startkommando använder du kommandot az webapp config . Om appen inte har något anpassat startkommando hoppar du över det här steget.

Till exempel innehåller python-sample-vscode-flask-tutorial-appen en fil med namnet startup.txt som innehåller ett startkommando som du kan använda på följande sätt:

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

Du hittar resursgruppens namn från utdata från föregående az webapp up kommando. Resursgruppens namn börjar med <azure-account-name>_rg_.

Steg 8. Om du vill se appen som körs öppnar du en webbläsare och går till http:// app-service-name.azurewebsites.net>.<

Om du ser en allmän sida väntar du några sekunder tills App Service startar och uppdaterar sidan. Om du fortsätter att se den allmänna sidan kontrollerar du att du har distribuerat från rätt mapp. Om du till exempel använder Flask-exempelappen är mappen python-sample-vscode-flask-tutorial. För Flask-exempelappen kontrollerar du också att du har angett startkommandot korrekt.

Konfigurera kontinuerlig distribution i App Service

I stegen nedan konfigurerar du kontinuerlig distribution (CD), vilket innebär att en ny koddistribution sker när ett arbetsflöde utlöses. Utlösaren i den här självstudien är en ändring av huvudgrenen för lagringsplatsen, till exempel med en pull-begäran (PR).

Steg 1. Lägg till GitHub Action med kommandot az webapp deployment github-actions add .

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 för att slutföra autentiseringen.

Om det finns en befintlig arbetsflödesfil som står i konflikt med namnet apptjänsten använder uppmanas du att välja om du vill skriva över. Använd parametern --force för att skriva över utan att fråga.

Vad kommandot lägg till gör:

Skapar en ny arbetsflödesfil: .github/workflows/<workflow-name.yml> på lagringsplatsen. Namnet på filen innehåller namnet på din App Service.
Hämtar en publiceringsprofil med hemligheter för din App Service 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.

Steg 2. Hämta information om en distributionskonfiguration för källkontroll med kommandot az webapp deployment source show .

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

Bekräfta värdena för repoUrl egenskaperna och branch i utdata från kommandot. Dessa värden ska matcha de värden som du angav i föregående steg.

Förklaring av GitHub-arbetsflöde och åtgärder

Ett arbetsflöde definieras av 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. Varje jobb i sin tur är en uppsättning steg. Och slutligen är varje steg ett gränssnittsskript eller en åtgärd.

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

Åtgärd	beskrivning
Kassan	Kolla in lagringsplatsen på en runner, en GitHub Actions-agent.
setup-python	Installera Python på löparen.
appservice-build	Skapa webbappen.
webapps-deploy	Distribuera webbappen med en autentiseringsuppgift för publiceringsprofil för att autentisera i Azure. Autentiseringsuppgifterna lagras i en GitHub-hemlighet.

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 GitHub-åtgärds-YML-fil i .github/workflows/<workflow-name.yml>. Du kan se dina auktoriserade appar och återkalla behörigheter under dina GitHub-konton Inställningar, under Integreringar/program.

Publicera profilhemlighet för arbetsflöde

I arbetsflödesfilen .github/workflows/<workflow-name.yml> som lades till på lagringsplatsen visas en platshållare för autentiseringsuppgifter för publiceringsprofil som behövs för arbetsflödets distributionsjobb. Publiceringsprofilinformationen lagras krypterad på lagringsplatsen Inställningar, under Säkerhet/åtgärder.

I den här artikeln autentiseras GitHub-åtgärden med en publiceringsprofilsautentisering. Det finns andra sätt att autentisera, till exempel med tjänstens huvudnamn eller OpenID-Anslut. Mer information finns i Distribuera till App Service med GitHub Actions.

Kör arbetsflödet

Nu ska du testa arbetsflödet genom att göra en ändring i lagringsplatsen.

Steg 1. Gå till din förgrening av exempellagringsplatsen (eller lagringsplatsen du använde) och välj den gren som du angav som en del av utlösaren.

Steg 2. Gör en liten ändring.

Om du till exempel använde VS Code Flask-självstudien kan du

Gå till filen /hello-app/templates/home.html för utlösargrenen.
Välj Redigera och lägg till texten "Omdistribuerad!".

Steg 3. Checka in ändringen direkt till den gren som du arbetar i.

Längst upp till höger på sidan som du redigerar väljer du knappen Checka in ändringar ... . Fönstret Genomför ändringar öppnas. I fönstret Genomför ändringar ändrar du incheckningsmeddelandet om du vill och väljer sedan knappen Genomför ändringar .
Incheckningen startar GitHub Actions-arbetsflödet.

Du kan också starta arbetsflödet manuellt.

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

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

Felsöka ett misslyckat arbetsflöde

Om du vill kontrollera status för ett arbetsflöde går du till fliken Åtgärder på lagringsplatsen. När du går in på den arbetsflödesfil som skapades i den här självstudien visas två jobb "build" och "deploy". För ett misslyckat jobb kan du titta på utdata från jobbaktiviteter för att få en indikation på felet. Några vanliga problem är:

Om appen misslyckas på grund av ett beroende som saknas bearbetas inte filen requirements.txt under distributionen. Det här beteendet inträffar om du har skapat webbappen direkt på portalen i stället för att az webapp up använda 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 med 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å lagringsplatsen för att se om tidsgränsen är ett tillfälligt problem.
Om du konfigurerar kontinuerlig distribution för containerappen enligt den här självstudien skapas arbetsflödesfilen (.github/workflows/<workflow-name.yml>) automatiskt åt dig. Om du har ändrat den tar du bort ändringarna för att se om de orsakar felet.

Köra ett skript efter distributionen

Ett skript efter distributionen kan till exempel definiera miljövariabler som förväntas av appkoden. Lägg till skriptet som en del av appkoden och kör det med startkommandot.

För att undvika hårdkodade variabelvärden i arbetsflödets YML-fil kan du i stället använda dem i GitHub-webbgränssnittet och sedan referera till variabelnamnet i skriptet. Du kan skapa krypterade hemligheter för en lagringsplats eller för en miljö (kontolagringsplats). Mer information finns i Krypterade hemligheter i GitHub Docs.

Ö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 på 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.

Enligt beskrivningen i artikeln Konfigurera Python-app på App Service – Startprocess för container letar App Service automatiskt 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 kodfragment 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 av python manage.py migrate kommandot när du har distribuerat appkoden. Du kan köra kommandot migrering i ett skript efter distributionen.

Koppla från GitHub Actions

Om du kopplar från GitHub Actions från Din App Service kan du konfigurera om appdistributionen. Du kan välja vad som händer med arbetsflödesfilen när du har kopplat från, oavsett om du vill spara eller ta bort filen.

Azure CLI
Azure-portalen

Koppla från GitHub Actions med Azure CLI az webapp deployment github-actions remove command.

az webapp deployment github-actions remove \
  --repo "<github-user>/<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 självstudien tar du bort resursgruppen som innehåller App Service och App Service-planen.

Azure CLI
Azure-portalen

Var som helst där Azure CLI är installerat, inklusive Azure Cloud Shell, kan du använda kommandot az group delete för att ta bort resursgruppen.

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

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.

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

Ta bort filen .github/workflows/<workflow-name.yml> på lagringsplatsen.
I lagringsplatsens inställningar 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.

Dela via