Comprendre les déploiements de bout en bout
Les workflows GitHub Actions 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 workflows 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 workflows ?
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 workflows, chacun appartenant à l’équipe responsable de son domaine particulier. Par exemple, vous pouvez créer un workflow pour déployer le code Bicep qui déploie les ressources Azure de votre site web, et un autre workflow pour déployer l’application de site web.
Cette approche vous offre une certaine flexibilité dans la façon de gérer les workflows, 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 workflow de déploiement d’application ne peut pas s’exécuter tant que le workflow 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 workflow d’infrastructure, entre les workflows.
Au lieu de cela, il est souvent préférable de créer un flux de travail unique qui déploie tous les éléments requis pour votre solution, même si différentes équipes ou différentes personnes gèrent les composants. Vous pouvez utiliser des outils tels que Git et GitHub 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. Lorsque la modification est prête à être intégrée et publiée, un flux de travail individuel effectue toutes les étapes nécessaires à la génération et au déploiement de la solution, ce qui 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 workflow 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 d’accès, des workflows réutilisables 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 flux de travail doit souvent faire plus que simplement interagir avec le plan de contrôle. Par exemple, vous pourriez avoir besoin de :
- 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éclenchez une mise à jour de modèle Machine Learning.
- Déployer un site web dans une application Azure App Service.
- Déployer des logiciels sur une machine virtuelle.
- Inscrire une entrée DNS auprès d’un fournisseur tiers.
Quand vous considérez un flux de travail 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 workflow 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 workflow
- Actions de workflow
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 commandes Azure CLI et les applets de commande Azure PowerShell. Vous créez une identité managée pour le script de déploiement à utiliser pour vous 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 fonctionnent quand vous devez exécuter un script de base au sein de votre processus de déploiement, mais ils ne vous fournissent pas facilement l’accès à d’autres éléments à partir de votre flux de travail.
Vous pouvez également exécuter votre propre logique au sein d’un workflow de déploiement. GitHub Actions offre un vaste écosystème d’actions pour les opérations courantes que vous devez effectuer. Si vous ne trouvez pas une action qui répond à vos besoins, vous pouvez utiliser un script pour exécuter votre propre code Bash ou PowerShell. Les scripts et actions de workflow s’exécutent à partir de l’exécuteur de votre workflow. Vous devez souvent authentifier l’action ou le script dans le plan de données du service que vous utilisez, et la façon dont vous effectuez cette opération dépend du service.
Les scripts et les actions de workflow vous offrent flexibilité et contrôle. Ils vous permettent également d’accéder aux artefacts de flux de travail, que vous allez bientôt découvrir. Dans ce module, nous nous concentrons sur les actions de workflow. Pour plus d’informations sur les scripts de déploiement Resource Manager, consultez la page Résumé à la fin du module.
Sorties
Un workflow crée et configure habituellement vos ressources Azure en déployant un fichier Bicep. Les parties suivantes du flux de travail interagissent ensuite avec le plan de données de ces ressources. Pour pouvoir interagir avec les ressources, les actions et les étapes du workflow ont besoin d’informations sur la ressource Azure qui a été créée.
Supposons, par exemple, que vous disposiez d’un fichier Bicep qui déploie un compte de stockage. Vous souhaitez que votre workflow déploie le compte de stockage, puis charge des objets blob dans un conteneur d’objets blob, dans le compte de stockage. L’étape de workflow 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 flux de travail peuvent lire la valeur de sortie. De cette façon, votre définition de workflow n’a pas besoin de coder en dur des noms ou d’autres informations susceptibles de changer d’un environnement à l’autre, ni d’être basée sur des règles définies dans votre fichier Bicep.
Avec GitHub Actions, vous pouvez propager les valeurs des sorties à l’aide des variables de workflow. L’action azure/arm-deploy crée automatiquement des variables pour chacune de vos sorties de déploiement Bicep. Vous pouvez également créer manuellement des variables de workflow dans des scripts. Vous trouverez des liens vers des informations supplémentaires dans la page Résumé, à la fin de ce module.
Lorsque vous accédez à des variables qui ont été créées dans un autre travail, vous devez publier la variable pour la rendre accessible au travail qui la lit. Supposons, par exemple, que vous créez un travail qui déploie un fichier Bicep et que vous deviez propager la sortie appServiceAppName vers votre workflow. Vous utilisez le mot clé outputs pour spécifier que la variable de workflow appServiceAppName doit être définie sur la valeur de la variable de sortie appServiceAppName créée par l’étape deploy :
job1:
runs-on: ubuntu-latest
outputs:
appServiceAppName: ${{ steps.deploy.outputs.appServiceAppName }}
steps:
- uses: actions/checkout@v3
- uses: azure/login@v1
name: Sign in to Azure
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- uses: azure/arm-deploy@v1
id: deploy
name: Deploy Bicep file
with:
failOnStdErr: false
deploymentName: ${{ github.run_number }}
resourceGroupName: Playground1
template: ./deploy/main.bicep
Ensuite, dans un travail ultérieur, vous créez une dépendance explicite sur le travail qui a créé la variable en incluant le mot clé needs, et vous faites référence à la variable à l’aide du nom de la variable publiée :
job2:
needs: job1
runs-on: ubuntu-latest
steps:
- run: |
echo "${{needs.job1.outputs.appServiceAppName}}"
En utilisant les sorties Bicep et les variables de workflow, vous pouvez créer un workflow qui déploie votre code Bicep, puis effectue diverses actions sur les ressources dans le cadre de votre déploiement.