Distribuera Bicep-filer med hjälp av ett arbetsflöde

  • 7 minuter

Nu när du har skapat ett grundläggande arbetsflöde är du redo att konfigurera arbetsflödet för att distribuera dina Bicep-filer. I den här lektionen får du lära dig hur du distribuerar Bicep-kod från ett arbetsflöde och hur du konfigurerar distributionsstegen.

Kommentar

Kommandona i den här enheten visas för att illustrera begrepp. Kör inte kommandona än. Du kommer att öva på det du lär dig här snart.

Kolla in din kod

Dina Bicep-filer lagras på din Git-lagringsplats. I GitHub Actions måste du uttryckligen be arbetsflödet att checka ut filerna från din Git-lagringsplats. Annars har arbetsflödet inte åtkomst till filerna. Det här steget är vanligtvis det första jobbet gör.

Om du vill kolla in koden kan du använda åtgärden actions/checkout@v3 :

name: MyWorkflow

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
      with:
        path: repo

Observera att arbetsflödet innehåller nyckelordet uses . Nyckelordet anger att du vill använda en fördefinierad åtgärd med namnet actions/checkout.

Precis som Bicep-resurser är åtgärderna alltid versionshanterade. I det här fallet använder arbetsflödet version 3, så @v3 läggs till i åtgärdsnamnet.

När arbetsflödet innehåller den här åtgärden checkas lagringsplatsens kod ut till löparens filsystem. Du anger sökvägen som filerna ska lagras i med hjälp av parametern path .

Autentisera till Azure

När du distribuerar en Bicep-fil från din egen dator använder du Azure CLI eller Azure PowerShell. Innan du kan distribuera koden måste du logga in på Azure. Vanligtvis ber verktygen dig att ange dina autentiseringsuppgifter i en webbläsare. När dina autentiseringsuppgifter har verifierats bekräftas dina behörigheter för att distribuera resurser och du kan använda verktygen för att distribuera Bicep-filen.

Dricks

I den här modulen skapar du en arbetsbelastningsidentitet som arbetsflödet ska använda. Modulen Autentisera ditt Azure-distributionsarbetsflöde med hjälp av arbetsbelastningsidentiteter ger en mer detaljerad förklaring av arbetsbelastningsidentiteter, inklusive hur de fungerar, samt hur du skapar dem, tilldelar dem roller och hanterar dem.

Distribution efter arbetsflöde kräver också autentisering. Eftersom arbetsflöden körs utan mänsklig inblandning autentiseras arbetsflöden till Azure med hjälp av en arbetsbelastningsidentitet. GitHub och Microsoft Entra ID fungerar tillsammans för att autentisera arbetsflödet på ett säkert sätt utan att behöva några autentiseringsuppgifter.

När arbetsflödet behöver kommunicera med Azure loggar ett arbetsflödessteg in på Azure med hjälp av en arbetsbelastningsidentitet. Sedan använder de steg som definieras i arbetsflödet arbetsflödets identitet.

Diagram that shows a workflow that includes an Azure deployment step, which accesses a secret and then deploys to Azure.

Du måste se till att din arbetsbelastningsidentitet har de behörigheter som krävs för att köra distributionsstegen. Du kan till exempel behöva tilldela arbetsbelastningsidentiteten rollen Deltagare för resursgruppen där du distribuerar dina resurser.

Varning

Det kan verka enklare att lagra dina användarautentiseringsuppgifter i YAML-filen och sedan logga in med kommandot az login . Du bör aldrig använda den här metoden för att autentisera arbetsflödet. Autentiseringsuppgifter i en YAML-fil lagras i klartext. Alla som har åtkomst till din lagringsplats kan se och använda autentiseringsuppgifterna. Även om du begränsar åtkomsten till din GitHub-lagringsplats finns YAML-filen som innehåller autentiseringsuppgifterna på den personens dator när någon klonar din lagringsplats.

Logga in på Azure

Innan arbetsflödet kan köra kommandon mot din Azure-miljö måste det först logga in. Det finns en åtgärd med namnet azure/login som hanterar inloggningsprocessen. Du måste också bevilja behörighet för arbetsflödet att fungera med autentiseringstoken.

name: MyWorkflow

on: [workflow_dispatch]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
      with:
        path: repo
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Åtgärden azure/login kräver att du anger tre typer av information för att använda en arbetsbelastningsidentitet: ett Microsoft Entra-program-ID, ditt Microsoft Entra-klient -ID (katalog) och det Azure-prenumerations-ID som du vill arbeta med.

När den här åtgärden har körts autentiseras din löpare och kan köra instruktioner mot din Azure-miljö.

Distribuera Bicep-filen

När arbetsflödet har loggat in på Azure kan det använda arbetsbelastningsidentiteten för att köra Bicep-distributionen. I GitHub Actions använder du åtgärden azure/arm-deploy för att initiera en Bicep-distribution.

Kommentar

Det finns andra sätt att distribuera Bicep-filer från GitHub Actions. Du kan till exempel använda åtgärden azure/CLI och sedan ange Azure CLI-kommandon för att köra dina distributioner. Men eftersom uppgiften azure/arm-deploy är särskilt utformad för distributioner använder du den i den här modulen.

Här är ett exempel på hur du kan konfigurera ett steg för att använda åtgärden azure/arm-deploy :

name: MyWorkflow

on: [workflow_dispatch]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
      with:
        path: repo
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      with:
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=Test

Åtgärden azure/arm-deploy accepterar flera parametrar, inklusive:

  • resourceGroupName: Namnet på den resursgrupp där du vill distribuera de resurser som definieras i Bicep-filen.
  • template: Sökvägen till Bicep-filen på lagringsplatsen. Sökvägen är relativ till lagringsplatsens rot.
  • parameters: Anger eventuella parametervärden som du anger vid distributionstillfället. I det här exemplet anger vi ett värde för parametern environmentType .

Eftersom föregående azure/login åtgärd redan loggade in arbetsflödet i Azure körs steget på en autentiserad azure/arm-deploy löpare.

Variabler

Ofta innehåller dina arbetsflöden värden som du vill återanvända på flera platser i arbetsflödesfilen. Du kanske också vill lagra dessa värden överst i arbetsflödesfilen för enkel referens och enkelt kunna ändra värdena. I arbetsflödet visas de variabler som du definierar som miljövariabler. Om du vill definiera återanvändbara värden använder du variabler.

Skapa en variabel

Du kan skapa variabler på olika nivåer i arbetsflödesfilen. Men om du vill att de ska vara tillgängliga för hela arbetsflödesfilen definierar du dem längst upp i filen, precis under instruktionen on . Om du vill definiera variablerna använder du parametern env :

env:
    AZURE_RESOURCEGROUP_NAME: gh-actions
    AZURE_WEBAPP_NAME: webapp-gh-actions

I föregående exempel anger vi två miljövariabler.

Använda en variabel i arbetsflödet

När du har skapat en variabel använder du en särskild syntax för att referera till den i ditt arbetsflödes YAML-fil, så här:

${{ env.AZURE_RESOURCEGROUP_NAME }}

Standardmiljövariabler

GitHub Actions använder också standardmiljövariabler. Standardmiljövariabler innehåller fördefinierad information som du kanske vill använda i arbetsflödet. Här är några av de standardmiljövariabler som du kan använda i arbetsflödet:

  • github.sha: Identifieraren för Git-incheckningen som utlöste arbetsflödet för körning.
  • github.run_number: Ett unikt nummer för varje körning av ett visst arbetsflöde på en lagringsplats. Det här talet börjar vid 1 för arbetsflödets första körning och ökar med varje ny körning. Du kan använda den här variabeln för att namnge din Azure-distribution, så att du kan spåra distributionen tillbaka till den specifika arbetsflödeskörning som utlöste den.

    Kommentar

    I GitHub Actions kan du köra ett arbetsflöde igen. När du gör det ändras inte körningsnumret, så du bör inte använda variabeln github.run_number för att räkna hur många gånger arbetsflödet har körts.

Hemligheter

Ibland måste du lagra hemlig information som arbetsflödet kan använda, till exempel ett databaslösenord eller en API-nyckel. Du använder GitHub-hemligheter för att lagra information som innehåller autentiseringsuppgifter eller känslig information på ett säkert sätt. Ditt arbetsflöde kan komma åt hemlighetens värde.

Hemligheter skapas i inställningarna för din GitHub-lagringsplats. En hemlighet är tillgänglig för alla arbetsflöden på lagringsplatsen. I en senare modul får du lära dig mer om miljöer, vilket gör att du kan begränsa användningen av hemligheter till distributioner till en specifik miljö.

Varning

Som standard fördunklar GitHub Actions hemliga variabelvärden i arbetsflödesloggar, men du måste också följa god praxis. Arbetsflödesstegen har åtkomst till hemligheternas värden. Om arbetsflödet innehåller ett steg som inte hanterar en hemlighet på ett säkert sätt finns det en risk att det hemliga värdet visas i arbetsflödesloggarna. Du bör alltid noggrant granska eventuella ändringar i en arbetsflödesdefinitionsfil för att kontrollera att hemligheterna inte hanteras felaktigt.

Du kan skapa hemligheter med hjälp av GitHub-webbgränssnittet. Om du vill referera till ett hemligt värde i arbetsflödet använder du följande syntax:

${{ secrets.NAME_OF_THE_SECRET }}

När arbetsflödet startar har den löpare som kör distributionsstegen åtkomst till det dekrypterade GitHub-hemlighetsvärdet. GitHub Actions är utformat för att inte avslöja hemliga värden i arbetsflödesloggarna.

Dricks

Precis som Bicep-parametrar behöver du inte skapa variabler för allt. Det är en bra idé att skapa variabler för allt som kan förändras mellan miljöer och GitHub-hemligheter för allt som är hemligt. Eftersom arbetsflödet alltid använder samma Bicep-fil behöver du inte skapa en variabel för sökvägen.

I den här modulen använder du GitHub-hemligheter för att lagra den information azure/login som uppgiften behöver för att logga in på Azure: din Microsoft Entra-prenumeration och klient-ID och arbetsbelastningsidentitetens programregistrerings-ID.