GitHub Actions su Azure

GitHub Actions è la piattaforma integrata di GitHub per CI/CD e automazione. I workflow sono definiti in file YAML archiviati nella directory .github/workflows/ del repository e vengono attivati dagli eventi di GitHub: push, pull request, release e altri ancora. GitHub Actions è profondamente integrato nell'ecosistema GitHub (issues, PR, pacchetti e analisi della sicurezza) e offre un ricco marketplace di azioni della community per attività come compilazione, test e distribuzione in Azure.

Un file di workflow di GitHub Actions contiene tre sezioni di primo livello. on definisce gli eventi di attivazione. env imposta le variabili di ambiente globali. jobs definisce uno o più processi, ciascuno eseguito su un runner (gestito da GitHub o self-hosted). Ogni processo contiene degli steps: run (script della shell) oppure uses (un'azione predefinita). Per impostazione predefinita, i processi vengono eseguiti in parallelo; utilizzi needs per creare dipendenze sequenziali.

Il metodo consigliato per autenticare GitHub Actions ad Azure è OpenID Connect (OIDC): emette token a breve durata senza archiviare segreti a lunga durata in GitHub. Configuri una credenziale di identità federata in una registrazione dell'app Azure o in un'identità gestita, accordandole attendibilità per il repository e il branch GitHub. Utilizzi l'azione azure/login@v2 per scambiare il token OIDC di GitHub con un token di accesso Azure: non sono necessari segreti client in GitHub Secrets.

L'azione azure/webapps-deploy@v3 distribuisce codice o un'immagine di container in Azure App Service. Gestisce la distribuzione negli slot, la distribuzione basata su pacchetto e la distribuzione di immagini Docker. La abbini a azure/login@v2 per l'autenticazione. Può scegliere come destinazione uno slot di staging, eseguire smoke test e poi effettuare lo scambio con l'azione azure/CLI@v2 che esegue il comando di scambio degli slot, replicando interamente in GitHub Actions il modello di distribuzione blue-green di Azure Pipelines.

Distribuisca in AKS da GitHub Actions utilizzando l'azione azure/k8s-deploy@v5. Questa azione usa kubectl apply per distribuire i manifest, esegue la sostituzione dell'immagine (sostituendo il tag dell'immagine con quello della build corrente) e monitora lo stato del rollout. L'azione azure/aks-set-context@v4 configura le credenziali di kubectl recuperando il kubeconfig del cluster tramite la sessione Azure autenticata.

Archivi i valori sensibili in GitHub Secrets: valori crittografati accessibili nei workflow come ${{ secrets.SECRET_NAME }}. Inserisca la configurazione non sensibile in GitHub Variables, accessibile come ${{ vars.VARIABLE_NAME }}. Entrambi possono essere associati a un repository, un ambiente o un'organizzazione. Utilizzi gli environments in GitHub Actions per aggiungere regole di protezione (revisori obbligatori, branch di distribuzione) simili agli Environments di Azure DevOps.

Gli Environments di GitHub Actions (configurati in Impostazioni del repository → Environments) aggiungono gate di distribuzione simili agli ambienti di Azure DevOps. Può richiedere revisori obbligatori, che devono approvare l'esecuzione di un processo destinato all'ambiente, limitare le distribuzioni a branch specifici (solo main può distribuire in Production) e aggiungere timer di attesa per ritardare le distribuzioni. I processi destinati a un ambiente protetto vengono sospesi finché non sono soddisfatte tutte le regole di protezione.

Eviti di duplicare la logica CI/CD tra i repository utilizzando due funzionalità di GitHub Actions. I workflow riutilizzabili consentono di definire un workflow in un repository e richiamarlo dai workflow di altri repository tramite uses: myorg/shared-workflows/.github/workflows/deploy.yml@main. Le azioni composite raggruppano più passaggi in un'unica azione archiviata in un repository, riutilizzabile con uses: myorg/my-actions/deploy@v1. Entrambe promuovono i principi DRY nelle pipeline CI/CD della Sua organizzazione.

Scelga GitHub Actions quando: il codice è ospitato su GitHub, il team preferisce l'interfaccia di GitHub, desidera una stretta integrazione con i controlli delle PR e l'analisi del codice di GitHub oppure sta sviluppando progetti open source (con un generoso numero di minuti gratuiti). Scelga Azure Pipelines quando: ha bisogno dell'integrazione con Azure Boards, di test avanzati con Azure Test Plans, della gestione dei feed di Azure Artifacts, quando il codice si trova in Azure Repos oppure quando necessita di una gestione complessa dei rilasci multi-stage con gate distribuiti su molti ambienti. Entrambe le soluzioni supportano allo stesso modo le distribuzioni in Azure.

Il GitHub Actions Marketplace ospita migliaia di azioni della community e ufficiali per le attività più comuni. Microsoft pubblica azioni Azure ufficiali: azure/login, azure/webapps-deploy, azure/aks-set-context, azure/k8s-deploy, azure/CLI, azure/arm-deploy e molte altre. Blocchi sempre le azioni a uno specifico tag di versione (ad esempio @v3) o a uno SHA di commit, per prevenire attacchi alla supply chain dovuti all'aggiornamento di un'azione compromessa con codice dannoso.

I runner gestiti da GitHub hanno accesso solo a Internet pubblico: non possono raggiungere risorse Azure private (database SQL, API interne) senza esporre pubblicamente tali risorse. Utilizzi runner self-hosted su VM Azure all'interno della Sua VNet per le distribuzioni verso risorse private. Registri un runner scaricando l'agente runner di GitHub Actions, configurandolo con l'URL del repository e il token di registrazione e avviandolo come servizio. Ridimensioni i runner self-hosted con Azure Container Apps per ottenere pool di runner elastici.

Verifichi la Sua comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) trattati in questa lezione.

In questa lezione ha imparato che i workflow di GitHub Actions sono file YAML in .github/workflows/, attivati dagli eventi di GitHub ed eseguiti sui runner; le credenziali federate OIDC consentono l'autenticazione ad Azure da GitHub Actions senza segreti; gli Environments di GitHub con regole di protezione aggiungono gate di approvazione alle distribuzioni in produzione. Con questo si conclude il corso su Azure DevOps; ora passeremo ad Azure Monitor e Log Analytics.