GitHub Actions i Azure

GitHub Actions är GitHubs inbyggda plattform för CI/CD och automatisering. Arbetsflöden definieras i YAML-filer som lagras i katalogen .github/workflows/ i Ert repositorium och utlöses av GitHub-händelser — pushar, pull requests, releaser med mera. GitHub Actions är djupt integrerat med GitHub-ekosystemet (ärenden, PR:er, paket och säkerhetsskanning) och erbjuder en omfattande marknadsplats med åtgärder från communityn för uppgifter som att bygga, testa och distribuera till Azure.

En arbetsflödesfil för GitHub Actions har tre avsnitt på toppnivå. on definierar utlösande händelser. env anger globala miljövariabler. jobs definierar ett eller flera jobb, där varje jobb körs på en runner (GitHub-hanterad eller självhostad). Varje jobb har steps — antingen run (skalskript) eller uses (en förbyggd åtgärd). Jobb körs parallellt som standard; använd needs för att skapa sekventiella beroenden.

Det rekommenderade sättet att autentisera GitHub Actions mot Azure är OpenID Connect (OIDC) — det utfärdar kortlivade token utan att långlivade hemligheter behöver lagras i GitHub. Konfigurera en federerad identitetsautentiseringsuppgift på en Azure App Registration eller Managed Identity och ge den förtroende för Ert GitHub-repositorium och Er gren. Använd åtgärden azure/login@v2 för att byta GitHubs OIDC-token mot en Azure-åtkomsttoken — inga klienthemligheter behöver lagras i GitHub Secrets.

Åtgärden azure/webapps-deploy@v3 distribuerar kod eller en containeravbildning till Azure App Service. Den hanterar slotdistribution, paketbaserad distribution och distribution av Docker-avbildningar. Kombinera den med azure/login@v2 för autentisering. Ni kan rikta distributionen mot en staging-slot, köra smoketester och sedan växla slotten med åtgärden azure/CLI@v2, som kör kommandot för slotväxling — på så sätt återskapas Azure Pipelines blågröna distributionsmönster helt i GitHub Actions.

Distribuera till AKS från GitHub Actions med åtgärden azure/k8s-deploy@v5. Den använder kubectl apply för att distribuera manifest, utför bildsubstitution (ersätter bildtaggen med taggen för den aktuella builden) och övervakar utrullningens hälsa. Åtgärden azure/aks-set-context@v4 konfigurerar kubectl-autentiseringsuppgifter genom att hämta klustrets kubeconfig med hjälp av den autentiserade Azure-sessionen.

Lagra känsliga värden i GitHub Secrets — krypterade värden som är tillgängliga som ${{ secrets.SECRET_NAME }} i arbetsflöden. Icke-känslig konfiguration lägger Ni i GitHub Variables — tillgänglig som ${{ vars.VARIABLE_NAME }}. Båda kan begränsas till ett repositorium, en miljö eller en organisation. Använd environments i GitHub Actions för att lägga till skyddsregler (obligatoriska granskare och distributionsgrenar) på liknande sätt som Azure DevOps Environments.

GitHub Actions Environments (konfigureras under Settings → Environments i repositoriet) lägger till distributionsgrindar som liknar miljöerna i Azure DevOps. Ni kan kräva obligatoriska granskare som måste godkänna innan ett jobb som riktar sig mot miljön körs, begränsa distributioner till specifika grenar (endast main får distribuera till Production) och lägga till väntetimer för att fördröja distributioner. Jobb som riktar sig mot en skyddad miljö pausas tills alla skyddsregler är uppfyllda.

Undvik att duplicera CI/CD-logik mellan repositorier genom att använda två funktioner i GitHub Actions. Med återanvändbara arbetsflöden kan Ni definiera ett arbetsflöde i ett repositorium och anropa det från arbetsflöden i andra repositorier med uses: myorg/shared-workflows/.github/workflows/deploy.yml@main. Sammansatta åtgärder samlar flera steg i en enda åtgärd som lagras i ett repositorium och kan återanvändas med uses: myorg/my-actions/deploy@v1. Båda främjar DRY-principen i organisationens CI/CD-pipelines.

Välj GitHub Actions när koden finns på GitHub, teamet föredrar GitHub-gränssnittet, Ni vill ha tät integration med GitHubs PR-kontroller och kodskanning eller bygger projekt med öppen källkod (generöst antal kostnadsfria minuter). Välj Azure Pipelines när Ni behöver integration med Azure Boards, avancerad testning med Azure Test Plans, hantering av Azure Artifacts-feeds, när koden finns i Azure Repos eller när Ni behöver komplex releasehantering i flera steg med grindar över många miljöer. Båda stöder distribution till Azure lika väl.

GitHub Actions Marketplace innehåller tusentals åtgärder från communityn och officiella åtgärder för vanliga uppgifter. Microsoft publicerar officiella Azure-åtgärder: azure/login, azure/webapps-deploy, azure/aks-set-context, azure/k8s-deploy, azure/CLI, azure/arm-deploy och många fler. Lås alltid åtgärder till en specifik versionstagg (till exempel @v3) eller ett commit-SHA för att förhindra attacker mot leveranskedjan där en komprometterad åtgärd uppdateras med skadlig kod.

GitHub-hanterade runners har endast åtkomst till det offentliga internet — de kan inte nå privata Azure-resurser (SQL-databaser och interna API:er) utan att dessa resurser exponeras offentligt. Använd självhostade runners på virtuella Azure-datorer i Ert VNet för distributioner till privata resurser. Registrera en runner genom att hämta GitHub Actions-runneragenten, konfigurera den med URL:en till Ert repositorium och en registreringstoken och köra den som en tjänst. Skala självhostade runners med Azure Container Apps för elastiska runner-pooler.

I den här lektionen lärde Ni Er att arbetsflöden i GitHub Actions är YAML-filer i .github/workflows/ som utlöses av GitHub-händelser och körs på runners, att federerade OIDC-autentiseringsuppgifter möjliggör hemlighetslös Azure-autentisering från GitHub Actions och att GitHub Environments med skyddsregler lägger till godkännandegrindar för produktionsdistributioner. Därmed är kursen i Azure DevOps slutförd — nästa avsnitt handlar om Azure Monitor och Log Analytics.