Bonnes pratiques de déploiement

Chaque équipe de développement a des exigences uniques qui peuvent compliquer l’implémentation d’un pipeline de déploiement efficace sur un service cloud. Cet article présente les trois principaux composants du déploiement sur App Service : les sources de déploiement, les pipelines de génération et les mécanismes de déploiement. Cet article présente également quelques-unes des meilleures pratiques et des conseils pour des environnements de langage spécifiques.

Composants du déploiement

Cette section décrit les trois principaux composants à déployer sur App Service.

Source de déploiement

Une source de déploiement correspond à l’emplacement de votre code d’application. Pour les applications de production, la source de déploiement est généralement un référentiel hébergé par un logiciel de gestion de version, comme GitHub, Bitbucket ou Azure Repos. Pour les scénarios de développement et de test, la source de déploiement peut être un projet sur votre ordinateur local.

Pipeline de build

Une fois que vous avez choisi une source de déploiement, l’étape suivante consiste à choisir un pipeline de build. Un pipeline de build lit votre code source à partir de la source de déploiement et exécute une série d’étapes pour obtenir l’application dans un état exécutable.

Les étapes peuvent inclure la compilation de code, la minification du code HTML et JavaScript, l’exécution de tests et la création de packages de composants. Les commandes spécifiques exécutées par le pipeline de build dépendent de votre pile de langage. Vous pouvez exécuter ces opérations sur un serveur de build, tel qu’Azure Pipelines ou localement.

Mécanisme de déploiement

Le mécanisme de déploiement est l’action utilisée pour placer votre application intégrée dans le répertoire /home/site/wwwroot de votre application web. Le répertoire /wwwroot est un emplacement de stockage monté partagé par toutes les instances de votre application web. Lorsque le mécanisme de déploiement place votre application dans ce répertoire, vos instances reçoivent une notification pour synchroniser les nouveaux fichiers.

App Service prend en charge les mécanismes de déploiement suivants :

• Points de terminaison Kudu : Kudu est l’outil de productivité des développeurs open source qui s’exécute en tant que processus distinct dans Windows App Service. Il s’exécute en tant que deuxième conteneur dans Linux App Service. Kudu gère les déploiements continus et fournit des points de terminaison HTTP pour le déploiement, comme zipdeploy/.
• FTP et WebDeploy : À l' aide des informations d’identification de votre site ou de votre utilisateur, vous pouvez télécharger des fichiers via FTP ou WebDeploy. Ces mécanismes ne passent pas par Kudu.

Les outils de déploiement, tels qu’Azure Pipelines, Jenkins et les plug-ins d’éditeur utilisent un de ces mécanismes de déploiement.

Utiliser des emplacements de déploiement

Dans la mesure du possible, lorsque vous déployez une nouvelle build de production, utilisez des emplacements de déploiement. Lorsque vous utilisez un plan App Service Standard ou mieux, vous pouvez déployer votre application dans un environnement intermédiaire, valider vos modifications et effectuer des tests de vérification de build. Lorsque vous êtes prêt, échangez vos emplacements intermédiaires et de production. L’opération d’échange préchauffe les instances de worker nécessaires pour correspondre à votre échelle de production, ce qui élimine les temps d’arrêt.

Déployer du code en continu

Si votre projet a des branches désignées pour le test, l'assurance qualité et la préproduction, chacune de ces branches doit être déployée en continu vers un emplacement de préproduction. Cette approche est appelée conception Gitflow. Cette conception permet à vos parties prenantes d’évaluer et de tester facilement la branche déployée.

Le déploiement continu ne doit jamais être activé pour votre emplacement de production. Au lieu de cela, votre branche de production (souvent la principale) doit être déployée sur un emplacement de non-production. Lorsque vous êtes prêt à mettre en production la branche de base, échangez-la dans l’emplacement de production. Un échange en production, au lieu d’un déploiement en production, vous permet d’éviter les temps d’arrêt et de restaurer les modifications en les échangeant à nouveau.

Déployer des conteneurs en continu

Pour les conteneurs personnalisés de Docker ou d’autres registres de conteneurs, déployez l’image dans un emplacement de préproduction et échangez en production pour éviter les temps d’arrêt. L’automatisation est plus complexe que le déploiement de code. Vous devez envoyer (push) l’image à un registre de conteneurs et mettre à jour la balise d’image sur l’application web.

Pour chaque branche que vous souhaitez déployer sur un slot, configurez l’automatisation pour exécuter ces tâches à chaque commit dans la branche.

1. Générez et balisez l’image. Dans le cadre du pipeline de build, étiquetez l’image avec l’ID de commit git, le timestamp ou d’autres informations identifiables. Il est préférable de ne pas utiliser la balise latest par défaut. Sinon, il est difficile de retracer le code actuellement déployé, ce qui rend le débogage beaucoup plus compliqué.
2. Envoyez (push) l’image balisée. Une fois l’image générée et balisée, le pipeline envoie (push) l’image au registre de conteneurs. À l’étape suivante, l’emplacement de déploiement extrait l’image balisée du registre de conteneurs.
3. Mettez à jour l’emplacement de déploiement avec la nouvelle balise d’image. Lorsque cette propriété est mise à jour, le site redémarre automatiquement et extrait la nouvelle image conteneur.

Cet article contient des exemples pour les frameworks d’automatisation courants.

Utiliser Azure DevOps

App Service est doté de la livraison continue intégrée pour les conteneurs via le centre de déploiement. Accédez à votre application dans le Portail Azure. Sous Déploiement, sélectionnez Centre de déploiement. Suivez les instructions pour sélectionner votre référentiel et votre branche. Cette approche permet de configurer un pipeline DevOps de construction et de déploiement pour construire, baliser et déployer automatiquement votre conteneur lorsque de nouveaux commits sont poussés vers la branche que vous avez sélectionnée.

Utiliser GitHub Actions

Vous pouvez également automatiser le déploiement de vos conteneurs à l’aide de GitHub Actions. Le fichier de workflow génère et balise le conteneur avec l’ID de validation, l’envoie (push) à un registre de conteneurs et met à jour l’application web spécifiée avec la nouvelle balise d’image.

on:
  push:
    branches:
    - <your-branch-name>

name: Linux_Container_Node_Workflow

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    # checkout the repo
    - name: 'Checkout GitHub Action'
      uses: actions/checkout@main

    - uses: azure/docker-login@v1
      with:
        login-server: contoso.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}

    - run: |
        docker build . -t contoso.azurecr.io/nodejssampleapp:${{ github.sha }}
        docker push contoso.azurecr.io/nodejssampleapp:${{ github.sha }} 

    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'node-rnc'
        publish-profile: ${{ secrets.azureWebAppPublishProfile }}
        images: 'contoso.azurecr.io/nodejssampleapp:${{ github.sha }}'

Utiliser d’autres fournisseurs d’automatisation

Les étapes répertoriées ci-dessus s’appliquent à d’autres utilitaires d’automatisation tels que CircleCI ou Travis CI. Toutefois, vous devez utiliser Azure CLI pour mettre à jour les emplacements de déploiement avec de nouvelles balises d’image lors de la dernière étape. Pour utiliser Azure CLI dans votre script d’automatisation, générez un principal de service à l’aide de la commande suivante.

az ad sp create-for-rbac --name "myServicePrincipal" --role contributor \
   --scopes /subscriptions/{subscription}/resourceGroups/{resource-group} \
   --sdk-auth

Dans votre script, connectez-vous en utilisant az login --service-principal et en fournissant les informations principales. Vous pouvez ensuite utiliser az webapp config container set pour définir le nom du conteneur, la balise, l’URL du registre et le mot de passe du registre. Pour plus d’informations, consultez Comment se connecter à Azure CLI sur Circle CI.

Considérations spécifiques au langage

Gardez à l’esprit les considérations suivantes pour les implémentations Java, Node et .NET.

Java

Utilisez l’API zipdeploy Kudu pour déployer des applications JAR. Utilisez wardeploy pour les applications WAR. Si vous utilisez Jenkins, vous pouvez utiliser ces API directement lors de votre phase de déploiement. Pour plus d’informations, consultez Déployer sur Azure App Service avec Jenkins.

Nœud

Par défaut, Kudu exécute les étapes de génération de votre application Node (npm install). Si vous utilisez un service de build tel qu’Azure DevOps, la build Kudu n’est pas nécessaire. Pour désactiver la build Kudu, créez un paramètre d’application SCM_DO_BUILD_DURING_DEPLOYMENT, avec une valeur de false.

.FILET

Par défaut, Kudu exécute les étapes de génération de votre application .NET (dotnet build). Si vous utilisez un service de build tel qu’Azure DevOps, la build Kudu n’est pas nécessaire. Pour désactiver la build Kudu, créez un paramètre d’application SCM_DO_BUILD_DURING_DEPLOYMENT, avec une valeur de false.

Autres points à prendre en considération pour le déploiement

D’autres considérations incluent le cache local et le processeur ou la mémoire élevée.

Cache local

Le contenu d'Azure App Service est stocké sur Azure Storage et est exposé de manière durable sous forme de partage de contenu. Toutefois, certaines applications ont uniquement besoin d’un magasin de contenu en lecture seule très performant à partir duquel elles peuvent s’exécuter avec une haute disponibilité. Ces applications peuvent tirer parti de l’utilisation du cache local. Pour plus d’informations, consultez Vue d’ensemble du cache local Azure App Service.

Remarque

Le cache local n’est pas recommandé pour les sites de gestion de contenu tels que WordPress.

Pour éviter les temps d’arrêt, utilisez toujours le cache local avec des emplacements de déploiement. Pour plus d’informations sur l’utilisation conjointe de ces fonctionnalités, consultez Meilleures pratiques.

Processeur ou mémoire à un niveau élevé

Si votre plan App Service utilise plus de 90 % de l’UC ou de la mémoire disponible, la machine virtuelle sous-jacente risque de rencontrer des problèmes lors du traitement de votre déploiement. Lorsque cette situation se produit, augmentez temporairement la quantité d’instances pour procéder au déploiement. Une fois le déploiement terminé, vous pouvez rétablir le nombre d’instances à sa valeur précédente.

Pour plus d’informations, consultez Diagnostics App Service pour connaître les meilleures pratiques applicables spécifiques à votre ressource.

1. Accédez à votre application web dans le portail Azure.

2. Dans le volet de navigation de gauche, sélectionnez Diagnostiquer et résoudre les problèmes pour ouvrir Diagnostics App Service.

3. Choisissez Disponibilité et performances ou explorez d’autres options, telles que Analyse de l’utilisation élevée du processeur.

   Affichez l’état actuel de votre application en ce qui concerne ces meilleures pratiques.

Vous pouvez également utiliser ce lien pour ouvrir directement les diagnostics de l'App Service pour votre ressource : https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.

Contenu connexe

• Informations de référence sur les variables d’environnement et les paramètres d’application