Förstå distributioner från slutpunkt till slutpunkt

  • 5 minuter

GitHub Actions-arbetsflöden är flexibla verktyg som du kan konfigurera på många olika sätt för att passa dina behov. I den här lektionen får du lära dig hur du använder arbetsflöden för att distribuera en hel lösning, inklusive att konfigurera Azure-infrastrukturen och att utföra andra distributionsåtgärder.

Hur många arbetsflöden?

I vissa organisationer skiljer sig teamet som hanterar Azure-miljön från det team som utvecklar koden som körs i miljön. I dessa situationer är det ofta frestande att skapa flera arbetsflöden, som alla ägs av teamet som ansvarar för dess specifika område. Du kan till exempel skapa ett arbetsflöde för att distribuera Bicep-koden som distribuerar webbplatsens Azure-resurser och ett annat arbetsflöde som distribuerar webbplatsprogrammet.

Även om den här metoden kan ge dig viss flexibilitet i hur du hanterar arbetsflöden kan det vara svårt att hålla allt synkroniserat. Anta till exempel att ditt webbplatsteam behöver en ny inställning i sin Azure App Service-app för att aktivera en funktion som den skapar. Arbetsflödet för programdistribution kan inte köras förrän arbetsflödet för infrastrukturdistributionen har slutförts. Det kan också bli komplicerat att skicka data, till exempel namnen på Azure-resurser som skapats av infrastrukturarbetsflödet, mellan arbetsflödena.

I stället är det ofta bättre att skapa ett enda arbetsflöde som distribuerar allt som krävs för din lösning, även om olika team eller olika personer hanterar komponenterna. Du kan använda verktyg som Git och GitHub för att samordna ditt arbete. När en ny funktion läggs till kan du använda en gren för att göra nödvändiga ändringar i Bicep-filen. När ändringen är redo att integreras och släppas utför ett enda arbetsflöde alla steg som krävs för att skapa och distribuera lösningen, vilket minskar risken för att saker blir osynkroniserade.

Dricks

När du skapar kod för din lösning måste du förmodligen distribuera den ofta så att du kan testa hur den fungerar. Du kanske upptäcker att distributionen av infrastrukturen tillsammans med programkoden gör att arbetsflödet körs långsamt och hämmar dina framsteg.

Om du är i den här positionen kan du överväga att inaktivera infrastrukturdistributionen för utvecklingsmiljön. Du kan använda sökvägsfilter, återanvändbara arbetsflöden och villkor för att uppnå detta. Du bör dock lämna den fullständiga distributionssekvensen intakt för dina andra miljöer.

Kontrollplanet och dataplanet

Många Azure-resurser tillhandahåller två olika plan för åtkomst. Kontrollplanet distribuerar och konfigurerar resursen. Med dataplanet kan du komma åt resursens funktioner.

När du skapar och distribuerar Bicep-filer interagerar du med kontrollplanet. I Azure är kontrollplanet Azure Resource Manager. Du använder Resource Manager för att definiera konfigurationen av var och en av dina resurser.

Arbetsflödet behöver dock ofta göra mer än att bara interagera med kontrollplanet. Du kan till exempel behöva:

  • Ladda upp en blob till ett lagringskonto.
  • Ändra ett databasschema.
  • Gör ett API-anrop till en tjänst från tredje part.
  • Utlös en uppdatering av maskininlärningsmodellen.
  • Distribuera en webbplats till en Azure App Service-app.
  • Distribuera programvara till en virtuell dator.
  • Registrera en DNS-post hos en tredjepartsleverantör.

När du överväger ett arbetsflöde från slutpunkt till slutpunkt behöver du vanligtvis distribuera dina Azure-resurser och sedan utföra en serie åtgärder mot dataplan för dessa resurser. Ibland kallas dessa åtgärder för den sista milen i distributionen, eftersom du utför större delen av distributionen med hjälp av kontrollplanet, och endast en liten mängd konfiguration återstår.

Kommentar

Vissa resurser har ingen tydlig uppdelning mellan kontrollplanet och dataplanet. Dessa inkluderar Azure Data Factory och Azure API Management. Båda tjänsterna stöder helt automatiserade distributioner med hjälp av Bicep, men de kräver särskilda överväganden. Du hittar länkar till mer information på sidan Sammanfattning i slutet av modulen.

Så här utför du dataplansåtgärder

När du skapar ett distributionsarbetsflöde som interagerar med dataplanet för dina resurser kan du använda någon av tre vanliga metoder:

  • Resource Manager-distributionsskript
  • Arbetsflödesskript
  • Arbetsflödesåtgärder

Resource Manager-distributionsskript definieras i Bicep-filen. De kör Bash- eller PowerShell-skript och kan interagera med Azure CLI-kommandon och Azure PowerShell-cmdletar. Du skapar en hanterad identitet för distributionsskriptet som ska användas för att autentisera till Azure, och Azure etablerar och hanterar automatiskt de andra resurser som krävs för att köra distributionsskriptet.

Distributionsskript är bra när du behöver köra ett grundläggande skript i distributionsprocessen, men de ger dig inte enkelt åtkomst till andra element från arbetsflödet.

Du kan också köra din egen logik inifrån ett distributionsarbetsflöde. GitHub Actions tillhandahåller ett omfattande ekosystem med åtgärder för vanliga saker som du behöver göra. Om du inte hittar en åtgärd som uppfyller dina behov kan du använda ett skript för att köra din egen Bash- eller PowerShell-kod. Arbetsflödesåtgärder och skript körs från arbetsflödets löpare. Du behöver ofta autentisera åtgärden eller skriptet till dataplanet för den tjänst som du använder, och hur du gör detta beror på tjänsten.

Arbetsflödesåtgärder och skript ger dig flexibilitet och kontroll. De ger dig också åtkomst till arbetsflödesartefakter, som du kommer att lära dig om snart. I den här modulen fokuserar vi på arbetsflödesåtgärder. Vi länkar till mer information om Resource Manager-distributionsskript på sidan Sammanfattning i slutet av modulen.

Utdata

Ett arbetsflöde skapar och konfigurerar vanligtvis dina Azure-resurser genom att distribuera en Bicep-fil. Arbetsflödets efterföljande delar interagerar sedan med dessa resursers dataplan. För att kunna interagera med resurserna behöver arbetsflödesåtgärderna och stegen information om den Azure-resurs som skapades.

Anta till exempel att du har en Bicep-fil som distribuerar ett lagringskonto. Du vill att arbetsflödet ska distribuera lagringskontot och sedan ladda upp några blobar till en blobcontainer i lagringskontot. Arbetsflödessteget som laddar upp blobarna måste känna till namnet på lagringskontot som ska anslutas till och namnet på blobcontainern som filen ska laddas upp till.

Det är bra att låta Bicep-filen bestämma namnen på dina Azure-resurser. Den kan använda parametrar, variabler eller uttryck för att skapa namnen för lagringskontot och blobcontainern. Bicep-filen kan sedan exponera utdata som ger varje resurs namn. Senare steg i arbetsflödet kan läsa utdatavärdet. På så sätt behöver arbetsflödesdefinitionen inte hårdkoda namn eller annan information som kan ändras mellan miljöer eller baseras på regler som definieras i Bicep-filen.

Med GitHub Actions kan du sprida värdena för utdata med hjälp av arbetsflödesvariabler. Åtgärden azure/arm-deploy skapar automatiskt variabler för var och en av dina Bicep-distributionsutdata. Du kan också skapa arbetsflödesvariabler manuellt i skript. Du hittar länkar till mer information på sidan Sammanfattning i slutet av den här modulen.

När du kommer åt variabler som har skapats i ett annat jobb måste du publicera variabeln för att göra den tillgänglig för jobbet som läser den. Anta till exempel att du skapar ett jobb som distribuerar en Bicep-fil och att du måste sprida appServiceAppName utdata till arbetsflödet. Du använder nyckelordet outputs för att ange att appServiceAppName arbetsflödesvariabeln ska anges till värdet för den appServiceAppName utdatavariabel som skapades i deploy steget:

job1:
  runs-on: ubuntu-latest
  outputs:
    appServiceAppName: ${{ steps.deploy.outputs.appServiceAppName }}
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
  - uses: azure/arm-deploy@v1
    id: deploy
    name: Deploy Bicep file
    with:
      failOnStdErr: false
      deploymentName: ${{ github.run_number }}
      resourceGroupName: Playground1
      template: ./deploy/main.bicep

I ett senare jobb skapar du sedan ett explicit beroende av jobbet som skapade variabeln genom att inkludera nyckelordet needs , och du refererar till variabeln med hjälp av namnet på den publicerade variabeln:

job2:
  needs: job1
  runs-on: ubuntu-latest
  steps:
  - run: |
      echo "${{needs.job1.outputs.appServiceAppName}}"

Genom att använda Bicep-utdata och arbetsflödesvariabler kan du skapa ett arbetsflöde som distribuerar Bicep-koden och sedan utföra olika åtgärder på resurserna som en del av distributionen.