Bygg en CI/CD-pipeline med GitHub Actions för Azure

Varför GitHub Actions för Azure

GitHub Actions har blivit Microsofts rekommenderade CI/CD-plattform för Azure-driftsättningar. Med Microsofts ägande av GitHub har integrationen mellan de två plattformarna fördjupats avsevärt. Azure-specifika actions underhålls som förstapartsutbud, workload identity federation eliminerar behovet av lagrade hemligheter, och GitHubs marknadsplats erbjuder ett rikt ekosystem av återanvändbara actions för vanliga Azure-uppgifter.

För team som redan använder GitHub för versionshantering innebär att anta GitHub Actions för Azure-driftsättningar färre verktyg att hantera, en enhetlig granskningslogg och inbyggd integration med pull request-arbetsflöden. De senaste ändringarna i GitHub Actions, inklusive uppdateringar av runner-avbildningar och action-versioner, gör det viktigt att hålla sig uppdaterad med bra praxis.

Konfigurera Workload Identity Federation

Den viktigaste förbättringen inom modern Azure CI/CD är workload identity federation med OpenID Connect (OIDC). Detta tillvägagångssätt eliminerar behovet av att lagra service principal-hemligheter i GitHub, vilket var ett bestående säkerhetsproblem med det traditionella tillvägagångssättet med klienthemligheter.

Med OIDC-federation begär GitHub Actions en kortlivad token direkt från Azure Active Directory under varje arbetsflödeskörning. Inga hemligheter lagras, inga uppgifter kan läcka, och tokenrotation sker automatiskt. Förtroenderelationen etableras genom en federerad identitetsuppgift på en Azure AD-applikation eller hanterad identitet.

Här är Azure CLI-kommandona för att konfigurera OIDC-förtroendet mellan GitHub och Azure:

Efter att ha kört dessa kommandon, lägg till följande hemligheter i ditt GitHub-repository: AZURE_CLIENT_ID (applikations-ID), AZURE_TENANT_ID (ditt Azure AD-klient-ID) och AZURE_SUBSCRIPTION_ID (ditt prenumerations-ID). Observera att ingen av dessa är faktiska hemligheter i traditionell mening — de är identifierare som bara är användbara i kombination med OIDC-förtroendet.

Det kompletta GitHub Actions-arbetsflödet

Här är ett produktionsklart arbetsflöde som bygger och driftsätter till Azure App Service med miljöskyddsregler:

Detta arbetsflöde demonstrerar flera bästa praxis. permissions-blocket begär uttryckligen bara de behörigheter som behövs: id-token: write och contents: read, enligt principen om minsta behörighet. Byggsteget körs först och skapar en artefakt som sedan konsumeras av driftsättningsjobben. Detta säkerställer att exakt samma byggartefakt driftsätts till både staging och produktion.

Egenskapen environment på varje driftsättningsjobb länkar det till en GitHub-miljö, där du konfigurerar skyddsregler. I ditt GitHub-repositorys inställningar kan du kräva manuella godkännanden innan produktionsdriftsättningen fortsätter, begränsa vilka grenar som kan driftsätta till produktion och ställa in väntetider mellan driftsättningar.

Miljöskyddsregler

GitHub-miljöer är mekanismen för att styra vem som kan driftsätta vad och var. För arbetsflödet ovan skulle du konfigurera två miljöer i dina repository-inställningar.

För staging-miljön kan du tillåta automatiska driftsättningar från main-grenen men begränsa driftsättningar från andra grenar. För produktionsmiljön skulle du vanligtvis kräva godkännande från en eller flera utsedda granskare, begränsa driftsättningar till enbart main-grenen, och valfritt lägga till en väntetimer för att möjliggöra övervakning av staging-driftsättningen innan produktion fortsätter.

Dessa skyddsregler upprätthålls av GitHub oavsett vad arbetsflödets YAML säger, vilket ger en säkerhetsgräns som inte kan kringgås genom att ändra arbetsflödesfilen.

Återanvändbara arbetsflöden

När din organisation växer kommer du sannolikt att ha flera repositoryn som driftsätter till Azure. Istället för att duplicera arbetsflödesfiler stöder GitHub Actions återanvändbara arbetsflöden som du definierar en gång och anropar från andra arbetsflöden.

Mönstret innebär att skapa ett centralt repository med arbetsflödesmallar som accepterar parametrar för applikationsnamn, Azure-resursgrupp och miljö. Enskilda repositoryn anropar sedan dessa återanvändbara arbetsflöden med sina specifika värden. Detta säkerställer konsekvens över din organisations driftsättningar och gör det enkelt att uppdatera driftsättningspraxis på ett ställe.

Viktiga överväganden

När du bygger din pipeline, håll dessa punkter i åtanke. Först, fixera alltid dina action-versioner till specifika commits eller huvudversioner istället för att använda latest. Meddelandet om kommande brytande ändringar från GitHub belyser varför detta är viktigt — uppdateringar av runner-avbildningar och utfasning av action-versioner kan bryta arbetsflöden som inte är fixerade.

Använd för det andra azure/login@v2-actionen, som stöder OIDC inbyggt. Tidigare versioner krävde annorlunda konfiguration.

För det tredje, separera dina bygg- och driftsättningssteg i olika jobb. Detta gör att du kan driftsätta samma testade artefakt till flera miljöer och gör det enklare att försöka igen med en misslyckad driftsättning utan att bygga om.

För den fullständiga referensen om driftsättning till Azure App Service med GitHub Actions, se den officiella Microsoft-dokumentationen.