Déployer sur l’infrastructure Azure avec GitHub Actions

  • Article

Dans ce guide, nous allons aborder la façon d’utiliser CI/CD et Infrastructure en tant que Code (IaC) pour déployer sur Azure avec GitHub Actions de manière automatisée et reproductible.

Cet article est une vue d’ensemble de l’architecture et présente une solution structurée pour la conception d’une application sur Azure qui est évolutive, sécurisée, résiliente et hautement disponible. Pour voir d’autres exemples concrets d’architectures cloud et d’idées de solution, parcourez les architectures Azure.

Avantages de l’utilisation d’IaC et de l’automatisation pour les déploiements

Il existe de nombreuses façons de déployer sur Azure, notamment le portail Azure, la CLI, l’API, et plus. Pour ce guide, nous allons utiliser l’automatisation IaC et CI/CD. Les avantages de cette approche comprennent :

  • Déclaratif : lorsque vous définissez votre processus d’infrastructure et de déploiement dans le code, il peut être versionné et examiné en utilisant le cycle de vie de développement logiciel standard. IaC permet également d’éviter toute dérive dans votre configuration.

  • Cohérence : le suivi d’un processus IaC garantit que l’ensemble de l’organisation suit une méthode standard et bien établie pour déployer l’infrastructure qui incorpore les meilleures pratiques et est renforcée pour répondre à vos besoins de sécurité. Toutes les améliorations apportées aux modèles centraux peuvent facilement être appliquées au sein de l’organisation.

  • Sécurité : les modèles gérés de manière centralisée peuvent être renforcés et approuvés par une équipe d’opérations cloud ou de sécurité pour répondre aux normes internes.

  • Libre-service : les équipes peuvent être autorisées à déployer leur propre infrastructure en utilisant des modèles gérés de manière centralisée.

  • Productivité améliorée : en utilisant des modèles standard, les équipes peuvent approvisionner rapidement de nouveaux environnements sans avoir à se soucier de tous les détails de mise en œuvre.

Vous trouverez des informations supplémentaires sous l'infrastructure reproductible dans le Centre d’architecture Azure ou Qu'est-ce que l'infrastructure en tant que code dans le Centre de ressources DevOps.

Architecture

Architecture overview of using CI/CD to deploy Azure

Flux de données

  1. Créer une branche et enregistrez les modifications de code IaC nécessaires.
  2. Créer une demande de tirage (PR) dans GitHub une fois que vous êtes prêt à fusionner vos modifications dans votre environnement.
  3. Un flux de travail GitHub Actions se déclenchera pour garantir que votre code est bien formaté, cohérent en interne et produit une infrastructure sécurisée. En outre, une analyse de simulation Terraform Plan ou Bicep s’exécutera pour générer un aperçu des modifications qui se produiront dans votre environnement Azure.
  4. Une fois examiné de façon appropriée, le PR peut être fusionnée dans votre branche principale.
  5. Un autre flux de travail GitHub Actions se déclenchera à partir de la branche principale et exécutera les modifications à l’aide de votre fournisseur IaC.
  6. (exclusif à Terraform) un flux de travail GitHub Action planifié régulièrement doit également s’exécuter pour rechercher une dérive de configuration dans votre environnement et créer un problème si des modifications sont détectées.

Prérequis

Utiliser Bicep

  1. Créer des environnements GitHub

    Les flux de travail utilisent des environnements et des secrets GitHub pour stocker les informations d’identité Azure et configurer un processus d’approbation pour les déploiements. Créez un environnement nommé production en suivant ces instructions. Sur production l’environnement, configurez une règle de protection et ajoutez tous les approbateurs requis dont vous avez besoin pour approuver les déploiements de production. Vous pouvez également limiter l’environnement à votre branche principale. Des instructions détaillées sont disponibles ici .

  2. Configurer l’identité Azure :

    Une application Azure Active Directory est requise qui est dotée des autorisations de déploiement dans votre abonnement Azure. Créez une application unique et donnez-lui les autorisations de lecture/écriture appropriées dans votre abonnement Azure. Ensuite, configurez les informations d’identification fédérées pour permettre à GitHub d’utiliser l’identité en utilisant OpenID Connect (OIDC). Consultez la documentation Azure pour obtenir des instructions détaillées. Trois informations d’identification fédérées devront être ajoutées :

    • Définissez le type d’entité sur Environment et utilisez le production nom de l’environnement.
    • Définissez le type d’entité sur Pull Request.
    • Définissez le type d’entité sur Branch et utilisez le main nom de la branche.

  3. Ajoutez GitHub secrets

    Remarque

    Bien qu'aucune des données sur les identités Azure ne contienne de secrets ou d’informations d’identification, nous utilisons toujours les secrets GitHub comme moyen pratique de paramétriser les informations d’identité par environnement.

    Créer les secrets suivants sur le dépôt en utilisant l’identité Azure :

    • AZURE_CLIENT_ID : >L'ID d'application (client) pour l’inscription de l'application dans Azure
    • AZURE_TENANT_ID : L'ID de locataire d'Azure Active Directory où l’inscription de l’application est définie.
    • AZURE_SUBSCRIPTION_ID : L'ID d’abonnement où l’inscription de l’application est définie.

    Vous trouverez des instructions pour ajouter les secrets au dépôt ici.

Utiliser Terraform

  1. Configurer l'emplacement de l’état Terraform

    Terraform utilise un fichier d’état pour stocker des informations sur l’état actuel de votre infrastructure managée et la configuration associée. Ce fichier devra être conservé entre les différentes exécutions du flux de travail. L’approche recommandée est de stocker ce fichier dans un compte de stockage Azure ou un autre back-end distant similaire. Normalement, ce stockage serait fourni manuellement ou via un flux de travail séparé. Le bloc back-end Terraform doit être mis à jour avec votre emplacement de stockage sélectionné (voir ici pour obtenir de la documentation).

  2. Créer un environnement GitHub

    Les flux de travail utilisent des environnements et des secrets GitHub pour stocker les informations d’identité Azure et configurer un processus d’approbation pour les déploiements. Créez un environnement nommé production en suivant ces instructions. Sur production l’environnement configurez une règle de protection et ajoutez tous les approbateurs requis qui doivent approuver les déploiements de production. Vous pouvez également limiter l’environnement à votre branche principale. Des instructions détaillées sont disponibles ici .

  3. Configurer l’identité Azure :

    Une application Azure Active Directory est requise qui est dotée des autorisations de déploiement dans votre abonnement Azure. Créez une application distincte pour un read-only et read/write des comptes et attribuez-lui les autorisations appropriées dans votre abonnement Azure. En outre, les deux rôles ont également besoin d’au moins Reader and Data Access des autorisations pour le compte de stockage où réside l’état Terraform de l’étape 1. Ensuite configurez les informations d’identification fédérées pour permettre à GitHub d’utiliser l’identité à l’aide d’OpenID Connect (OIDC). Consultez la documentation Azure pour obtenir des instructions détaillées.

    Pour read/write l’identité, créez une information d’identification fédérée comme suit :

    • Définissez Entity Type et Environment utilisez le nom de production l’environnement.

    Pour read-only l’identité, créez deux informations d’identification fédérées comme suit :

    • Affectez la valeur Entity Type à Pull Request.
    • Définissez Entity Type et Branch utilisez le nom main de la branche.

  4. Ajoutez GitHub secrets

    Remarque

    Bien qu'aucune des données sur les identités Azure ne contienne de secrets ou d’informations d’identification, nous utilisons toujours les secrets GitHub comme moyen pratique de paramétriser les informations d’identité par environnement.

    Créez les secrets suivants sur le dépôt à l’aide de read-only l’identité :

    • AZURE_CLIENT_ID : >L'ID d'application (client) pour l’inscription de l'application dans Azure
    • AZURE_TENANT_ID : L'ID de locataire d'Azure Active Directory où l’inscription de l’application est définie.
    • AZURE_SUBSCRIPTION_ID : L'ID d’abonnement où l’inscription de l’application est définie.

    Vous trouverez des instructions pour ajouter les secrets au dépôt ici.

    Créez un autre secret sur production l’environnement à l’aide de read-write l’identité :

    • AZURE_CLIENT_ID : >L'ID d'application (client) pour l’inscription de l'application dans Azure

    Vous trouverez des instructions pour ajouter les secrets à l’environnement ici. Le secret d’environnement remplace le secret du dépôt lors de l’étape de déploiement dans l’environnement production lorsque des autorisations de lecture/écriture élevées sont requises.

Déployer avec GitHub Actions

Utiliser Bicep

Il existe deux flux de travail principaux inclus dans l'architecture de référence :

  1. Tests unitaires Bicep

    Ce flux de travail s’exécute sur chaque validation et se compose d’un ensemble de tests unitaires sur le code d’infrastructure. Il exécute la build bicep pour compiler le bicep sur un modèle ARM. Cela garantit qu’il n’y a pas d’erreurs de formatage. Ensuite, il effectue une validation pour s'assurer que le modèle est déployable. Enfin, checkov, un outil d’analyse de code statique open source pour IaC, s’exécute pour détecter les problèmes de sécurité et de conformité. Si le dépôt utilise GitHub Advanced Security (GHAS), les résultats seront chargés sur GitHub.

  2. Simulation Bicep / Déploiement

    Ce flux de travail s’exécute sur chaque demande de tirage et sur chaque validation sur la branche principale. L’étape de simulation du flux de travail est utilisée pour comprendre l’impact des modifications IaC sur l’environnement Azure en exécutant une simulation. Ce rapport est ensuite attaché à la demande de tirage pour un examen facile. L’étape de déploiement s’exécute après l’analyse de simulation lorsque le flux de travail est déclenché par un envoi vers la branche principale. Cette étape déploie le modèle sur Azure après la signature d’une révision manuelle.

Utiliser Terraform

Il existe trois flux de travail principaux inclus dans l'architecture de référence:

  1. Tests unitaires Terraform

    Ce flux de travail s’exécute sur chaque validation et se compose d’un ensemble de tests unitaires sur le code d’infrastructure. Il exécute terraform fmt pour garantir que le code est correctement structuré et suit les meilleures pratiques terraform. Ensuite, il effectue la validation terraform pour vérifier que le code est syntaxiquement correct et cohérent en interne. Enfin, checkov, un outil d’analyse de code statique open source pour IaC, s’exécute pour détecter les problèmes de sécurité et de conformité. Si le dépôt utilise GitHub Advanced Security (GHAS), les résultats seront chargés sur GitHub.

  2. Planifier / Appliquer Terraform

    Ce flux de travail s’exécute sur chaque demande de tirage et sur chaque validation sur la branche principale. L’étape de planification du flux de travail est utilisée pour comprendre l’impact des modifications IaC sur l’environnement Azure en exécutant le plan terraform. Ce rapport est ensuite attaché à la demande de tirage pour un examen facile. L’étape d’application s’exécute après le plan lorsque le flux de travail est déclenché par un envoi vers la branche principale. Cette étape prend le document de plan et applique les modifications après qu’une révision manuelle a été approuvée s’il y a des modifications en attente dans l’environnement.

  3. Détection de dérive Terraform

    Ce flux de travail s’exécute régulièrement pour analyser votre environnement pour détecter toute dérive de configuration ou modification apportée en dehors de Terraform. Si une dérive est détectée, un problème GitHub est soulevé pour alerter les mainteneurs du projet.