Zelfstudie: Continue implementatie configureren voor een Python-web-app in Azure Container Apps

Dit artikel maakt deel uit van een reeks zelfstudies over het in een container zetten en implementeren van een Python-web-app voor Azure Container Apps. Met Container Apps kunt u container-apps implementeren zonder dat u complexe infrastructuur hoeft te beheren.

In deze zelfstudie gaat u het volgende doen:

• Configureer continue implementatie voor een container-app met behulp van een GitHub Actions werkstroom.
• Breng een wijziging aan in een kopie van de voorbeeldopslagplaats om de GitHub Actions-werkstroom te activeren.
• Problemen oplossen die kunnen optreden bij het configureren van continue implementatie.
• Verwijder resources die u niet nodig hebt wanneer u de reeks zelfstudies hebt voltooid.

Continue implementatie is gerelateerd aan de DevOps-praktijk van continue integratie en continue levering (CI/CD), wat automatisering is van uw werkstroom voor app-ontwikkeling.

In het volgende diagram worden de taken in deze handleiding getoond.

Voorwaarden

Als u continue implementatie wilt instellen, hebt u het volgende nodig:

• De resources (en hun configuratie) die u hebt gemaakt in de vorige zelfstudie, waaronder een exemplaar van Azure Container Registry en een container-app in Azure Container Apps.

• Een GitHub-account waar u de voorbeeldcode hebt gesplitst (Django- of Flask) en waarmee u verbinding kunt maken vanuit Azure Container Apps. (Als u de voorbeeldcode hebt gedownload in plaats van te forken, moet u uw lokale repository naar uw GitHub-account pushen.)

• Het is optioneel om Git te installeren in uw ontwikkelomgeving om codewijzigingen aan te brengen en naar uw opslagplaats in GitHub te pushen. U kunt de wijzigingen ook rechtstreeks in GitHub aanbrengen.

Continue implementatie voor een container configureren

In de vorige zelfstudie hebt u een container-app gemaakt en geconfigureerd in Azure Container Apps. Een deel van de configuratie bestond uit het ophalen van een Docker-image uit een Azure Container Registry-instantie. De containerafbeelding wordt uit het register gehaald wanneer u een container maakt revisie, bijvoorbeeld de eerste keer dat u de container-app instelt.

In deze sectie stelt u continue implementatie in met behulp van een GitHub Actions-werkstroom. Bij continue deployment worden nieuwe Docker-images en containerrevisies gemaakt op basis van een trigger. De trigger in deze handleiding is elke wijziging in de hoofd- tak van uw opslagplaats, zoals met een pull request. Wanneer de werkstroom wordt geactiveerd, wordt er een nieuwe Docker-image gemaakt, naar het Azure Container Registry-exemplaar gepusht en wordt de container-app bijgewerkt naar een nieuwe revisie met behulp van de nieuwe image.

Azure CLI

U kunt Azure CLI-opdrachten uitvoeren in Azure Cloud Shell- of op een werkstation waarop Azure CLI- is geïnstalleerd.

Als u opdrachten uitvoert in een Git Bash-shell op een Windows-computer, voert u de volgende opdracht in voordat u doorgaat:

export MSYS_NO_PATHCONV=1

1. Maak een service-principal met behulp van de opdracht 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>"
   

   In de opdracht:

   • <app-naam> is een optionele weergavenaam voor de service-principal. Als u de optie --name weglaat, wordt er een GUID gegenereerd als de weergavenaam.
   • <abonnements-id> is de GUID die uw abonnement uniek identificeert in Azure. Als u uw abonnements-id niet weet, kunt u de opdracht az account show uitvoeren en kopiëren vanuit de eigenschap id in de uitvoer.
   • <resourcegroepnaam> is de naam van een resourcegroep die de Azure Container Apps-container bevat. Op rollen gebaseerd toegangsbeheer (RBAC) bevindt zich op het niveau van de resourcegroep. Als u de stappen in de vorige zelfstudie hebt gevolgd, is de naam van de resourcegroep pythoncontainer-rg.

   Sla de uitvoer van deze opdracht op voor de volgende stap. Sla met name de client-id (appId eigenschap), het clientgeheim (password eigenschap) en de tenant-id (tenant eigenschap) op.

2. Configureer GitHub Actions met behulp van de opdracht 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
   

   In de opdracht:

   • <is de naam van de resourcegroep>. In deze handleiding betreft het pythoncontainer-rg.
   • <https://github.com/userid/repo> is de URL van uw GitHub-opslagplaats. In deze handleiding is het https://github.com/userid/msdocs-python-django-azure-container-apps of https://github.com/userid/msdocs-python-flask-azure-container-apps. In deze URL's is userid uw GitHub-gebruikers-id.
   • <registernaam> is het bestaande Azure Container Registry-exemplaar dat u in de vorige zelfstudie hebt gemaakt, of een exemplaar dat u kunt gebruiken.
   • <client-id> is de waarde van de eigenschap appId van de vorige az ad sp create-for-rbac opdracht. De ID is een GUID van de vorm 00000000-0000-0000-0000-00000000.
   • <tenant-id> is de waarde van de eigenschap tenant uit het voorafgaande az ad sp create-for-rbac commando. De ID is ook een GUID die vergelijkbaar is met de Client-ID.
   • <clientgeheim> is de waarde van de eigenschap password van de vorige az ad sp create-for-rbac opdracht.

Azure Portal

1. Ga in de Azure-portalnaar de container-app waarvoor u continue implementatie wilt configureren. Selecteer in het servicemenu Continue implementatie.

   

2. Azure Container Apps machtigen voor toegang tot uw GitHub-account:

   1. Selecteer Aanmelden met GitHub.
   2. In het autorisatiedialoogvenster, selecteer AzureAppService autoriseren.

   

   Tip

   U kunt Container Apps-toegang tot het GitHub-account intrekken vanuit de beveiligingssectie van uw account.

3. Configureer de details van de continue implementatie:

   • Organisatie-: gebruik uw GitHub-gebruikersnaam.
   • Opslagplaats: selecteer de fork van de voorbeeld-app. (Als je de voorbeeldcode oorspronkelijk hebt gedownload naar je ontwikkelomgeving, push de repository naar GitHub.)
   • Branch: selecteer hoofd-.
   • opslagplaatsbron: selecteer Azure Container Registry-.
   • Registry-: selecteer de Azure Container Registry-instantie die u in de vorige zelfstudie hebt gemaakt.
   • Image: selecteer de naam van de Docker-image. In deze zelfstudie is het python-container-app.
   • Service Principal: laat nieuwe maken en laat het aanmaakproces een nieuwe Service Principal creëren.

   Selecteer continue implementatie starten om de configuratie te voltooien.

   

4. Bekijk de informatie over de continue implementatie.

   De informatie bevat een koppeling naar het gemaakte GitHub Actions-werkstroombestand. Azure Container Apps heeft het bestand in uw repository ingecheckt.

   

In de configuratie van continue implementatie maakt een service-principal het mogelijk voor GitHub Actions om toegang te krijgen tot en wijzigingen aan te brengen in Azure-resources. De rollen die zijn toegewezen aan de service-principal beperken de toegang tot resources. De service-principal is toegewezen aan de ingebouwde inzender rol voor de resourcegroep die de container-app bevat.

Als u de stappen voor de portal hebt gevolgd, is het serviceaccount automatisch voor u gemaakt. Als u de stappen voor de Azure CLI hebt gevolgd, hebt u de service-principal expliciet gemaakt voordat u continue implementatie hebt geconfigureerd.

De web-app opnieuw implementeren met GitHub Actions

In dit gedeelte brengt u een wijziging aan in de geforkte kopie van de voorbeeldrepository. Daarna kunt u bevestigen dat de wijziging automatisch op de website wordt geïmplementeerd.

Als je dat nog niet gedaan hebt, maak dan een fork van de voorbeeldrepository (Django of Flask). U kunt de code rechtstreeks wijzigen in GitHub- of in uw ontwikkelomgeving vanaf een opdrachtregel met Git-.

GitHub

1. Ga naar uw fork van de voorbeeldrepository en begin in de hoofdvertakking.

   

2. Breng een wijziging aan:

   1. Ga naar het bestand /templates/base.html. (Voor Django is het pad restaurant_review/templates/restaurant_review/base.html.)
   2. Selecteer bewerken en wijzig de woordgroep Azure Restaurant Review in Azure Restaurant Review - Redeployed.

   

3. Controleer onder aan de pagina die u bewerkt of Direct doorvoeren naar de hoofdbranch is geselecteerd. Selecteer vervolgens de knop Wijzigingen doorvoeren.

   

Met de doorvoering wordt de GitHub Actions-werkstroom gestart.

opdrachtregel

Als u dat nog niet hebt gedaan, gebruikt u git clone om uw geforkte opslagplaats naar uw ontwikkelomgeving te halen en de map naar de opslagplaats te wijzigen. Voer vervolgens de volgende stappen uit:

1. Begin in hoofd-van :

   git checkout main
   git pull
   

2. Breng een wijziging aan.

   Ga naar het bestand ./templates/base.html (./restaurant_review/templates/restaurant_review/base.html voor Django) en wijzig de woordgroep Azure Restaurant Review in Azure Restaurant Review - Redeployed.

3. Voer de wijziging door en push deze naar GitHub:

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

De eerste keer dat u Git gebruikt, moet u mogelijk de globale variabelen instellen user.name en user.email. Zie de Help voor git-configvoor meer informatie.

De push van wijzigingen in de main branch start de GitHub Actions-werkstroom.

Notitie

In deze handleiding wordt getoond hoe u rechtstreeks een wijziging aanbrengt in de hoofdbranch. In typische softwarewerkstromen maakt u een verandering in een andere tak dan main en dient u vervolgens een pull request in om de verandering samen te voegen in main. Pull-aanvragen starten ook de workflow.

Begrijp GitHub Actions

Werkstroomgeschiedenis weergeven

Als u de werkstroomgeschiedenis wilt bekijken, gebruikt u een van de volgende procedures.

GitHub

Ga in GitHubnaar uw fork van de voorbeeldopslagplaats en open het tabblad Actions.

opdrachtregel

In deze stappen wordt de GitHub CLI-gebruikt.

1. Bekijk een samenvatting van uw werkstroom. Voer de volgende opdracht uit in de map die uw kloon bevat:

   gh workflow view
   

   Met deze opdracht wordt u gevraagd een werkstroom te selecteren en krijgt u vervolgens een overzicht van recente uitvoeringen van die werkstroom.

   Notitie

   De eerste keer dat u ghgebruikt, wordt u mogelijk gevraagd om te verifiëren. Volg de GitHub CLI-prompts om te verifiëren.

   Als u meer dan één externe configuratie hebt geconfigureerd, wordt u mogelijk gevraagd om gh repo set-default uit te voeren om een externe standaardopslagplaats te selecteren. Selecteer uw fork in de weergegeven opties.

   U kunt de opdracht gh workflow view uitvoeren vanuit elke map zonder dat u een standaardopslagplaats hoeft in te stellen door de parameter --repo [HOST/]OWNER/REPO toe te voegen.

2. Ga naar GitHub voor meer informatie over een werkstroomuitvoering:

   gh workflow view --web
   

Werkstroomgeheimen

De .github/workflows/<workflownaam>.yml werkstroombestand dat aan de repository is toegevoegd, bevat placeholders voor referenties die nodig zijn voor de bouw- en containerapplicatie-updatetaken van de werkstroom. De referentiegegevens worden versleuteld opgeslagen in het gebied Instellingen van de opslagplaats, onder Beveiliging>Geheimen en variabelen>Acties.

Als de referentiegegevens worden gewijzigd, kunt u deze hier bijwerken. Als de Wachtwoorden van Azure Container Registry bijvoorbeeld opnieuw worden gegenereerd, moet u de REGISTRY_PASSWORD waarde bijwerken. Zie Versleutelde geheimen in de GitHub-documentatie voor meer informatie.

Geautoriseerde OAuth-apps

Wanneer u continue implementatie instelt, wijst u Azure Container Apps aan als een geautoriseerde OAuth-app voor uw GitHub-account. Container Apps gebruikt de geautoriseerde toegang om een YAML-bestand voor GitHub Actions te maken in .github/workflows/<werkstroomnaam>.yml. U kunt uw geautoriseerde apps bekijken en machtigingen intrekken in uw account, onder Integrations>Applications.

Problemen oplossen

U krijgt fouten tijdens het instellen van een service-principal via de Azure CLI

Deze sectie kan u helpen bij het oplossen van fouten die u krijgt tijdens het instellen van een service-principal met behulp van de Azure CLI az ad sp create-for-rba opdracht.

Als u een foutmelding krijgt met 'InvalidSchema: Er zijn geen verbindingsadapters gevonden':

• Controleer de shell waarin u werkt. Als u een Bash-shell gebruikt, stelt u de MSYS_NO_PATHCONV variabelen in als export MSYS_NO_PATHCONV=1.

  Zie het GitHub-probleem Kan geen service-principal maken met Azure CLI vanuit de Git Bash-shellvoor meer informatie.

Als u een foutmelding krijgt met 'Meer dan één toepassing heeft dezelfde weergavenaam':

• De naam wordt al gebruikt voor de service-principal. Kies een andere naam of laat het argument --name weg. Er wordt automatisch een GUID gegenereerd als weergavenaam.

GitHub Actions-werkstroom is mislukt

Als u de status van een werkstroom wilt controleren, gaat u naar het tabblad Acties van de opslagplaats:

• Als er een mislukte werkstroom is, duik dieper in het werkstroombestand. Er moeten twee taken zijn: bouwen en implementeren. Voor een mislukte taak controleert u de uitvoer van de taken van de taak om te zoeken naar problemen.
• Als er een foutmelding is met 'TLS handshake time-out', start u de werkstroom handmatig. Selecteer in de repository op het tabblad ActiesAutomatische implementatie starten om te zien of de time-out een tijdelijk probleem is.
• Als u continue implementatie instelt voor de container-app, zoals wordt weergegeven in deze zelfstudie, wordt het werkstroombestand (.github/workflows/<werkstroomnaam>.yml) automatisch voor u gemaakt. U hoeft dit bestand niet te wijzigen voor deze zelfstudie. Als u dit hebt gedaan, kunt u de wijzigingen terugzetten en de werkstroom proberen.

Website toont geen wijzigingen die u hebt samengevoegd in de hoofdbranch

In GitHub:

• Controleer of de GitHub Actions-werkstroom is uitgevoerd en of u de wijziging hebt ingevoerd in de vertakking waarmee de werkstroom wordt geactiveerd.

In de Azure-portal:

• Controleer het Azure Container Registry-exemplaar om te zien of er een nieuwe Docker-afbeelding is gemaakt met een tijdstempel na je wijziging aan de vertakking.

• Controleer de logboeken van de container-app om te zien of er een programmeerfout is:

  1. Ga naar de container-app en ga vervolgens naar Revisiebeheer><actieve container>>Revisiedetails>Console-logboeken.
  2. Kies de volgorde van de kolommen om tijd gegenereerd, Stream_sen Log_sweer te geven.
  3. Sorteer de logboeken op meest recente en zoek naar Python-stderr- en stdout-berichten in de kolom Stream_s. Python print-uitvoer is stdout berichten.

In de Azure CLI:

• Gebruik de az containerapp logs show opdracht.

U wilt de continue implementatie stoppen

Het stoppen van continue implementatie betekent dat de verbinding tussen uw container-app en uw opslagplaats wordt verbroken.

In de Azure-portal:

• Ga naar de container-app. Selecteer in het servicemenu Continue implementatieen selecteer vervolgens Verbinding verbreken.

In de Azure CLI:

• Gebruik de opdracht az container app github-action remove.

Nadat u de verbinding hebt verbroken:

• De .github/workflows/<werkstroomnaam>.yml bestand wordt verwijderd uit uw opslagplaats.
• Geheime sleutels worden niet verwijderd uit de opslagplaats.
• Azure Container Apps blijft als een geautoriseerde OAuth-app voor uw GitHub-account.
• In Azure blijft de laatst geïmplementeerde container over. U kunt de container toepassing opnieuw verbinden met de Azure Container Registry-exemplaar, zodat nieuwe containerrevisies de meest recente afbeeldingen binnenhalen.
• In Azure worden service-principals die u hebt gemaakt en gebruikt voor continue implementatie, niet verwijderd.

Resources verwijderen

Als u klaar bent met de reeks zelfstudies en u geen extra kosten wilt maken, verwijdert u de resources die u hebt gebruikt.

Als u een resourcegroep verwijdert, worden alle resources in de groep verwijderd en is dit de snelste manier om resources te verwijderen. Zie de opschoningsstap van de tutorial Containerizevoor een voorbeeld van het verwijderen van resourcegroepen.

Verwante inhoud

Als u van plan bent om voort te bouwen op deze zelfstudie, volgen hier enkele volgende stappen die u kunt uitvoeren:

• schaalregels instellen in Azure Container Apps
• Aangepaste domeinnamen en certificaten binden in Azure Container Apps
• Een app bewaken in Azure Container Apps