Comprendre les déploiements de bout en bout

Effectué

Les pipelines sont des outils flexibles que vous pouvez configurer de nombreuses façons différentes, en fonction de vos besoins. Dans cette unité, vous allez apprendre à utiliser des pipelines pour déployer une solution complète, y compris la configuration de l’infrastructure Azure, et pour effectuer d’autres opérations de déploiement.

Combien de pipelines ?

Dans certaines organisations, l’équipe qui gère l’environnement Azure est différente de celle qui développe le code qui s’exécute dans l’environnement. Dans une telle situation, il est souvent tentant de créer plusieurs pipelines, chacun appartenant à l’équipe responsable de son domaine particulier. Par exemple, vous pouvez créer un pipeline pour déployer le code Bicep qui déploie les ressources Azure de votre site web, et un autre pipeline pour déployer l’application de site web.

Cette approche vous offre une certaine flexibilité dans la façon de gérer les pipelines, mais il peut être difficile de conserver la synchronisation de tous les éléments. Supposons, par exemple, que votre équipe de site web a besoin d’un nouveau paramètre sur son application Azure App Service pour activer une fonctionnalité qu’elle crée. Le pipeline de déploiement d’application ne peut pas s’exécuter tant que le pipeline de déploiement d’infrastructure n’a pas abouti. En outre, il peut devenir difficile d’envoyer des données, telles que les noms des ressources Azure créées par votre pipeline d’infrastructure, entre les pipelines.

Au lieu de cela, il est souvent préférable de créer un pipeline unique qui déploie tous les éléments requis pour votre solution, même si différentes personnes ou différentes équipes gèrent les composants. Vous pouvez utiliser des outils tels que Git et Azure DevOps pour coordonner votre travail. Quand une nouvelle fonctionnalité est ajoutée, vous pouvez utiliser une branche pour apporter les modifications nécessaires à votre fichier Bicep. Puis, quand la modification est prête à être intégrée et publiée, un pipeline individuel effectue toutes les étapes nécessaires à la génération et au déploiement de la solution. Un pipeline unique réduit le risque de désynchronisation.

Conseil

Quand vous créez du code pour votre solution, vous devez probablement le déployer fréquemment pour tester son fonctionnement. Vous pouvez constater que le déploiement de votre infrastructure avec votre code d’application ralentit l’exécution de votre pipeline et empêche votre progression.

Si vous êtes dans cette position, vous pouvez envisager de désactiver le déploiement de l’infrastructure pour votre environnement de développement. Vous pouvez utiliser des filtres de chemin, des modèles de pipeline et des conditions pour y parvenir. Toutefois, vous devez laisser intacte la séquence de déploiement complète pour vos autres environnements.

Plan de contrôle et plan de données

De nombreuses ressources Azure fournissent deux plans différents pour l’accès. Le plan de contrôle déploie et configure la ressource. Le plan de données vous permet d’accéder aux fonctionnalités de la ressource.

Lorsque vous créez et déployez des fichiers Bicep, vous interagissez avec le plan de contrôle. Dans Azure, le plan de contrôle est Azure Resource Manager. Vous utilisez Resource Manager pour définir la configuration de chacune de vos ressources.

Toutefois, votre pipeline doit souvent faire plus que simplement interagir avec le plan de contrôle. Par exemple, vous devrez peut-être effectuer d’autres tâches :

• Charger un objet blob dans un compte de stockage.
• Modifier un schéma de base de données.
• Effectuer un appel d’API vers un service tiers.
• Déclencher la mise à jour d’un modèle Machine Learning.
• Déployer un site web dans une application Azure App Service.
• Déployer des logiciels sur une machine virtuelle.
• Inscrivez une entrée DNS (Domain Name Server) auprès d’un fournisseur tiers.

Quand vous considérez un pipeline de bout en bout, vous devez généralement déployer vos ressources Azure, puis effectuer une série d’opérations par rapport aux plans de données de ces ressources. Parfois, ces opérations sont appelées le dernier kilomètre du déploiement, car vous effectuez la majeure partie du déploiement à l’aide du plan de contrôle, et seule une petite quantité de configuration est conservée.

Notes

Certaines ressources n’ont pas de division claire entre leur plan de contrôle et leur plan de données. C’est le cas notamment d’Azure Data Factory et de la gestion des API Azure. Ces deux services prennent en charge les déploiements entièrement automatisés à l’aide de Bicep, mais ils requièrent des considérations spéciales. Vous trouverez des liens vers des informations supplémentaires dans la page Résumé, à la fin du module.

Comment effectuer des opérations de plan de données

Quand vous créez un pipeline de déploiement qui interagit avec le plan de données de vos ressources, vous pouvez utiliser l’une des trois approches courantes :

• Scripts de déploiement Resource Manager.
• Scripts de pipeline.
• Tâches de pipeline.

Les scripts de déploiement Resource Manager sont définis dans votre fichier Bicep. Ils exécutent des scripts Bash ou PowerShell et peuvent interagir avec les applets de commande Azure PowerShell ou Azure CLI. Vous créez une identité managée pour que le script de déploiement puisse s’authentifier auprès d’Azure, et Azure provisionne et gère automatiquement les autres ressources dont il a besoin pour exécuter le script de déploiement.

Les scripts de déploiement sont utiles quand vous devez exécuter un script de base dans votre processus de déploiement. Toutefois, ils ne vous fournissent pas facilement un accès à d’autres éléments de votre pipeline.

Vous pouvez également exécuter votre propre logique au sein d’un pipeline de déploiement. Azure Pipelines fournit un écosystème complet de tâches pour les opérations courantes que vous devez effectuer. Si vous ne trouvez pas une tâche qui répond à vos besoins, vous pouvez utiliser un script pour exécuter votre propre code Bash ou PowerShell. Les scripts et les tâches de pipeline s’exécutent à partir de l’agent de votre pipeline. Vous devez souvent authentifier la tâche ou le script dans le plan de données du service que vous utilisez, et la façon dont vous vous authentifiez dépend du service.

Les scripts et les tâches de pipeline vous offrent flexibilité et contrôle. Ils vous permettent également d’accéder aux artefacts de pipeline, que vous allez bientôt découvrir. Dans ce module, nous nous concentrons sur les scripts et les tâches de pipeline. Pour plus d’informations sur les scripts de déploiement Resource Manager, consultez la page Résumé à la fin du module.

Sorties

Un pipeline crée et configure habituellement vos ressources Azure en déployant un fichier Bicep. Les parties suivantes du pipeline interagissent ensuite avec le plan de données de ces ressources. Pour pouvoir interagir avec les ressources, les tâches et les étapes du pipeline ont besoin d’informations sur la ressource Azure que vous avez créée.

Supposons, par exemple, que vous disposiez d’un fichier Bicep qui déploie un compte de stockage. Vous souhaitez que votre pipeline déploie le compte de stockage, puis charge des objets blob dans un conteneur d’objets blob, dans le compte de stockage. La tâche de pipeline qui télécharge les objets blob doit connaître le nom du compte de stockage auquel se connecter et le nom du conteneur d’objets blob vers lequel charger le fichier.

Il est conseillé de laisser le fichier Bicep déterminer les noms de vos ressources Azure. Il peut utiliser des paramètres, des variables ou des expressions pour créer les noms pour le compte de stockage et le conteneur d’objets blob. Le fichier Bicep peut ensuite exposer une sortie qui fournit le nom de chaque ressource. Les étapes ultérieures du pipeline peuvent lire la valeur de la sortie. De cette façon, votre définition de pipeline n’a pas besoin de coder en dur des noms ou d’autres informations susceptibles de changer d’un environnement à l’autre. En outre, la définition n’a pas besoin d’être basée sur des règles définies dans votre fichier Bicep.

Avec Azure Pipelines, vous pouvez propager les valeurs des sorties à l’aide de variables de pipeline. Vous pouvez définir la valeur d’une variable de pipeline dans un script de pipeline. Vous utilisez une sortie de journal dans un format spécial qu’Azure Pipelines sait interpréter, comme illustré ici :

stages:
- stage: Stage1
  jobs:
  - job: Job1
    steps:
      # Set the variable's value.
      - script: |
          echo "##vso[task.setvariable variable=myVariableName;isOutput=true]VariableValue"
        name: Step1

      # Read the variable's value.
      - script:
          echo $(myVariableName)

Lorsque vous créez une variable dans un travail, mais que vous souhaitez y accéder dans un autre travail à la même étape, vous devez la mapper.

stages:
- stage: Stage2
  jobs:
  - job: Job2
    steps:
      # Set the variable's value.
      - script: |
          echo "##vso[task.setvariable variable=myVariableName;isOutput=true]VariableValue"
        name: Step1

  - job: Job3
    dependsOn: Job2
    variables: # Map the variable to this job.
      myVariableName: $[ dependencies.Job2.outputs['Step1.myVariableName'] ]
    steps:
      # Read the variable's value.
      - script: |
          echo $(myVariableName)

Pour accéder à une variable entre les phases de pipeline, vous devez également la mapper, mais vous utilisez une syntaxe différente :

stages:
- stage: Stage2
  jobs:
  - job: Job2
    steps:
      # Set the variable's value.
      - script: |
          echo "##vso[task.setvariable variable=myVariableName;isOutput=true]VariableValue"
        name: Step1

  - job: Job3
    dependsOn: Job2
    variables: # Map the variable to this job.
      myVariableName: $[ dependencies.Job2.outputs['Step1.myVariableName'] ]
    steps:
      # Read the variable's value.
      - script: |
          echo $(myVariableName)

- stage: Stage3
  dependsOn: Stage2
  jobs:
  - job: Job4
    variables: # Map the variable to this stage.
      myVariableName: $[ stageDependencies.Stage2.Job2.outputs['Step1.myVariableName'] ]
    steps:
      # Read the variable's value.
    - script: |
        echo $(myVariableName)

En utilisant les sorties Bicep et les variables de pipeline, vous pouvez créer un pipeline multiphase qui déploie votre code Bicep, puis effectue diverses actions sur les ressources dans le cadre de votre déploiement.