Dela via

Distribuera till Azure-infrastruktur med GitHub Actions

I den här guiden går vi igenom hur du använder CI/CD och Infrastruktur som kod (IaC) för att distribuera till Azure med GitHub Actions på ett automatiserat och repeterbart sätt.

Den här artikeln är en arkitekturöversikt och visar en strukturerad lösning för att utforma ett program i Azure som är skalbart, säkert, motståndskraftigt och med hög tillgänglighet. Om du vill se fler verkliga exempel på molnarkitekturer och lösningsidéer kan du bläddra i Azure-arkitekturer.

Fördelar med att använda IaC och automatisering för distributioner

Det finns många sätt att distribuera till Azure, inklusive Azure-portalen, CLI, API med mera. I den här guiden använder vi IaC- och CI/CD-automatisering. Fördelarna med den här metoden är:

  • Deklarativ: När du definierar din infrastruktur- och distributionsprocess i kod kan den versionshanteras och granskas med hjälp av standardlivscykeln för programvaruutveckling. IaC hjälper också till att förhindra eventuella avvikelser i din konfiguration.

  • Konsekvens: Genom att följa en IaC-process ser du till att hela organisationen följer en standard, väletablerad metod för att distribuera infrastruktur som innehåller bästa praxis och är härdad för att uppfylla dina säkerhetsbehov. Alla förbättringar som görs i de centrala mallarna kan enkelt tillämpas i hela organisationen.

  • Säkerhet: Centralt hanterade mallar kan härdas och godkännas av ett molndrifts- eller säkerhetsteam för att uppfylla interna standarder.

  • Självbetjäning: Teams kan få möjlighet att distribuera sin egen infrastruktur genom att använda centralt hanterade mallar.

  • Förbättrad produktivitet: Genom att använda standardmallar kan team snabbt etablera nya miljöer utan att behöva oroa sig för all implementeringsinformation.

Ytterligare information finns under repeterbar infrastruktur i Azure Architecture Center eller vad som är infrastruktur som kod i DevOps Resource Center.

Architecture

Arkitekturöversikt över hur du använder CI/CD för att distribuera Azure

Dataflöde

  1. Skapa en ny gren och kontrollera nödvändiga IaC-kodändringar.
  2. Skapa en pull-begäran (PR) i GitHub när du är redo att sammanfoga dina ändringar i din miljö.
  3. Ett GitHub Actions-arbetsflöde utlöses för att säkerställa att koden är väl formaterad, internt konsekvent och skapar säker infrastruktur. Dessutom körs en Terraform-plan eller Bicep-konsekvensanalys för att generera en förhandsversion av de ändringar som kommer att ske i din Azure-miljö.
  4. När PR har granskats på rätt sätt kan den slås ihop med din huvudgren.
  5. Ett annat GitHub Actions-arbetsflöde utlöses från huvudgrenen och kör ändringarna med din IaC-provider.
  6. (exklusivt för Terraform) Ett regelbundet schemalagt GitHub Action-arbetsflöde bör också köras för att söka efter eventuella konfigurationsavvikelser i din miljö och skapa ett nytt problem om ändringar identifieras.

Förutsättningar

Använd Bicep

  1. Skapa GitHub-miljöer

    Arbetsflödena använder GitHub-miljöer och hemligheter för att lagra Azure-identitetsinformationen och konfigurera en godkännandeprocess för distributioner. Skapa en miljö med namnet production genom att följa dessa instruktioner. I miljön production konfigurerar du en skyddsregel och lägger till alla nödvändiga godkännare som du vill ska kunna signera produktionssättningar. Du kan också begränsa miljön till din huvudgren. Detaljerade instruktioner finns här.

  2. Konfigurera Azure Identity:

    Ett Azure Active Directory-program krävs som har behörighet att distribuera i din Azure-prenumeration. Skapa ett enda program och ge det lämpliga läs-/skrivbehörigheter i din Azure-prenumeration. Konfigurera sedan de federerade autentiseringsuppgifterna så att GitHub kan använda identiteten med hjälp av OpenID Connect (OIDC). Mer information finns i Azure-dokumentationen . Tre federerade autentiseringsuppgifter måste läggas till:

    • Ange Entitetstyp till Environment och använd production miljönamnet.
    • Ange Entitetstyp till Pull Request.
    • Ange Entitetstyp till Branch och använd main grennamnet.

  3. Lägga till GitHub-hemligheter

    Anmärkning

    Ingen av data om Azure-identiteterna innehåller några hemligheter eller autentiseringsuppgifter, men vi använder fortfarande GitHub-hemligheter som ett praktiskt sätt att parametrisera identitetsinformationen per miljö.

    Skapa följande hemligheter på lagringsplatsen med hjälp av Azure-identiteten:

    • AZURE_CLIENT_ID : Program-ID:t (klient) för appregistreringen i Azure
    • AZURE_TENANT_ID : Klient-ID för Azure Active Directory där appregistreringen är definierad.
    • AZURE_SUBSCRIPTION_ID : Prenumerations-ID:t där appregistreringen definieras.

    Instruktioner för att lägga till hemligheterna på lagringsplatsen finns här.

Använda Terraform

  1. Konfigurera Terraform State Location

    Terraform använder en tillståndsfil för att lagra information om det aktuella tillståndet för din hanterade infrastruktur och tillhörande konfiguration. Den här filen måste sparas mellan olika körningar av arbetsflödet. Den rekommenderade metoden är att lagra den här filen i ett Azure Storage-konto eller någon annan liknande fjärrserverdel. Normalt etableras den här lagringen manuellt eller via ett separat arbetsflöde. Terraform-serverdelsblocket behöver uppdateras med den valda lagringsplatsen (se här för dokumentation).

  2. Skapa GitHub-miljö

    Arbetsflödena använder GitHub-miljöer och hemligheter för att lagra Azure-identitetsinformationen och konfigurera en godkännandeprocess för distributioner. Skapa en miljö med namnet production genom att följa dessa instruktioner. I miljön production konfigurerar du en skyddsregel och lägger till de godkännare du vill ha som ska godkänna produktionsinstallationer. Du kan också begränsa miljön till din huvudgren. Detaljerade instruktioner finns här.

  3. Konfigurera Azure Identity:

    Ett Azure Active Directory-program krävs som har behörighet att distribuera i din Azure-prenumeration. Skapa ett separat program för en read-only och read/write konton och ge dem rätt behörigheter i din Azure-prenumeration. Dessutom behöver båda rollerna minst Reader and Data Access behörighet till lagringskontot där Terraform-tillståndet från steg 1 finns. Konfigurera sedan de federerade autentiseringsuppgifterna så att GitHub kan använda identiteten med hjälp av OpenID Connect (OIDC). Mer information finns i Azure-dokumentationen .

    För identiteten read/write skapar du en federerad autentiseringsuppgift enligt följande:

    • Ange Entity Type till Environment och använd production miljönamnet.

    För identiteten read-only skapar du två federerade autentiseringsuppgifter på följande sätt:

    • Ställ in Entity Type på Pull Request.
    • Ange Entity Type till Branch och använd main grennamnet.

  4. Lägga till GitHub-hemligheter

    Anmärkning

    Ingen av data om Azure-identiteterna innehåller några hemligheter eller autentiseringsuppgifter, men vi använder fortfarande GitHub-hemligheter som ett praktiskt sätt att parametrisera identitetsinformationen per miljö.

    Skapa följande hemligheter på lagringsplatsen med hjälp av identiteten read-only :

    • AZURE_CLIENT_ID : Program-ID:t (klient) för appregistreringen i Azure
    • AZURE_TENANT_ID : Klient-ID för Azure Active Directory där appregistreringen är definierad.
    • AZURE_SUBSCRIPTION_ID : Prenumerations-ID:t där appregistreringen definieras.

    Instruktioner för att lägga till hemligheterna på lagringsplatsen finns här.

    Skapa en annan hemlighet i production miljön med hjälp av identiteten read-write :

    • AZURE_CLIENT_ID : Program-ID:t (klient) för appregistreringen i Azure

    Instruktioner för att lägga till hemligheter i miljön finns här. Miljöhemligheten åsidosätter källförvarets hemlighet när distributionssteget utförs till production miljön, där utökade läs-/skrivbehörigheter krävs.

Distribuera med GitHub Actions

Använd Bicep

Det finns två huvudsakliga arbetsflöden som ingår i referensarkitekturen:

  1. Bicep-enhetstester

    Det här arbetsflödet körs vid varje commit och består av en uppsättning enhetstester av infrastrukturkoden. Den kör bicep build för att kompilera bicep till en ARM-mall. Detta säkerställer att det inte finns några formateringsfel. Därefter utför den en verifiering för att säkerställa att mallen kan distribueras. Slutligen körs checkov, ett analysverktyg för statisk kod med öppen källkod för IaC, för att identifiera säkerhets- och efterlevnadsproblem. Om lagringsplatsen använder GitHub Advanced Security (GHAS) laddas resultatet upp till GitHub.

  2. Bicep Hypotetisk/Distribuera

    Det här arbetsflödet körs på varje pull request och vid varje commit till huvudgrenen. Konsekvensfasen i arbetsflödet används för att förstå effekten av IaC-ändringarna på Azure-miljön genom att köra konsekvensanalys. Den här rapporten bifogas sedan pr för enkel granskning. Implementeringsfasen körs efter vad händer om-analysen när arbetsflödet utlöses av en push till huvudgrenen. Det här steget distribuerar mallen till Azure när en manuell granskning har godkänts.

Använda Terraform

Det finns tre huvudsakliga arbetsflöden som ingår i referensarkitekturen:

  1. Terraform-enhetstester

    Det här flödet körs för varje commit och består av en serie enhetstester på infrastrukturkoden. Den kör terraform fmt för att säkerställa att koden är korrekt linted och följer terraform bästa praxis. Därefter utför den terraform-verifiering för att kontrollera att koden är syntaktiskt korrekt och internt konsekvent. Slutligen körs checkov, ett analysverktyg för statisk kod med öppen källkod för IaC, för att identifiera säkerhets- och efterlevnadsproblem. Om lagringsplatsen använder GitHub Advanced Security (GHAS) laddas resultatet upp till GitHub.

  2. Terraform-plan/Använd

    Det här arbetsflödet körs på varje pull request och vid varje commit till huvudgrenen. Planeringssteget i arbetsflödet används för att förstå effekten av IaC-ändringarna på Azure-miljön genom att köra terraform-planen. Den här rapporten bifogas sedan pr för enkel granskning. Tillämpningsfasen körs efter planeringen när arbetsflödet utlöses av en push till huvudgrenen. Det här steget tar plandokumentet och tillämpar ändringarna efter att en manuell granskning har slutförts och godkänt eventuella väntande ändringar i miljön.

  3. Detektering av Terraform-drift

    Det här arbetsflödet körs regelbundet för att genomsöka din miljö efter eventuella konfigurationsavvikelser eller ändringar som görs utanför Terraform. Om någon drift identifieras genereras ett GitHub-problem för att varna projektunderhållarna.

  • Last updated on