Déploiements
To be effective, a software system must be deployable. The higher the cost of deployments, the less useful the system is. A goal of a software architecture, then, should be to make a system that can be easily deployed with a single action. Unfortunately, deployment strategy is seldom considered during initial development. This leads to architectures that may make the system easy to develop, but leave it very difficult to deploy.
– Robert C. Martin, (Martin 2018)
Il y a une raison simple et fondamentale pour aborder le déploiement dès maintenant : à trop peaufiner un développement pour soi-même, on en oublie que l’objectif final est d’exposer l’application, de la rendre exécutable sur un serveur et accessible à des utilisateurs.
Attendre le dernier moment, c’est risquer d’oublier des exigences clés, de négliger une fonctionnalité essentielle, ou de devoir réadapter l’application — parfois lourdement — à un environnement cible alors que le développement est pourtant terminé, testé et validé.
Dans cette partie-ci, nous parlerons de méthodes de travail, avec comme objectif d’éviter que l’application ne tourne que sur notre machine et que chaque déploiement ne soit une plaie à gérer. Chaque mise à jour doit être réalisable de la manière la plus simple possible, et chaque étape doit être le plus possible automatisée.
Dans son plus simple élément, la mise à disposition d’une nouvelle version d’une application pourrait se résumer à ces trois étapes :
Dans une version plus automatisée, une application pourrait être mise à jour simplement en envoyant son code sur un dépôt centralisé : ce déclencheur a la responsabilité de démarrer une chaı̂ne de vérification d’utilisabilité, de bon fonctionnement et de sécurité, pour immédiatement la mettre à disposition de nouveaux utilisateurs si chaque acteur de cette chaı̂ne indique que tout est OK.
D’autres mécanismes fonctionnent également, mais au plus les actions nécessitent d’étapes ou d’intervenants humains, au plus la probabilité qu’un problème survienne est grande, même dans le cas de processus de routine. Sans aller jusqu’à demander de développer vos algorithmes sur douze pieds, la programmation reste un art régit par un ensemble de bonnes pratiques, par des règles à respecter et par la nécessité de travailler avec d’autres personnes qui ont souvent une expérience, des compétences ou une approche différente.
Because value is created only when our services are running in production, we must ensure that we are not only delivering fast flow, but that our deployments can also be performed without causing chaos and disruptions such as service outages, service impairments, or security or compliance failures (Kim et al. 2016)
Un bon déploiement ne doit pas reposer sur une multitude de scripts épars et non documentés. Il doit être rapide, fiable et reproductible. Cet objectif passe par une bonne architecture logicielle, où chaque composant est isolé, démarre correctement, s’intègre aux autres, et peut être supervisé.
Prendre en compte le déploiement dès les premières phases du développement permet également de documenter les procédures d’installation, de mise à jour et de sauvegarde dès le départ. À la fin de chaque itération, les fonctionnalités devraient être intégrées, testées, fonctionnelles, et déployables dans un environnement proche de la production — en s’appuyant sur une base commune avec l’environnement de développement.
Le déploiement d’une nouvelle version devrait être aussi simple que possible — idéalement, l’exécution de quelques lignes dans un script Bash.
Red Hat propose un article intitulé What Is IaaS, qui résume efficacement les différents modèles d’hébergement et les responsabilités associées :
[cols=“,,,,” options=“header”] |=== | |On-site |IaaS |PaaS |SaaS |Applications |✅ |✅ |✅ |❌ |Données |✅ |✅ |✅ |❌ |Exécution |✅ |✅ |❌ |❌ |Middleware |✅ |✅ |❌ |❌ |Système d’exploitation |✅ |✅ |❌ |❌ |Virtualisation |✅ |❌ |❌ |❌ |Serveurs |✅ |❌ |❌ |❌ |Stockage |✅ |❌ |❌ |❌ |Réseau |✅ |❌ |❌ |❌ |===
On distingue ainsi plusieurs approches :
- Le déploiement on-premises (sur site), qui implique la gestion complète de l’infrastructure, du réseau jusqu’au maintien de l’application.
- Les Infrastructures as a Service (IaaS), où la couche d’infrastructure est prise en charge (virtualisation, stockage, réseau), mais où vous restez responsable du système, des applications et des données.
- Les Platforms as a Service (PaaS), où il vous suffit de déployer votre application selon des standards imposés, sans vous préoccuper de l’OS ou des dépendances système.
- Les Software as a Service (SaaS), où vous n’avez plus qu’à utiliser l’application finale, déjà hébergée, configurée et maintenue par un tiers.
Objectifs de cette section
Dans cette section, nous allons :
- Définir l’infrastructure et les composants nécessaires à l’application ;
- Configurer l’hôte (physique, virtuel ou conteneurisé) et y déployer l’application, en explorant également les solutions d’automatisation comme Ansible ou SaltStack ;
- Mettre en place les outils de supervision, d’analyse de logs, de gestion d’erreurs et de remontée d’informations pour assurer la robustesse de l’application une fois en ligne.
Méthodes étudiées
Nous détaillerons ensuite trois méthodes concrètes de déploiement :
- link:/deployment/on-premise/[Sur une machine hôte], en embarquant tous les composants sur un serveur unique. Ce n’est pas la solution la plus flexible (pas de load balancer, ni de base de données distribuée), mais elle constitue un bon point de départ.
- link:/deployment/cloud-native/[Dans des conteneurs], à l’aide de Docker Compose, pour une architecture plus modulaire et portable (toujours sur un seul hôte dans un premier temps).
- link:/deployment/platform-as-a-service/[Sur une plateforme PaaS], afin de s’abstraire de toute la configuration système et ne se concentrer que sur le déploiement de l’application elle-même.