Python-web-apps implementeren in App Service met behulp van GitHub Actions (Linux)

In dit artikel wordt beschreven hoe u het CI/CD-platform (continue integratie en continue levering) in GitHub Actions gebruikt om een Python-web-app te implementeren in Azure App Service op Linux. Uw GitHub Actions-werkstroom bouwt automatisch de code en implementeert deze in het App Service-exemplaar wanneer er een doorvoering naar de opslagplaats is. U kunt andere automatisering toevoegen in uw GitHub Actions-werkstroom, zoals testscripts, beveiligingscontroles en implementatie met meerdere fasen.

Opslagplaats voor app-code maken

Als u de procedures in dit artikel wilt voltooien, hebt u een Python-web-app nodig die is vastgelegd in een GitHub-opslagplaats.

• Bestaande app: Als u een bestaande Python-web-app wilt gebruiken, moet u ervoor zorgen dat de app wordt doorgevoerd in een GitHub-opslagplaats.

• Nieuwe app: Als u een nieuwe Python-web-app nodig hebt, kunt u de https://github.com/Microsoft/python-sample-vscode-flask-tutorial GitHub-opslagplaats splitsen en klonen. De voorbeeldcode ondersteunt de zelfstudie Flask in Visual Studio Code en biedt een werkende Python-toepassing.

Doel-App Service-exemplaar maken

De snelste manier om een App Service-exemplaar te maken, is door de Azure-opdrachtregelinterface (CLI) te gebruiken via de interactieve Azure Cloud Shell. Cloud Shell bevat Git en de Azure CLI. In de volgende procedure gebruikt u de opdracht az webapp up om zowel het App Service-exemplaar te maken als de eerste implementatie van uw app uit te voeren.

1. Meld u aan bij de Azure Portal op https://portal.azure.com.

2. Open de Azure CLI door de Cloud Shell-optie te selecteren op de werkbalk van de portal:

   

3. Selecteer in Cloud Shell de optie Bash in de vervolgkeuzelijst:

   

4. Kloon uw opslagplaats in Cloud Shell met behulp van de git-kloonopdracht .

   Aanbeveling

   Als u opdrachten of tekst in Cloud Shell wilt plakken, gebruikt u de sneltoets Ctrl+Shift+V of klikt u met de rechtermuisknop en selecteert u Plakken in het contextmenu.

   • Voor de Flask-voorbeeld-app kunt u de volgende opdracht gebruiken. Vervang het <github-user> gedeelte door de naam van het GitHub-account waar u de opslagplaats hebt gesplitst:

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

   • Als uw app zich in een andere opslagplaats bevindt, stelt u GitHub Actions in voor de specifieke opslagplaats. Vervang het <github-user> gedeelte door de naam van het GitHub-account waar u de opslagplaats hebt gesplitst en geef de werkelijke naam van de opslagplaats op in de <repo-name> tijdelijke aanduiding:

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

   Opmerking

   Cloud Shell wordt ondersteund door een Azure Storage-account in een resourcegroep met de naam cloud-shell-storage-your-region<>. Dat opslagaccount bevat een afbeelding van het Cloud Shell-bestandssysteem, waarin de gekloonde opslagplaats is opgeslagen. Er zijn kleine kosten voor deze opslag. U kunt het opslagaccount verwijderen nadat u dit artikel hebt voltooid, samen met andere resources die u maakt.

5. Wijzig in Cloud Shell de map in de opslagplaatsmap voor uw Python-app, zodat de opdracht az webapp up de app herkent als Python. Voor de Flask-voorbeeld-app gebruikt u de volgende opdracht:

   cd python-sample-vscode-flask-tutorial
   

6. Gebruik in Cloud Shell de opdracht az webapp up om een App Service-exemplaar te maken en voer de eerste implementatie voor uw app uit:

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

   • Geef voor de <app-service-name> tijdelijke aanduiding een App Service-naam op die uniek is in Azure. De naam moet 3 tot 60 tekens lang zijn en mag alleen letters, cijfers en afbreekstreepjes bevatten. De naam moet beginnen met een letter en eindigen op een letter of cijfer.

   • Gebruik de az webapp list-runtimes opdracht voor een lijst met beschikbare runtimes op uw systeem.

   • Wanneer u de runtimewaarde in de opdracht invoert, gebruikt u de PYTHON:X.Y indeling, waarbij X.Y de primaire en secundaire versie van Python is.

   • U kunt ook de regiolocatie van het App Service-exemplaar opgeven met behulp van de --location parameter. Gebruik de az account list-locations --output table opdracht voor een lijst met beschikbare locaties.

7. Als uw app een aangepast opstartscript heeft, gebruikt u de opdracht az webapp config om het script te initiëren.

   • Als uw app geen aangepast opstartscript heeft, gaat u verder met de volgende stap.

   • Voor de Flask-voorbeeld-app moet u toegang krijgen tot het opstartscript in het startup.txt-bestand door de volgende opdracht uit te voeren:

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

     Geef de naam van uw resourcegroep en de naam van het App Service-exemplaar op in de <resource-group-name> en <app-service-name> tijdelijke aanduidingen. Als u de naam van de resourcegroep wilt vinden, controleert u de uitvoer van de vorige az webapp up opdracht. De naam van de resourcegroep bevat de Naam van het Azure-account, gevolgd door het achtervoegsel _rg , zoals in <azure-account-name>_rg_.

8. Als u de actieve app wilt weergeven, opent u een browser en gaat u naar het implementatie-eindpunt voor uw App Service-exemplaar. Vervang in de volgende URL de tijdelijke aanduiding <app-service-name> door de naam van uw App Service-exemplaar:

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

   Als u een algemene pagina ziet, wacht u enkele seconden totdat het App Service-exemplaar is gestart en vernieuwt u de pagina.

   • Als u een algemene pagina blijft zien, controleert u of u hebt geïmplementeerd vanuit de juiste map.
   • Bevestig voor de Flask-voorbeeld-app dat u hebt geïmplementeerd vanuit de map python-sample-vscode-flask-tutorial . Controleer ook of u de opstartopdracht juist instelt.

Continue implementatie instellen in App Service

In de volgende procedure stelt u continue levering (CD) in, wat betekent dat er een nieuwe code-implementatie plaatsvindt wanneer een werkstroom wordt geactiveerd. De trigger in het voorbeeld van het artikel is elke wijziging in de hoofdbranch van uw opslagplaats, zoals met een pull-aanvraag (PR).

1. Controleer in Cloud Shell of u zich in de hoofdmap voor uw systeem (~) bevindt en niet in een app-submap, zoals python-sample-vscode-flask-tutorial.

2. Voeg GitHub Actions toe met het commando az webapp deployment github-actions add. Vervang tijdelijke aanduidingen door uw specifieke waarden:

   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
   

   • De --login-with-github parameter maakt gebruik van een interactieve methode om een persoonlijk toegangstoken op te halen. Volg de aanwijzingen en voltooi de verificatie.

   • Als het systeem een bestaand werkstroombestand met dezelfde naam van het App Service-exemplaar tegenkomt, volgt u de aanwijzingen om te kiezen of u de werkstroom wilt overschrijven. U kunt de --force parameter met de opdracht gebruiken om conflicterende werkstromen automatisch te overschrijven.

   Met add de opdracht worden de volgende taken uitgevoerd:

   • Hiermee maakt u een nieuw werkstroombestand op de .github/workflows/<werkstroomnaam>.yml pad in uw opslagplaats. De bestandsnaam bevat de naam van uw App Service-exemplaar.
   • Haalt een publicatieprofiel op met geheimen voor uw App Service-exemplaar en voegt dit toe als een GitHub-actiegeheim. De naam van het geheim begint met AZUREAPPSERVICE_PUBLISHPROFILE_. Naar dit geheim wordt verwezen in het werkstroombestand.

3. Haal de details van een implementatieconfiguratie voor broncodebeheer op met de opdracht az webapp deployment source show . Vervang de tijdelijke aanduidingsparameters door uw specifieke waarden:

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

4. Bevestig in de uitvoer van de opdracht de waarden voor de repoUrl en branch eigenschappen. Deze waarden moeten overeenkomen met de waarden die u hebt opgegeven met de add opdracht.

GitHub-werkstroom en -acties onderzoeken

Een werkstroomdefinitie wordt opgegeven in een YAML-bestand (.yml) in het pad /.github/workflows/ in uw opslagplaats. Dit YAML-bestand bevat de verschillende stappen en parameters waaruit de werkstroom bestaat, een geautomatiseerd proces dat is gekoppeld aan een GitHub-opslagplaats. U kunt elk project bouwen, testen, verpakken, vrijgeven en implementeren op GitHub met een werkstroom.

Elke werkstroom bestaat uit een of meer taken en elke taak bestaat uit een reeks stappen. Elke stap is een shellscript of een actie. Elke taak heeft een sectie Actie in het werkstroombestand.

In termen van de werkstroom die is ingesteld met uw Python-code voor implementatie in Azure App Service, heeft de werkstroom de volgende acties:

De werkstroomsjabloon die wordt gebruikt om de werkstroom te maken, is Azure/actions-workflow-samples.

De werkstroom wordt geactiveerd bij push-events naar de opgegeven branch. De gebeurtenis en vertakking worden gedefinieerd aan het begin van het werkstroombestand. In het volgende codefragment ziet u bijvoorbeeld dat de werkstroom wordt geactiveerd bij pushgebeurtenissen naar de hoofdbranch :

on:
  push:
    branches:
    - main

Geautoriseerde OAuth-apps

Wanneer u continue implementatie instelt, autoriseert u Azure App Service als een geautoriseerde OAuth-app voor uw GitHub-account. App Service gebruikt de geautoriseerde toegang om een YAML-bestand voor gitHub-acties te maken op de .github/workflows/<workflow-name>.yml pad in uw opslagplaats.

Als u uw geautoriseerde apps wilt zien en machtigingen wilt intrekken onder uw GitHub-accounts, gaat u naar Instellingenintegraties>/Toepassingen:

Geheim van workflow-publicatieprofiel

In de .github/workflows/<werkstroomnaam>.yml werkstroombestand dat is toegevoegd aan uw opslagplaats, is er een tijdelijke aanduiding voor het publiceren van profielreferenties die vereist zijn voor de implementatietaak van de werkstroom. De publicatieprofielgegevens worden versleuteld opgeslagen in de opslagplaats.

Als u het geheim wilt weergeven, gaat u naar Instellingen>beveiligingsgeheim>en variabelenacties>:

In dit artikel wordt de GitHub-actie geverifieerd met een referentie voor een publicatieprofiel. Er zijn andere manieren om te verifiëren, zoals met een service-principal of OpenID Connect. Zie Implementeren in App Service met behulp van GitHub Actions voor meer informatie.

Werkstroom uitvoeren en testen

De laatste stap is het testen van de workflow door een wijziging aan te brengen in de repository.

1. Ga in een browser naar je fork van de voorbeeldrepository (of de repository die je hebt gebruikt) en selecteer de branch die je hebt ingesteld als onderdeel van de trigger.

   

2. Breng een kleine wijziging aan in uw Python-web-app.

   Voor de Flask-handleiding is hier een eenvoudige wijziging:

   1. Ga naar het bestand /hello-app/templates/home.html van de triggervertakking.
   2. Kies Bewerken (potlood).
   3. Zoek in de editor de afdrukinstructie <p> en voeg de tekst "Opnieuw ingezet!" toe.

3. Voer de wijziging rechtstreeks door naar de vertakking waarin u werkt.

   1. Selecteer wijzigingen doorvoeren in de editor rechtsboven. Het venster Wijzigingen doorvoeren wordt geopend.
   2. Wijzig in het venster Wijzigingen doorvoeren het doorvoerbericht naar wens en selecteer Wijzigingen doorvoeren.

   Het doorvoerproces activeert de GitHub Actions-werkstroom.

U kunt de werkstroom ook handmatig activeren:

1. Ga naar het tabblad Acties van de opslagplaats die is ingesteld voor continue implementatie.

2. Selecteer de werkstroom in de lijst met werkstromen en selecteer vervolgens Werkstroom uitvoeren.

Problemen met een mislukte workflow oplossen

U kunt de status van een werkstroom controleren op het tabblad Acties voor de app-opslagplaats. Wanneer u het werkstroombestand bekijkt dat in dit artikel is gemaakt, ziet u twee taken: bouwen en implementeren. Ter herinnering is de werkstroom gebaseerd op de sjabloon Azure/actions-workflow-samples .

Voor een mislukte taak bekijkt u de uitvoer van taaktaken voor een indicatie van de fout.

Hier volgen enkele veelvoorkomende problemen om te onderzoeken:

• Als de app mislukt vanwege een ontbrekende afhankelijkheid, is uw requirements.txt bestand niet verwerkt tijdens de implementatie. Dit gedrag treedt op als u de web-app rechtstreeks in de portal hebt gemaakt in plaats van de opdracht te gebruiken az webapp up , zoals wordt weergegeven in dit artikel.

• Als u de app-service hebt geconfigureerd via de portal, wordt de instelling voor de build-actie SCM_DO_BUILD_DURING_DEPLOYMENT mogelijk niet ingesteld. Deze instelling moet zijn ingesteld op true. Met az webapp up de opdracht wordt de build-actie automatisch ingesteld.

• Als u een foutbericht ziet met betrekking tot de time-out voor TLS-handshake, voert u de werkstroom handmatig uit door automatische implementatie activeren te selecteren op het tabblad Acties van de app-opslagplaats. U kunt bepalen of de time-out een tijdelijk probleem is.

• Als u continue implementatie instelt voor de container-app, zoals wordt weergegeven in dit artikel, wordt het oorspronkelijke werkstroombestand .github/workflows/<workflow-name>.yml automatisch voor u gemaakt. Als u het bestand hebt gewijzigd, verwijdert u de wijzigingen om te zien of deze de fout veroorzaken.

Script na implementatie uitvoeren

Een script na de implementatie kan verschillende taken uitvoeren, zoals het definiëren van omgevingsvariabelen die worden verwacht door de app-code. U voegt het script toe als onderdeel van de app-code en voert het script uit met behulp van de opstartopdracht.

Als u hardcoderingsvariabelewaarden in uw YAML-werkstroombestand wilt voorkomen, kunt u overwegen om de variabelen in GitHub te configureren en te verwijzen naar de namen van variabelen in het script. U kunt versleutelde geheimen maken voor een opslagplaats of voor een omgeving (accountopslagplaats). Zie Geheimen gebruiken in GitHub Actions voor meer informatie.

Django-overwegingen bekijken

Zoals eerder in dit artikel is vermeld, kunt u GitHub Actions gebruiken om Django-apps te implementeren in Azure App Service op Linux, als u een afzonderlijke database gebruikt. U kunt geen SQLite-database gebruiken omdat App Service het bestand db.sqlite3 vergrendelt, waardoor zowel lees- als schrijfbewerkingen worden voorkomen. Dit gedrag heeft geen invloed op een externe database.

In het artikel Python-app configureren in App Service - Container opstarten wordt beschreven hoe App Service automatisch zoekt naar een wsgi.py-bestand in uw app-code, dat meestal het app-object bevat. Wanneer u de opdracht hebt gebruikt om de webapp config set opstartopdracht in te stellen, hebt u de --startup-file parameter gebruikt om het bestand op te geven dat het app-object bevat. De webapp config set opdracht is niet beschikbaar in de webapps-deploy-actie. In plaats daarvan kunt u de startup-command parameter gebruiken om de opstartopdracht op te geven. De volgende code laat bijvoorbeeld zien hoe u de opstartopdracht opgeeft in het werkstroombestand:

startup-command: startup.txt

Wanneer u Django gebruikt, wilt u doorgaans de gegevensmodellen migreren met behulp van de python manage.py migrate opdracht nadat u de app-code hebt geïmplementeerd. U kunt de migratieopdracht uitvoeren in een script na de implementatie.

Verbinding verbreken met GitHub Actions

Als u de verbinding met GitHub Actions van uw App Service-exemplaar verbreekt, kunt u de implementatie van de app opnieuw configureren. U kunt kiezen wat er gebeurt met uw werkstroombestand nadat u de verbinding hebt verbroken en of u het bestand wilt opslaan of verwijderen.

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

De hulpbronnen opschonen

Verwijder de resourcegroep met het App Service-exemplaar en het App Service-plan om te voorkomen dat er kosten in rekening worden gebracht voor de Azure-resources die in dit artikel zijn gemaakt.

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

Opslagaccount verwijderen

Als u het opslagaccount wilt verwijderen dat het bestandssysteem voor Cloud Shell onderhoudt, waarvoor een kleine maandelijkse kosten in rekening worden gebracht, verwijdert u de resourcegroep die begint met cloud-shell-storage. Als u de enige gebruiker van de groep bent, is het veilig om de resourcegroep te verwijderen. Als er andere gebruikers zijn, kunt u een opslagaccount in de resourcegroep verwijderen.

GitHub-account en opslagplaats bijwerken

Als u de Azure-resourcegroep verwijdert, kunt u overwegen de volgende wijzigingen aan te brengen in het GitHub-account en de opslagplaats die is verbonden voor continue implementatie:

• Verwijder in de app-opslagplaats het bestand .github/workflows/<workflow-name>.yml .
• Verwijder in de instellingen van de app-opslagplaats de AZUREAPPSERVICE_PUBLISHPROFILE_ geheime sleutel die voor de werkstroom is gemaakt.
• Verwijder Azure App Service in de instellingen van het GitHub-account als een geautoriseerde OAuth-app voor uw GitHub-account.

Verwante inhoud

• Algemene opslagplaatsen en werkstromen voor GitHub Actions
• Commandoverwijzing - az webapp implementatie github-actions