Configurer des applications et des machines virtuelles

Effectué

Il est courant de générer des applications et d’autres codes personnalisés pour votre solution Azure. Les applications personnalisées peuvent inclure des sites web, des API et des applications en arrière-plan qui s’exécutent sans la moindre intervention humaine. Dans cette unité, vous découvrez comment concevoir un pipeline pour créer et déployer une application avec son infrastructure.

Créer des applications

De nombreux types d’applications doivent être compilés ou générés avant de pouvoir être utilisés. Le processus de génération prend le code source de l’application, effectue une séquence d’activités sur celui-ci, puis crée un ensemble de fichiers pouvant être déployés.

Le processus de génération compile le code source en fichiers binaires ou exécutables, mais il inclut généralement d’autres activités :

• Compression des fichiers image qui sont servis aux utilisateurs de votre site web.
• Linting de votre code pour vérifier s’il suit les bonnes pratiques de codage.
• Exécution de tests unitaires qui vérifient le comportement d’éléments individuels de votre application.

En plus de ces étapes, vous pouvez également procéder à la signature numérique des fichiers pour vous assurer qu’ils ne peuvent pas être modifiés.

Quelle que soit la série d’étapes, la sortie du processus de génération est un artefact déployable. L’artefact est normalement enregistré dans le système de fichiers de l’agent de pipeline. Les phases ultérieures de votre pipeline doivent fonctionner avec l’artefact pour le déployer dans vos environnements, puis le tester à mesure qu’il franchit les barrières qualité que vous définissez dans votre définition de pipeline.

Notes

Vous avez peut-être déjà entendu les termes d’intégration continue et de déploiement continu, ou CI et CD. Un processus de génération figure dans la partie d’intégration continue de votre pipeline.

Artefacts de pipeline

Les artefacts générés dans votre pipeline ne sont pas stockés dans votre dépôt Git. Ils sont dérivés du code source, mais ne sont pas eux-mêmes du code et n’appartiennent pas à un référentiel de contrôle de code source. Ils sont créés sur le système de fichiers de l’agent de pipeline. Un agent est créé pour chaque travail de pipeline. Vous devez donc disposer d’un moyen de partager les fichiers entre les travaux et les agents.

Les artefacts de pipeline offrent un moyen de stocker des fichiers dans Azure Pipelines et sont associés à l’exécution particulière de votre pipeline. Vous utilisez la tâche de pipeline intégrée PublishBuildArtifacts pour indiquer à Azure Pipelines de publier un fichier ou un dossier à partir du système de fichiers de l’agent en tant qu’artefact de pipeline :

- task: PublishBuildArtifacts@1
  displayName: Publish folder as a pipeline artifact
  inputs:
    artifactName: my-artifact-name
    pathToPublish: '$(Build.ArtifactStagingDirectory)/my-folder'

La propriété pathToPublish est l’emplacement qui contient vos fichiers de sortie ou de code compilés sur le système de fichiers de l’agent de pipeline. Le contenu à cet emplacement est publié dans l’artefact. Vous pouvez spécifier un fichier individuel ou un dossier.

Chaque artefact a un nom, que vous spécifiez à l’aide de la propriété de tâche artifactName. Vous utilisez le nom de l’artefact pour y faire référence ultérieurement dans le pipeline. Les travaux et les phases de pipeline suivants peuvent télécharger l’artefact afin de l’utiliser pour, par exemple, déployer le site web sur le serveur qui l’héberge :

Lorsque vous utilisez des travaux de déploiement, les artefacts de pipeline sont automatiquement téléchargés par défaut. Si vous utilisez des travaux standard, utilisez la tâche DownloadBuildArtifacts pour télécharger un artefact de pipeline :

- task: DownloadBuildArtifacts@0
  inputs:
    buildType: current
    downloadType: single
    artifactName: my-artifact-name
    downloadPath: '$(System.ArtifactsDirectory)'

Déployer des applications

Le processus de génération d’une application génère et publie un artefact déployable. Des phases ultérieures du pipeline déploient l’artefact. La façon dont vous déployez une application dépend du service que vous utilisez pour l’héberger.

Déployer dans Azure App Service

Votre entreprise de jouets utilise Azure App Service pour héberger son site web. Vous pouvez créer et configurer une application App Service à l’aide de Bicep. Mais au moment de déployer l’application, plusieurs options s’offrent à vous pour déplacer l’application compilée sur l’infrastructure d’hébergement. Ces options sont gérées dans le cadre du plan de données App Service.

L’approche la plus courante consiste à utiliser la tâche Azure Pipelines AzureRmWebAppDeployment :

- task: AzureRmWebAppDeployment@4
  inputs:
    azureSubscription: MyServiceConnection
    ResourceGroupName: MyResourceGroup
    WebAppName: my-app-service
    Package: '$(Pipeline.Workspace)/my-artifact-name/website.zip'

Vous devez fournir plusieurs éléments d’informations pour déployer votre application sur App Service. Ces informations incluent le groupe de ressources et le nom de ressource de l’application App Service, que vous spécifiez à l’aide des entrées ResourceGroupName et WebAppName. Comme vous l’avez appris dans l’unité précédente, vous devez ajouter une sortie à votre fichier Bicep et utiliser une variable de pipeline pour propager le nom de l’application dans l’ensemble de votre pipeline. Vous devez également spécifier un fichier .zip avec l’application à déployer à l’aide de l’entrée Package. Il s’agit généralement du chemin à un artefact de pipeline.

App Service dispose de son propre système d’authentification de plan de données, qu’il utilise pour les déploiements. La tâche AzureRmWebAppDeployment gère automatiquement le processus d’authentification pour vous :

La tâche AzureRmWebAppDeployment utilise le principal de service associé à votre connexion de service pour créer et télécharger automatiquement les informations d’identification nécessaires au déploiement. Elle utilise ensuite les informations d’identification de déploiement lorsqu’elle communique avec l’API de plan de données App Service.

App Service fournit également quelques autres fonctionnalités liées au déploiement, dont notamment les emplacements de déploiement. Les emplacements vous aident à déployer de nouvelles versions de vos applications de manière sûre et sans temps d’arrêt. Ils vous aident également à préparer et à « préchauffer » la nouvelle version de votre application avant d’envoyer du trafic de production vers celle-ci. Nous n’utilisons pas d’emplacements dans ce module, mais nous fournissons un lien vers des informations supplémentaires à leur sujet dans la page Résumé, à la fin du module.

Déployer des applications vers d’autres services Azure

Azure fournit de nombreuses autres options pour l’hébergement de vos applications, chacune ayant sa propre approche du déploiement.

Azure Functions repose sur App Service et utilise un processus de déploiement similaire à celui décrit précédemment.

Si vous déployez sur une machine virtuelle, vous devez généralement vous connecter à l’instance de machine virtuelle pour installer votre application. Vous devez souvent utiliser des outils spécialisés, tels que Chef, Puppet ou Ansible, pour orchestrer un déploiement sur des machines virtuelles.

Si vous utilisez Kubernetes ou Azure Kubernetes Service (AKS), l’approche pour générer et déployer votre solution est légèrement différente. Une fois votre application créée, votre pipeline crée une image conteneur et la publie dans un registre de conteneurs, à partir duquel votre cluster Kubernetes lit les données. Comme votre registre de conteneurs conserve l’application compilée, vous n’utilisez généralement pas un artefact de pipeline.

Dans ce module, nous nous concentrons sur Azure App Service pour illustrer les concepts de pipeline impliqués. Dans la page Résumé à la fin du module, nous fournissons des liens vers des informations supplémentaires sur le déploiement vers d’autres services d’hébergement.

Tester des applications dans votre pipeline

Dans un module précédent, vous avez appris la valeur et l’importance de l’exécution de tests automatisés à partir de votre pipeline. Lorsque vous déployez une application, il est recommandé que le pipeline exécute des tests qui appellent le code de l’application. Ces tests réduisent le risque qu’une erreur d’application ou de déploiement puisse entraîner un temps d’arrêt. Dans des scénarios plus avancés, vous pouvez même effectuer un ensemble de cas de test sur votre application, tels que l’appel d’API ou l’envoi et la surveillance d’une transaction synthétique.

De nombreuses applications implémentent des points de terminaison de contrôle d’intégrité. Lorsqu’un point de terminaison de contrôle d’intégrité reçoit une demande, il effectue une série de vérifications par rapport au site web, par exemple pour s’assurer que les bases de données et les services réseau sont accessibles à partir de l’environnement d’application. La réponse que le site renvoie indique si l’application est saine. Les développeurs peuvent écrire et personnaliser leurs propres contrôles d’intégrité en fonction des exigences de l’application. Si votre application dispose d’un point de terminaison de contrôle d’intégrité, il est souvent judicieux de la surveiller à partir de votre pipeline une fois la phase de déploiement terminée.

Votre pipeline de déploiement

Dans l’exercice suivant, vous mettez à jour votre pipeline de déploiement pour y ajouter de nouveaux travaux afin de générer l’application de votre site web et de la déployer dans chaque environnement :