Konfigurera kontinuerlig distribution för en Python-webbapp i Azure Container Apps

Den här artikeln är en del av en självstudie om hur du containeriserar och distribuerar en Python-webbapp till Azure Container Apps. Med Container Apps kan du distribuera containerbaserade appar utan att hantera komplex infrastruktur.

I den här delen av självstudien får du lära dig hur du konfigurerar kontinuerlig distribution eller leverans (CD) för containerappen. CD är en del av DevOps-metoden för kontinuerlig integrering/kontinuerlig leverans (CI/CD), som är automatisering av ditt arbetsflöde för apputveckling. Mer specifikt använder du GitHub Actions för kontinuerlig distribution.

Det här tjänstdiagrammet visar de komponenter som beskrivs i den här artikeln: konfiguration av CI/CD.

Förutsättningar

För att konfigurera kontinuerlig distribution behöver du:

• Resurserna och konfigurationen som skapades i föregående artikel i den här självstudieserien, som innehåller ett Azure Container Registry och en containerapp i Azure Container Apps.

• Ett GitHub-konto där du förgrenade exempelkoden (Django eller Flask) och du kan ansluta till från Azure Container Apps. (Om du har laddat ned exempelkoden i stället för att förgrena dig kontrollerar du att du push-överför din lokala lagringsplats till ditt GitHub-konto.)

• Du kan också installera Git i utvecklingsmiljön för att göra kodändringar och push-överföra till lagringsplatsen i GitHub. Du kan också göra ändringarna direkt i GitHub.

Konfigurera CD för en container

I en tidigare artikel i den här självstudien skapade och konfigurerade du en containerapp i Azure Container Apps. En del av konfigurationen var att hämta en Docker-avbildning från ett Azure Container Registry. Containeravbildningen hämtas från registret när du skapar en containerrevision, till exempel när du först konfigurerar containerappen.

I det här avsnittet konfigurerar du kontinuerlig distribution med hjälp av ett GitHub Actions-arbetsflöde. Med kontinuerlig distribution skapas en ny Docker-avbildning och containerrevision baserat på en utlösare. Utlösaren i den här självstudien är en ändring av huvudgrenen för lagringsplatsen, till exempel med en pull-begäran (PR). När det utlöses skapar arbetsflödet en ny Docker-avbildning, push-överför den till Azure Container Registry och uppdaterar containerappen till en ny revision med den nya avbildningen.

Azure CLI

Azure CLI-kommandon kan köras i Azure Cloud Shell eller på en arbetsstation med Azure CLI installerat.

Om du kör kommandon i ett Git Bash-gränssnitt på en Windows-dator anger du följande kommando innan du fortsätter:

export MSYS_NO_PATHCONV=1

Steg 1. Skapa ett huvudnamn för tjänsten med kommandot az ad sp create-for-rbac .

az ad sp create-for-rbac \
--name <app-name> \
--role Contributor \
--scopes "/subscriptions/<subscription-ID>/resourceGroups/<resource-group-name>"

Där:

• <appnamn> är ett valfritt visningsnamn för tjänstens huvudnamn. Om du lämnar alternativet --name genereras ett GUID som visningsnamn.
• <subscription-ID är det GUID> som unikt identifierar din prenumeration i Azure. Om du inte känner till ditt prenumerations-ID kan du köra kommandot az account show och kopiera det från id egenskapen i utdata.
• <resource-group-name> är namnet på en resursgrupp som innehåller Azure Container Apps-containern. Rollbaserad åtkomstkontroll (RBAC) finns på resursgruppsnivå. Om du följde stegen i föregående artikel i den här självstudien är pythoncontainer-rgresursgruppens namn .

Spara utdata för det här kommandot för nästa steg, särskilt klient-ID (appId egenskap), klienthemlighet (password egenskap) och klient-ID (tenant egenskap).

Steg 2. Konfigurera GitHub Actions med kommandot az containerapp github-action add .

az containerapp github-action add \
--resource-group <resource-group-name> \
--name python-container-app \
--repo-url <https://github.com/userid/repo> \
--branch main \
--registry-url <registry-name>.azurecr.io \
--service-principal-client-id <client-id> \
--service-principal-tenant-id <tenant-id> \
--service-principal-client-secret <client-secret> \
--login-with-github

Där:

• <resource-group-name> är namnet på resursgruppen. Om du följer den här självstudien är det "pythoncontainer-rg".
• <https://github.com/userid/repo> är URL:en för din GitHub-lagringsplats. Om du följer stegen i den här självstudien blir det antingen https://github.com/userid/msdocs-python-django-azure-container-apps eller https://github.com/userid/msdocs-python-flask-azure-container-apps; där userid är ditt GitHub-användar-ID.
• <registernamn> är det befintliga Container Registry som du skapade för den här självstudien, eller ett som du kan använda.
• <client-id> är värdet för appId egenskapen från föregående az ad sp create-for-rbac kommando. ID:t är ett GUID i formuläret 00000000-0000-0000-0000-000000000.
• <tenant-id> är värdet för tenant egenskapen från föregående az ad sp create-for-rbac kommando. ID:t är också ett GUID som liknar klient-ID:t.
• <client-secret> är värdet för password egenskapen från föregående az ad sp create-for-rbac kommando.

Azure-portalen

Steg 1. I Azure-portalen går du till den containerapp som du vill konfigurera kontinuerlig distribution för och väljer resursen Kontinuerlig distribution.

Steg 2. Ge Azure Container Apps åtkomst till ditt GitHub-konto.

• Välj Logga in med GitHub.
• I popup-fönstret auktorisering väljer du AuktoriseraAppService.

ContainerAppåtkomst till GitHub-accont kan återkallas genom att gå till säkerhetsavsnittet för ditt konto och återkalla åtkomsten.

Steg 3. När du har loggat in med GitHub konfigurerar du information om kontinuerlig distribution.

• Organisation → Använd ditt GitHub-användarnamn.
• Lagringsplats → Välj förgrening av exempelappen. (Om du ursprungligen laddade ned exempelkoden till utvecklarmiljön skickar du lagringsplatsen till GitHub.)
• Gren → Välj huvud.
• Lagringsplatskälla → Välj Azure Container Registry.
• Register → Välj det Azure Container Registry som du skapade tidigare i självstudien.
• Bild → Välj Docker-avbildningsnamnet. Om du följer självstudien är det "python-container-app".
• Tjänstens huvudnamn → Lämna Skapa nytt och låt skapandeprocessen skapa ett nytt huvudnamn för tjänsten.

Välj Starta kontinuerlig distribution för att slutföra konfigurationen.

Steg 4. Granska informationen om kontinuerlig distribution.

När den kontinuerliga distributionen har konfigurerats kan du hitta en länk till arbetsflödesfilen för GitHub Actions som skapats. Azure Container Apps checkade in filen på lagringsplatsen.

I konfigurationen av kontinuerlig distribution används ett huvudnamn för tjänsten för att göra det möjligt för GitHub Actions att komma åt och ändra Azure-resurser. Åtkomsten till resurser begränsas av de roller som tilldelats tjänstens huvudnamn. Tjänstens huvudnamn tilldelades den inbyggda deltagarrollen i resursgruppen som innehåller containerappen.

Om du följde stegen för portalen skapades tjänstens huvudnamn automatiskt åt dig. Om du följde stegen för Azure CLI skapade du uttryckligen tjänstens huvudnamn först innan du konfigurerade kontinuerlig distribution.

Distribuera om webbappen med GitHub Actions

I det här avsnittet gör du en ändring i din förgrenade kopia av exempellagringsplatsen och bekräftar att ändringen distribueras automatiskt till webbplatsen.

Om du inte redan har gjort det skapar du en förgrening av exempellagringsplatsen (Django eller Flask). Du kan göra din kodändring direkt i GitHub eller i utvecklingsmiljön från en kommandorad med Git.

GitHub

Steg 1. Gå till din förgrening av exempellagringsplatsen och starta i huvudgrenen.

Steg 2. Gör en ändring.

• Gå till filen /templates/base.html . (För Django är sökvägen: restaurant_review/templates/restaurant_review/base.html.)
• Välj Redigera och ändra frasen "Azure Restaurant Review" till "Azure Restaurant Review – Omdistribuerad".

Steg 3. Checka in ändringen direkt till huvudgrenen .

• Längst ned på sidan som du redigerar väljer du knappen Checka in .
• Incheckningen startar GitHub Actions-arbetsflödet.

Kommandorad

Om du inte redan har gjort det kan du använda git clone för att hämta din förgrenade lagringsplats till utvecklingsmiljön och ändra katalogen till lagringsplatsen.

Steg 1. Börja i huvudsyfte.

git checkout main
git pull

Steg 2. Gör en ändring.

Gå till filen ./templates/base.html (./restaurant_review/templates/restaruant_review/base.html för Django) och ändra frasen "Azure Restaurant Review" till "Azure Restaurant Review – Omdistribuerad".

Steg 3. Checka in och skicka ändringen till GitHub.

git commit -a -m "Redeploy with title change."
git push

Första gången du använder git kan du behöva ange globala variabler "user.name" och "user.email". Mer information finns i hjälpen för git-config.

Push-överföringen av ändringar i huvudgrenen startar GitHub Actions-arbetsflödet.

Kommentar

Vi visade att vi gjorde en ändring direkt i huvudgrenen. I vanliga programvaruarbetsflöden gör du en ändring i en annan gren än main och skapar sedan en pull-begäran (PR) för att sammanfoga ändringen till main. PR:er startar också arbetsflödet.

Om GitHub-åtgärder

Visa arbetsflödeshistorik

GitHub

Steg 1. På GitHub går du till din förgrening av exempellagringsplatsen och öppnar fliken Åtgärder .

Kommandorad

De här stegen använder GitHub CLI.

Steg 1. Få en sammanfattning av arbetsflödet. Kör följande kommando i mappen som innehåller din klon:

gh workflow view

Det här kommandot uppmanar dig att välja ett arbetsflöde och ger sedan en översikt över de senaste körningarna av arbetsflödet.

Kommentar

Första gången du använder gh kan du uppmanas att autentisering. Följ GitHub CLI-anvisningarna för att autentisera.

Om du har fler än en fjärrkonfigurerad kan du bli ombedd att köra gh repo set-default för att välja en standardlagringsplats för fjärrlagringsplats. Välj din förgrening bland de alternativ som visas.

Du kan köra gh workflow view kommandot från valfri mapp utan att behöva ange en standardlagringsplats genom att lägga till parametern --repo [HOST/]OWNER/REPO .

Steg 2. Gå till GitHub för information om körningen av arbetsflödet.

gh workflow view --web

Arbetsflödes hemligheter

I .github/workflows/<workflow-name>.yml arbetsflödesfil som lades till på lagringsplatsen ser du platshållare för autentiseringsuppgifter som behövs för uppdateringsjobben för bygg- och containerappen i arbetsflödet. Informationen om autentiseringsuppgifter lagras krypterad i lagringsplatsen Inställningar under Säkerhetshemligheter//och variabler Åtgärder.

Om information om autentiseringsuppgifter ändras kan du uppdatera den här. Om Azure Container Registry-lösenorden till exempel återskapas måste du uppdatera värdet för REGISTRY_PASSWORD. Mer information finns i Krypterade hemligheter i GitHub-dokumentationen.

OAuth-auktoriserade appar

När du konfigurerar kontinuerlig distribution godkänner du Azure Container Apps som en auktoriserad OAuth-app för ditt GitHub-konto. Container Apps använder den auktoriserade åtkomsten för att skapa en GitHub Actions YML-fil i .github/workflows/<workflow-name>.yml. Du kan se dina auktoriserade appar och återkalla behörigheter under Integreringsprogram/för ditt konto.

Felsökningstips

Fel vid konfiguration av tjänstens huvudnamn med Azure CLI-kommandot az ad sp create-for-rba .

• Du får ett felmeddelande som innehåller "InvalidSchema: Inga anslutningskort hittades".

  • Kontrollera gränssnittet som du kör i. Om du använder Bash-gränssnittet anger du MSYS_NO_PATHCONV variablerna enligt följande export MSYS_NO_PATHCONV=1. Mer information finns i GitHub-problemet Det gick inte att skapa tjänstens huvudnamn med Azure CLI från Git Bash Shell. Inga anslutningskort hittades..

• Du får ett felmeddelande som innehåller "Fler än ett program har samma visningsnamn".

  • Det här felet anger att namnet redan har tagits för tjänstens huvudnamn. Välj ett annat namn eller utelämna --name argumentet så genereras ett GUID automatiskt som visningsnamn.

GitHub Actions-arbetsflödet misslyckades.

• Om du vill kontrollera status för ett arbetsflöde går du till fliken Åtgärder på lagringsplatsen.
• Om det finns ett misslyckat arbetsflöde kan du öka detaljnivån i arbetsflödesfilen. Det bör finnas två jobb "build" och "deploy". För ett misslyckat jobb kan du titta på utdata från jobbets aktiviteter för att söka efter problem.
• 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. Du bör inte behöva ändra den här filen för den här självstudien. Om du gjorde det återställer du ändringarna och provar arbetsflödet.

Webbplatsen visar inte ändringar som du har sammanfogat i huvudgrenen.

• I GitHub: kontrollera att GitHub Actions-arbetsflödet kördes och att du checkade in ändringen i den gren som utlöser arbetsflödet.
• I Azure-portalen: Kontrollera Azure Container Registry för att se om en ny Docker-avbildning har skapats med en tidsstämpel efter ändringen av grenen.
• I Azure-portalen: kontrollera loggarna för containerappen. Om det finns ett programmeringsfel visas det här.
  • Gå till containerappen | Revisionshantering | <aktiv container> | Revisionsinformation | Konsolloggar
  • Välj ordningen på kolumnerna för att visa "Time Generated", "Stream_s" och "Log_s". Sortera loggarna efter de senaste först och leta efter Python stderr - och stdout-meddelanden i kolumnen "Stream_s". Utdata från Python "print" kommer att vara stdout-meddelanden .
• Med Azure CLI använder du kommandot az containerapp logs show .

Vad händer när jag kopplar från kontinuerlig distribution?

• Att stoppa kontinuerlig distribution innebär att du kopplar från containerappen från lagringsplatsen. Så här kopplar du från:

  • I Azure-portalen går du till containerappen, väljer resursen Kontinuerlig distribution och väljer Koppla från.
  • Med Azure CLI använder du kommandot az container app github-action remove .

• Efter frånkopplingen går du till din GitHub-lagringsplats:

  • Filen .github/workflows/<workflow-name>.yml tas bort från lagringsplatsen.
  • Hemliga nycklar tas inte bort.
  • Azure Container Apps förblir som en auktoriserad OAuth-app för ditt GitHub-konto.

• Efter frånkopplingen i Azure:

  • Containern finns kvar med den senast distribuerade containern. Du kan återansluta containerappen med Azure Container Registry så att nya containerrevisioner hämtar den senaste avbildningen.
  • Tjänstens huvudnamn som skapats och används för kontinuerlig distribution tas inte bort.

Nästa steg

Om du är klar med självstudien och inte vill medföra extra kostnader tar du bort de resurser som används. Om du tar bort en resursgrupp tas alla resurser i gruppen bort och det snabbaste sättet att ta bort resurser. Ett exempel på hur du tar bort resursgrupper finns i rensning av containerbaserad självstudie.

Om du planerar att bygga vidare på den här självstudien kan du utföra några nästa steg.

• Ange skalningsregler i Azure Container Apps

• Binda anpassade domännamn och certifikat i Azure Container Apps

• Övervaka en app i Azure Container Apps