Comment assurer le déploiement continu des applications modernes ?

L'expression "application moderne" est fréquemment utilisée dans les blogs et les articles techniques, mais sa définition a toujours été subjective. Lorsque je parle d'une application moderne, voici ce que j'ai à l'esprit.

Qu'est-ce qu'une application moderne ?

Les applications modernes sont construites avec des modèles architecturaux modulaires, des modèles opérationnels sans serveur et des processus de développement agiles. Elles vous permettent d'innover plus rapidement, de réduire les risques, d'accélérer la mise sur le marché et de diminuer votre coût total de possession (TCO). L'une des façons pour une entreprise d'itérer et d'innover plus rapidement est d'adopter des pratiques DevOps modernes - notamment CI / CD. Il s'agit d'une autre expression que vous avez probablement rencontrée lors d'une conférence ou dans les médias. CI / CD est l'abréviation de Continuous Integration / Continuous Deployment. Dans certains cas, le "D" signifie également "Delivery" (livraison), mais pour les besoins de cet article, nous opterons pour "Deployment". Si vous vous êtes déjà demandé comment moderniser votre application en adoptant les meilleures pratiques de CD, cet article vous est destiné.

Un avertissement - Bien que l'article illustre le déploiement continu avec l'utilisation des services AWS tels que AWS CodeDeploy et Amazon Elastic Container Service (ECS), les principes restent les mêmes pour le fournisseur de cloud et l'outil de votre choix.

Trouver l'équilibre entre agilité et fiabilité

Le rêve de tout développeur est d'écrire du code, d'appuyer sur un gros bouton rouge et de voir ensuite ce code en production. Cela peut être une bonne ou une mauvaise chose. D'une certaine manière, c'est le processus de développement le plus agile qui soit. Qui a besoin de contrôles et d'équilibres, n'est-ce pas ? Mais c'est aussi une *très* mauvaise chose. Bugs et erreurs peuvent faire planter votre application et offrir à vos clients une expérience terrible. Alors comment trouver l'équilibre entre agilité et fiabilité ?

Le déploiement continu est un moyen de se rapprocher de la réalisation de ce rêve. Tout comme l'intégration continue - où les développeurs fusionnent régulièrement leurs modifications de code dans un référentiel central, après quoi des constructions et des tests automatisés sont exécutés - le CD est la pratique où les modifications de code sont automatiquement préparées pour une mise en production. Le déploiement continu s'appuie sur l'intégration continue en déployant toutes les modifications du code dans un environnement de test et/ou un environnement de production après la phase de construction. Il peut y avoir (et il y a généralement) plusieurs étapes de test parallèles avant un déploiement en production. La différence entre la livraison continue et le déploiement continu est la présence d'une approbation manuelle pour la mise en production. Avec le déploiement continu, la production se fait automatiquement sans approbation explicite. Aussi bien que d'appuyer sur ce gros bouton rouge.

‍

Comment réussir le déploiement continu ?

Les objectifs d'un déploiement continu efficace sont les suivants :

• Déployer automatiquement les nouvelles modifications dans les environnements de test,
• Déploiement en production en toute sécurité sans impact sur les clients,
• Livrer plus rapidement en réduisant les délais de modification et le taux d'échec des modifications.

Avec le cloud, la mise en œuvre de cette pratique est plus facile que jamais. Prenons l'exemple d'AWS CodeDeploy qui permet des déploiements automatisés avec des serveurs virtuels, des conteneurs, des serverless et même des charges de travail sur site.

Déploiement continu appliqué à AWS CodeDeploy

Voici un exemple de la manière dont AWS CodeDeploy automatise vos déploiements sur Amazon ECS. (Cela suppose que vous avez les conditions préalables d'une application fonctionnant sur AWS avec les autorisations et les politiques IAM pertinentes).

CodeDeploy a besoin d'un fichier de spécification d'application ou AppSpec pour gérer les déploiements. Ce fichier est généralement formaté en YAML (ou JSON) et ressemble à quelque chose comme ceci :

version : 0.0
os : linux
fichiers :
- source : /
destination : /var/www/html/WordPress
hooks :
BeforeInstall :
- emplacement : scripts/install_dependencies.sh
timeout : 300
runas : root
AfterInstall :
- emplacement : scripts/change_permissions.sh
timeout : 300
runas : root
ApplicationStart :
- emplacement : scripts/start_server.sh
- emplacement : scripts/create_test_db.sh
timeout : 300
runas : root
ApplicationStop :
- emplacement : scripts/stop_server.sh
timeout : 300
runas : root

‍

Comme vous pouvez le voir, il y a différentes sections dans le fichier AppSpec. Les sections telles que version et os sont explicites. Vous pouvez définir les configurations de l'application et également spécifier le système d'exploitation utilisé.

La section "hooks" contient des mappings qui relient les crochets d'événements du cycle de vie du déploiement à un ou plusieurs scripts. Chaque crochet de déploiement est exécuté une fois par déploiement vers une instance. Vous pouvez spécifier un ou plusieurs scripts à exécuter dans un hook. Chaque crochet pour un événement du cycle de vie est spécifié avec un chaîne de caractère sur une ligne séparée. Il existe différents événements de cycle de vie tels que ApplicationStop, BeforeInstall et ApplicationStop afin que les scripts automatisés puissent s'exécuter à chacun de ces événements. Par exemple, dans le crochet ApplicationStart, les 2 scripts démarrent un serveur et créent une base de données. De même, le crochet ApplicationStop comporte un script qui arrête le serveur.

Comprendre les types de déploiement et les configurations

Vous gérez donc vos déploiements avec un fichier AppSpec, ce qui n'est que le début d'un déploiement automatisé. L'étape suivante consiste à déterminer comment éliminer les temps d'arrêt et minimiser les erreurs pour que vos clients ne soient pas affectés. La clé est de choisir le bon type de déploiement et la bonne configuration pour votre application. CodeDeploy propose deux options de type de déploiement :

•  1. Déploiement sur place où l'application sur chaque instance du groupe de déploiement est arrêtée, la dernière révision de l'application est installée, et la nouvelle version de l'application est lancée et validée. 
• 2. Déploiements bleus/verts - que nous allons maintenant aborder en profondeur.

Stratégie de déploiement bleu/vert

Nous voulons créer des applications modernes, et des applications modernes nécessitent des solutions modernes. L'une des façons de moderniser votre application est d'adopter la stratégie de déploiement bleu/vert. Il s'agit d'une stratégie de déploiement dans laquelle vous créez deux environnements distincts, mais identiques. Un environnement (bleu) exécute la version actuelle de l'application et un environnement (vert) exécute la nouvelle version de l'application. Une fois les tests terminés sur l'environnement vert, le trafic des applications en direct est dirigé vers l'environnement vert et l'environnement bleu est déprécié.

‍

Cette stratégie augmente la disponibilité des applications et réduit le risque de déploiement en simplifiant le processus de retour en arrière en cas d'échec du déploiement. La redirection du trafic peut se faire de trois manières différentes.

‍

• Tout en une fois: Tout le trafic est transféré de l'ensemble de tâches ECS vers la fonction ou l'ensemble de tâches mis à jour en une seule fois. Pour ce faire, choisissez la configuration CodeDeployDefault.ECSAllAtOnce. Comme son nom l'indique, cette configuration transfère tout le trafic vers le conteneur Amazon ECS mis à jour en une seule fois.
• Linéaire: Le trafic est déplacé par incréments égaux avec un nombre égal de minutes entre chaque incrément. Vous pouvez choisir parmi des options linéaires prédéfinies qui spécifient le pourcentage de trafic déplacé dans chaque incrément et le nombre de minutes entre chaque incrément. Il existe deux configurations prédéfinies que vous pouvez utiliser et dont les noms sont explicites : CodeDeployDefault.ECSLinear10PercentEvery1Minutes qui décale 10% du trafic toutes les minutes jusqu'à ce que tout le trafic soit décalé, et CodeDeployDefault.ECSLinear10PercentEvery3Minutes qui décale 10% du trafic toutes les trois minutes jusqu'à ce que tout le trafic soit décalé.
• Canari: Pour savoir pourquoi on parle de déploiement " canari ", allez jusqu'au bas de l'article ! Ici, le trafic est transféré en deux étapes. Vous pouvez choisir parmi des options canari prédéfinies qui spécifient le pourcentage de trafic transféré vers l'ensemble de tâches ECS dans le premier incrément et l'intervalle, en minutes, avant que le trafic restant ne soit transféré dans le second incrément. CodeDeployDefault.ECSCanary10Percent5Minutes transfère 10 % du trafic lors du premier incrément. Les 90 % restants sont déployés cinq minutes plus tard, tandis que CodeDeployDefault.ECSCanary10Percent15Minutes décale 10 % du trafic dans le premier incrément et les 90 % restants sont déployés 15 minutes plus tard.

‍

La différence subtile entre les déploiements linéaires et canariens réside dans la façon dont le trafic est déplacé après les premiers X pour cent. Dans le cas d'un déploiement linéaire, le transfert suit une progression... linéaire ; mais dans le cas d'un déploiement canari, 90 % du trafic est transféré en une seule fois, APRÈS un certain temps. Dans ce laps de temps, s'il n'y a pas d'alarmes ou d'erreurs, on suppose que la nouvelle mise à jour est bonne à prendre. Les déploiements linéaires et canariens via CodeDeploy limitent l'exposition du trafic en direct à la nouvelle version de l'application à un pourcentage du trafic total, afin de surveiller les performances avant d'acheminer le trafic restant en toute confiance. Vous pouvez également configurer des alarmes Amazon CloudWatch pour vous alerter si un problème est détecté. CodeDeploy peut alors redéployer automatiquement une révision stable d'une application précédemment déployée en tant que nouveau déploiement.

Faites confiance au processus

La modernisation est un parcours et non quelque chose qu'une entreprise peut réaliser du jour au lendemain. La mise en place de processus de déploiement continu se construit avec le temps. D'après mon expérience personnelle, j'ai constaté que l'adoption d'une "vision pessimiste" - où l'on trouve toutes les raisons d'échouer un déploiement - fait des merveilles dans la construction d'un pipeline de déploiement robuste qui minimise les temps d'arrêt pour vos clients. Le CI / CD est une approche qui est (pardonnez le jeu de mots) en constante évolution - donc le meilleur moment pour commencer à moderniser est maintenant !

‍

De plus, comme promis, voici un Fun Fact™ - Le nom du déploiement d' un canari fait allusion aux canaris (oiseaux) en cage que les mineurs emportaient avec eux dans les tunnels de la mine. Si des gaz dangereux tels que le monoxyde de carbone s'accumulaient dans la mine, les gaz tuaient le canari avant de tuer les mineurs, fournissant ainsi un avertissement pour sortir immédiatement des tunnels. Ainsi, dans le cas des déploiements de canaris, si l'un des déploiements provoque une erreur et déclenche une alarme, le déploiement est alors annulé et le client n'est pas impacté. Maintenant vous le savez 🤓