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 allez apprendre à concevoir un workflow pour créer et déployer une application parallèlement à 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. Un processus de génération inclut habituellement d’autres activités, notamment la compression des fichiers image qui seront envoyés aux utilisateurs de votre site web, le linting de votre code pour vérifier qu’il respecte les bonnes pratiques de codage et l’exécution de tests unitaires qui vérifient le comportement des différents composants de votre application. Vous pouvez également effectuer des étapes telles que la signature numérique des fichiers pour garantir qu’ils ne pourront 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’exécuteur de workflow. Les parties ultérieures de votre workflow 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 workflow.

Remarque

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

Artefacts de workflow

Les artefacts générés dans votre workflow 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. Ils n’appartiennent donc pas à un référentiel de contrôle de code source. Ils sont créés dans le système de fichiers de l’exécuteur de workflow. Un exécuteur est créé pour chaque travail de workflow. Vous devez donc disposer d’un moyen de partager les fichiers entre les travaux et les agents.

Les artefacts de flux de travail offrent un moyen de stocker des fichiers dans GitHub Actions et sont associés à l’exécution particulière de votre flux de travail. Vous utilisez l’action de workflow actions/upload-artifact pour indiquer à GitHub Actions de charger un fichier ou un dossier à partir du système de fichiers de l’exécuteur en tant qu’artefact de workflow :

- name: Upload folder as a workflow artifact
  uses: actions/upload-artifact@v3
  with:
    name: my-artifact-name
    path: ./my-folder

La propriété path est l’emplacement qui contient vos fichiers de sortie ou de code compilés sur le système de fichiers de l’exécuteur du travail. Le contenu à cet emplacement sera chargé dans l’artefact. Vous pouvez spécifier un seul fichier, plusieurs fichiers ou un dossier.

Chaque artefact a un nom, que vous spécifiez à l’aide de la propriété name. Vous utilisez le nom de l’artefact pour y faire référence ultérieurement dans le workflow. Les travaux de workflow 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 :

Utilisez l’action actions/download-artifact pour télécharger tous les artefacts de workflow :

- uses: actions/download-artifact@v3

Vous pouvez aussi spécifier un nom d’artefact pour télécharger uniquement un artefact spécifique :

- uses: actions/download-artifact@v3
  with:
    name: my-artifact-name

Déployer des applications

Le processus de génération d’une application génère et charge un artefact déployable. Les travaux ultérieurs dans le workflow 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 lorsque le moment arrive de déployer l’application, vous disposez de plusieurs options pour transférer 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 l’action azure/webapps-deploy :

- uses: azure/webapps-deploy@v2
  with:
    app-name: my-app-service
    package: 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 nom de ressource de l’application App Service, que vous spécifiez à l’aide de la propriété app-name. Comme vous l’avez appris dans l’unité précédente, vous devez ajouter une sortie à votre fichier Bicep et utiliser une variable de workflow pour propager le nom de l’application dans l’ensemble de votre workflow. Vous devez également spécifier un fichier .zip avec l’application à déployer à l’aide de la propriété package. Il s’agit généralement du chemin d’accès à un artefact de workflow.

App Service dispose de son propre système d’authentification de plan de données, qu’il utilise pour les déploiements. L’action azure/webapps-deploy gère automatiquement le processus d’authentification pour vous :

L’action azure/webapps-deploy utilise l’identité associée à la session Azure active de votre travail, que vous avez connectée à l’aide d’une identité de charge de travail. L’action permet de créer et de télécharger 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 sur la page Résumé 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), vous utiliseriez normalement une approche légèrement différente pour générer et déployer votre solution. Une fois votre application créée, votre workflow 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 workflow.

Dans ce module, nous nous concentrons sur Azure App Service pour illustrer les concepts de workflow 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 workflow

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 workflow. Lorsque vous déployez une application, il est recommandé que le workflow 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 workflow une fois le travail de déploiement terminé.

Votre workflow de déploiement

Dans l’exercice suivant, vous allez mettre à jour votre workflow de déploiement pour ajouter de nouveaux travaux afin de créer l’application de votre site web et de la déployer dans chaque environnement :