GitHub Actions sur Azure

GitHub Actions est la plateforme intégrée de CI/CD et d’automatisation de GitHub. Les flux de travail sont définis dans des fichiers YAML stockés dans le répertoire .github/workflows/ de votre dépôt et déclenchés par des événements GitHub : envois, demandes d’extraction, mises à jour de version, etc. GitHub Actions est étroitement intégré à l’écosystème GitHub (problèmes, demandes d’extraction, packages, analyse de sécurité) et fournit une vaste marketplace d’Actions communautaires pour des tâches telles que la compilation, les tests et le déploiement sur Azure.

Un fichier de flux de travail GitHub Actions comporte trois sections de premier niveau. on définit les événements déclencheurs. env définit les variables d’environnement globales. jobs définit une ou plusieurs tâches, chacune s’exécutant sur un runner (hébergé par GitHub ou auto-hébergé). Chaque tâche comporte des étapes : soit run (script shell), soit uses (une Action prédéfinie). Les tâches s’exécutent en parallèle par défaut ; utilisez needs pour créer des dépendances séquentielles.

La méthode recommandée pour authentifier GitHub Actions auprès d’Azure est OpenID Connect (OIDC) : elle émet des jetons de courte durée sans stocker de secrets de longue durée dans GitHub. Configurez un justificatif d’identité fédérée sur une inscription d’application Azure ou une identité managée, en lui accordant une relation de confiance avec votre dépôt et votre branche GitHub. Utilisez l’Action azure/login@v2 pour échanger le jeton OIDC GitHub contre un jeton d’accès Azure ; aucun secret client dans GitHub Secrets n’est nécessaire.

L’Action azure/webapps-deploy@v3 déploie du code ou une image de conteneur sur Azure App Service. Elle gère le déploiement sur un emplacement, le déploiement basé sur un package et le déploiement d’une image Docker. Associez-la à azure/login@v2 pour l’authentification. Vous pouvez cibler un emplacement de préproduction, exécuter des tests de fumée, puis l’échanger avec l’Action azure/CLI@v2 qui exécute la commande d’échange d’emplacements, reproduisant entièrement le modèle de déploiement bleu-vert d’Azure Pipelines dans GitHub Actions.

Déployez sur AKS depuis GitHub Actions à l’aide de l’Action azure/k8s-deploy@v5. Cette Action utilise kubectl apply pour déployer les manifestes, effectue une substitution d’image (en remplaçant la balise de l’image par celle de la Build actuelle) et surveille l’état du déploiement. L’Action azure/aks-set-context@v4 configure les identifiants kubectl en récupérant la configuration kubeconfig du cluster à l’aide de la session Azure authentifiée.

Stockez les valeurs sensibles dans GitHub Secrets : ces valeurs chiffrées sont accessibles sous la forme ${{ secrets.SECRET_NAME }} dans les flux de travail. Placez la configuration non sensible dans GitHub Variables : elle est accessible sous la forme ${{ vars.VARIABLE_NAME }}. Les deux peuvent être limités à un dépôt, un environnement ou une organisation. Utilisez les environnements dans GitHub Actions pour ajouter des règles de protection (réviseurs requis, branches de déploiement), comme avec les Environments d’Azure DevOps.

Les Environments de GitHub Actions (configurés dans Paramètres du dépôt → Environments) ajoutent des contrôles de déploiement similaires à ceux des environnements Azure DevOps. Vous pouvez exiger des réviseurs requis qui doivent approuver l’exécution d’une tâche ciblant l’environnement, limiter les déploiements à des branches précises (seule main peut déployer sur Production) et ajouter des minuteries d’attente pour retarder les déploiements. Les tâches ciblant un environnement protégé sont suspendues jusqu’à ce que toutes les règles de protection soient respectées.

Évitez de dupliquer la logique de CI/CD entre les dépôts grâce à deux fonctionnalités de GitHub Actions. Les flux de travail réutilisables vous permettent de définir un flux de travail dans un dépôt et de l’appeler depuis les flux de travail d’autres dépôts à l’aide de uses: myorg/shared-workflows/.github/workflows/deploy.yml@main. Les Actions composites regroupent plusieurs étapes en une seule Action stockée dans un dépôt et réutilisable avec uses: myorg/my-actions/deploy@v1. Toutes deux favorisent les principes DRY dans les pipelines de CI/CD de votre organisation.

Choisissez GitHub Actions lorsque votre code est hébergé sur GitHub, que votre équipe préfère l’interface GitHub, que vous souhaitez une intégration étroite avec les vérifications des demandes d’extraction et l’analyse du code GitHub, ou que vous développez des projets open source (avec un nombre généreux de minutes gratuites). Choisissez Azure Pipelines lorsque vous avez besoin d’une intégration avec Azure Boards, de tests avancés avec Azure Test Plans, de la gestion des flux Azure Artifacts, lorsque votre code se trouve dans Azure Repos ou lorsque vous avez besoin d’une gestion complexe des mises en production en plusieurs étapes avec des contrôles répartis sur de nombreux environnements. Les deux permettent de déployer sur Azure tout aussi efficacement.

La Marketplace GitHub Actions héberge des milliers d’Actions communautaires et officielles pour les tâches courantes. Microsoft publie des Actions Azure officielles : azure/login, azure/webapps-deploy, azure/aks-set-context, azure/k8s-deploy, azure/CLI, azure/arm-deploy et bien d’autres. Épinglez toujours les Actions à une balise de version précise (par exemple @v3) ou à un SHA de validation afin d’empêcher qu’une attaque de la chaîne d’approvisionnement ne permette de remplacer une Action compromise par du code malveillant.

Les runners hébergés par GitHub disposent uniquement d’un accès à Internet public : ils ne peuvent pas atteindre les ressources Azure privées (bases de données SQL, API internes) sans exposer ces ressources publiquement. Utilisez des runners auto-hébergés sur des VM Azure dans votre réseau virtuel pour les déploiements vers des ressources privées. Enregistrez un runner en téléchargeant l’agent runner de GitHub Actions, en le configurant avec l’URL de votre dépôt et le jeton d’inscription, puis en l’exécutant comme un service. Faites évoluer les runners auto-hébergés avec Azure Container Apps pour obtenir des pools de runners élastiques.

Testez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris que les flux de travail GitHub Actions sont des fichiers YAML situés dans .github/workflows/, déclenchés par des événements GitHub et exécutés sur des runners, que les identifiants fédérés OIDC permettent une authentification Azure sans secret depuis GitHub Actions et que les GitHub Environments avec des règles de protection ajoutent des contrôles d’approbation aux déploiements en production. Le cours Azure DevOps est maintenant terminé ; nous allons ensuite étudier Azure Monitor et Log Analytics.