Partager via

Déployer sur l’infrastructure Azure avec GitHub Actions

Dans ce guide, nous allons aborder la façon d’utiliser CI/CD et Infrastructure as 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 é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 de l’iaC et de l’automatisation pour les déploiements

Il existe de nombreuses façons de déployer sur Azure, notamment le portail Azure, l’interface CLI, l’API, etc. Pour ce guide, nous allons utiliser l’automatisation IAC et CI/CD. Les avantages de cette approche sont les suivants :

  • Déclaratif : lorsque vous définissez votre processus d’infrastructure et de déploiement dans le code, il peut être versionné et examiné à l’aide du 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 à vous soucier de tous les détails de l’implémentation.

Vous trouverez des informations supplémentaires sous une infrastructure reproductible dans le Centre d’architecture Azure ou sur l’infrastructure en tant que code dans le Centre de ressources DevOps.

Architecture

Vue d’ensemble de l’architecture de l’utilisation de CI/CD pour déployer Azure

Dataflow

  1. Créez une branche et vérifiez les modifications de code IaC nécessaires.
  2. Créez une Pull Request dans GitHub une fois que vous êtes prêt à fusionner vos modifications dans votre environnement.
  3. Un flux de travail GitHub Actions se déclenche pour vous assurer que votre code est bien mis en forme, cohérent en interne et produit une infrastructure sécurisée. En outre, une analyse 'what-if' Terraform ou Bicep sera exécutée pour générer un aperçu des modifications qui se produiront dans votre environnement Azure.
  4. Une fois l'examen effectué correctement, la demande de modification peut être fusionnée dans votre branche principale.
  5. Un autre flux de travail GitHub Actions se déclenche à partir de la branche principale et exécute 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.

Prerequisites

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 l’environnement production, configurez une règle de protection et ajoutez tous les approbateurs nécessaires 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 dispose des autorisations de déploiement dans votre abonnement Azure. Créez une application unique et accordez-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é à l’aide d’OpenID Connect (OIDC). Consultez la documentation Azure pour obtenir des instructions détaillées. Trois informations d’identification fédérées doivent être ajoutées :

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

  3. Ajouter des secrets GitHub

    Note

    Même si aucune des données relatives aux identités Azure ne contient de secrets ou d’informations d’identification, nous utilisons toujours des secrets GitHub comme moyen pratique de paramétrer les informations d’identité par environnement.

    Créez les secrets suivants sur le référentiel à l’aide de l’identité Azure :

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

    Vous trouverez ici des instructions pour ajouter les secrets au référentiel.

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 doit être conservé entre différentes exécutions du flux de travail. L’approche recommandée consiste à stocker ce fichier dans un compte de stockage Azure ou un autre serveur principal distant similaire. Normalement, ce stockage est approvisionné manuellement ou via un flux de travail distinct. 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. Dans l’environnement production, configurez une règle de protection et ajoutez tous les approbateurs requis qui doivent valider les déploiements en 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 dispose des autorisations de déploiement dans votre abonnement Azure. Créez une application distincte pour un read-only compte et read/write attribuez-lui les autorisations appropriées dans votre abonnement Azure. En outre, les deux rôles auront également besoin d'au moins Reader and Data Access permissions 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 l’identité read/write , créez une information d’identification fédérée comme suit :

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

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

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

  4. Ajouter des secrets GitHub

    Note

    Même si aucune des données relatives aux identités Azure ne contient de secrets ou d’informations d’identification, nous utilisons toujours des secrets GitHub comme moyen pratique de paramétrer les informations d’identité par environnement.

    Créez les secrets suivants sur le référentiel à l’aide de l’identité read-only :

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

    Vous trouverez ici des instructions pour ajouter les secrets au référentiel.

    Créez un autre secret sur l’environnement production en utilisant l’identité read-write.

    • AZURE_CLIENT_ID : ID d’application (client) de l’inscription de l’application dans Azure

    Vous trouverez ici des instructions pour ajouter les secrets à l’environnement. Le secret d’environnement remplace le secret du dépôt lors de l’exécution 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 de 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 bicep build pour compiler le bicep en un modèle ARM. Cela garantit qu’il n’existe aucune erreur de mise en forme. Ensuite, il effectue une validation pour vous 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 référentiel utilise GitHub Advanced Security (GHAS), les résultats sont chargés sur GitHub.

  2. Bicep What-If / Déploiement

    Ce flux de travail s’exécute à chaque pull request et à 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 le what-if. Ce rapport est ensuite joint à la PR pour faciliter l'examen. 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 (push) vers la branche principale. Cette étape déploiera le modèle sur Azure après l’approbation 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 formaté et suit les meilleures pratiques de Terraform. Ensuite, il effectue terraform validate pour vérifier que le code est correct sur le plan syntaxique 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 référentiel utilise GitHub Advanced Security (GHAS), les résultats sont chargés sur GitHub.

  2. Plan Terraform / Appliquer

    Ce flux de travail s’exécute à chaque pull request et à 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 terraform plan. Ce rapport est ensuite joint à la PR pour faciliter l'examen. L’étape d’application s’exécute après le plan lorsque le flux de travail est déclenché par un envoi (push) vers la branche principale. Cette étape prendra le document de plan et appliquera les modifications après l'approbation d'une révision manuelle, 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 déclenché pour alerter les mainteneurs du projet.

  • Last updated on