Lorsque l’on développe des solutions applicatives, il arrive inévitablement le moment où nous devons déployer une nouvelle version en production.
Il existe bien des façons de faire, mais je souhaite vous proposer dans cet article quelques solutions efficaces et fiables que j’ai eu l’occasion d’utiliser ces dernières années chez Digiwin.
Dans cet article, je parlerai essentiellement de solutions de déploiement de code basées sur des langages open source. Ces technologies sont souvent exécutées sur un environnement Linux.
Qu’est-ce que le Déploiement Continu ?
Automatiser le déploiement depuis les sources produites est une nécessité pour apporter de la fiabilité dans le processus de livraison de nouvelles versions d’un logiciel.
Généralement, pendant les formations scolaires, lorsqu’on apprend à développer des logiciels, nous livrons les sources manuellement, via un serveur FTP par exemple. Le fait de recourir à une action manuelle, comme dans toute industrie, peut cependant engendrer une erreur d’origine humaine.
C’est pour cela qu’il est important, dès la phase d’initialisation de votre projet, de mettre en place une procédure de livraison et de l’automatiser. C’est ce que nous appelons le Déploiement Continu, ou CD (Continuous Deployment en Anglais).
Adapter votre stratégie de déploiement continu à votre gestion de projet
Dans les ESN, nous contractualisons généralement la réalisation d’un lot de fonctionnalités. C’est pourquoi on adopte souvent une stratégie de livraison par lot de fonctionnalités rassemblées dans une déclinaison unique du logiciel.
Chez les éditeurs de logiciel, nous pouvons retrouver des cycles plus courts avec la réalisation parallèle de fonctionnalités et une livraison en production au fil de l’eau de ces nouvelles fonctionnalités.
Côté gestion des sources, on retrouve souvent deux méthodologies GIT adaptées en fonction de la méthode de gestion de projet, Gitflow ou GithubFlow.
Deux approches principales de déploiement
L’approche « Push »
L’approche Push fait intervenir un système externe, la plupart du temps un outil d’intégration continue comme les Gitlab Pipelines, Github Actions…
Cet outil va déclencher une suite d’actions en fonction des commits sur GIT. C’est cet outil qui va ensuite se connecter au serveur ou au cluster pour mettre à jour le livrable. Il va donc pousser les nouvelles modifications vers l’environnement d’exécution.
Avantages / Inconvenients
Les plus :
- Les protections des branches / restrictions d’accès se font au niveau du SCM
- La procédure de déploiement est versionnée, comme les sources
- L’état du déploiement est visible sur le SCM
- Beaucoup d’outils différents peuvent être utilisés, notamment grâce à l’utilisation de Docker
Les moins
- L’outil doit disposer d’un accès technique (SSH par exemple) vers la plateforme d’exploitation
- Le SCM stocke les Credentials permettant de se connecter aux serveurs
- Enfermement sur un SCM spécifique. En cas de migration vers un autre outil, il faudra reconstruire la procédure de déploiement.
Comment faire ?
Hébergement de conteneurs Docker classique :
- On peut exposer le daemon Docker via TCP pour le piloter à distance. Ce qui permet d’ordonner l’exécution d’un conteneur sur le serveur directement.
- On peut aussi se connecter en SSH sur le serveur et utiliser des commandes docker locales, ce qui permet d’avoir recours à Docker Compose.
L’avantage est de pouvoir continuer à se connecter au serveur en SSH et manipuler les conteneurs sans l’outil de Pipeline.
Kubernetes :
- Il est possible de se connecter au Control PLane et de piloter les déploiements à l’aide de kubectl ou de Helm.
Non conteneurisé :
- Nous pouvons uploader des sources via rsync ou scp puis éventuellement se connecter via SSH au serveur pour exécuter des commandes (migration de bases de données, nettoyage de cache etc…)
- On peut utiliser des outils comme Ansistrano qui vont automatiser la transition entre deux versions des sources.
L’approche « Pull »
Les changements de versions sont gérés depuis l’intérieur du serveur ou du cluster.
Cela nécessite qu’un opérateur (un programme) soit en charge de surveiller le gestionnaire de sources (ou autre) afin de provoquer la mise à jour applicative. C’est donc cet opérateur qui définit et maintient l’état du déploiement.
Avantages / Inconvénients
Les plus :
- Pas besoin d’exposer les serveurs à des outils externes, les flux sont seulement sortants, et non plus entrants pour le déploiement.
- Pas besoin de modifier la procédure de déploiement lors d’un changement de SCM. On est moins enfermé dans un seul système.
- Les droits d’administration peuvent rester seulement en local et les protections/restrictions d’environnements ne sont pas altérables depuis l’extérieur.
- Le monitoring d’un déploiement est plus aisé, car le système est synchronisé en permanence avec la production. Cela permet d’avoir des outils plus proches de l’exécution.
Les moins :
- La gestion des secrets et des variables d’environnement se fait côté exécution. Il est donc nécessaire d’avoir une sauvegarde externe de ces données pour pouvoir les restaurer en cas d’avarie.
- Il peut y avoir une latence entre la mise à jour du SCM et le déploiement effectif. On est généralement basé sur un principe de polling, consistant à vérifier à une certaine fréquence s’il existe une mise à jour.
- Le versionning des configurations de déploiement est indépendant du système applicatif. Il faut donc être précautionneux lors de l’ajout de commande à la livraison d’une nouvelle version par exemple.
Comment faire ?
Hébergement de conteneurs Docker classiques :
- On peut simplement vérifier périodiquement qu’une nouvelle image est disponible sur un registry et faire la mise à jour automatiquement. Exemple d’outil : Watchtower
- Déployer un runner sur le serveur qui restera en attente d’exécuter un pipeline de déploiement. Ce mode est un peu hybride avec le mode Push car il permet de ne pas exposer publiquement les accès au serveur, c’est le runner qui vérifie périodiquement s’il n’a pas une tâche à effectuer.
Kubernetes :
- Utiliser un outil comme ArgoCD qui est un outil complet permettant de manager l’état d’un cluster Kubernetes.
Non conteneurisé :
- Il est possible de surveiller périodiquement si de nouvelles sources sont disponibles sur GIT ou sur un Bucket S3.
Conclusion
Que ce soit par l’approche Pull ou Push, il faudra adapter vos outils à votre façon de fonctionner. Ce choix doit aussi tenir compte des acteurs en charge de la gestion des procédures de déploiement : équipe OPS ou développeurs ?
Votre SCM influencera aussi certainement le choix de votre stratégie de déploiement continu.
Chacune de ces stratégies a des avantages et inconvénients. Chez Digiwin, nous sommes là pour vous aider et vous accompagner à faire le bon choix et à mettre en place un socle fiable et pérenne pour le déploiement de vos applications.
