Dans un précédent article nous vous avons parlé de la démarche devops. La principale raison de cette démarche est d’avoir des mises en production facilitées, tout en ayant une meilleure confiance dans les livrables. A moins que vous préfériez passer des nuits blanches au boulot…
Débloque les + belles offres tech en 10 mins
N’importe qui à la prod’ vous le dira : on ne change pas un système qui fonctionne… dans les faits c’est une très mauvaise pratique. En effet tôt ou tard il faudra faire des changements, et plus on attend pour les faire plus on aura mal. Dès lors il faut plutôt pratiquer la politique du « release early, release often », autrement dit on livre tôt et souvent. Ca permet comme ça de fournir des micro-changements dans l’application et, au cas où quelque chose va mal, on parvient très vite à le localiser et le résoudre. Cela implique néanmoins de mettre en place l’infrastructure nécessaire pour des tests poussés et pouvant être exécutés fréquemment. Il faut aussi mettre à jour régulièrement le système de base de la machine, notamment pour des raisons de sécurité, mais là encore ça ne se fait pas sans tests préalables.
Le packaging des livrables
Une constante revient parmi les équipes de production : l’installation doit pouvoir se réaliser en un clic ou une commande simple. On observe en effet bien trop souvent, notamment dans le monde JEE, des équipes qui fournissent les fichiers .class et une documentation de 200 pages pour faire le déploiement, quand ce n’est pas plus. Certains éditeurs de logiciels à ce niveau en sont à oublier des fichiers dans leurs livrables, car tout est fait à la main. Cette situation n’est pas tenable, et donc il faut soigner le packaging.
L’idéal est de s’adapter au format natif de la plateforme cible. Par exemple sous Windows les livrables seront fournis en .msi, sous les Linux à base Debian en .deb, et pour les Redhat des RPM. De la sorte on peut bénéficier des outils natifs de la plateforme. Sous Windows c’est plus compliqué mais sous les vrais systèmes on peut par exemple déclarer qu’on a besoin de telle ou telle librairie, et au moment de l’installation des livrables les librairies seront automatiquement installées si elles ne l’étaient pas au préalable.
La gestion de configuration
Un logiciel, quel qu’il soit, se compose en fait de trois éléments principaux :
- Le code
- La configuration
- La plateforme cible
Pour le code les choses sont évidentes. Maintenant il est également important de versionner la configuration et de la conserver dans un gestionnaire de sources, afin de pouvoir monter rapidement une machine. En effet contrairement à ce qu’on pourrait penser les seules choses à sauvegarder sur un serveur sont les données utilisateur. Le reste doit pouvoir être redéployé très rapidement.
Par exemple dans mes expériences passées en packageant des logiciels en RPM il suffisait de cinq minutes pour installer une nouvelle machine, alors que sans ceux-ci pour la même opération il aurait fallu beaucoup plus. Et de même la configuration était ensuite appliquée automatiquement, avec des outils dédiés.
La configuration par défaut
Afin de diminuer le travail de configuration au déploiement, même si celle-ci est automatisée, les livrables fournis par les équipes de développement devraient fournir une configuration par défaut. Celle-ci contient notamment :
- La documentation complète des différents paramètres au sein même des fichiers de configuration.
- Des paramètres préconfigurés là où c’est possible, par exemple la taille de la heap de la JVM ou encore pour les vrais systèmes les différents chemins.
La configuration automatique des applications
En analysant les configurations des serveurs on s’aperçoit que bien souvent l’essentiel des configurations est identique entre les différentes machines et seuls changent quelques paramètres comme les URLs de bases de données. Dès lors il est hors de question de répéter les mêmes manipulations sur des centaines de machines. Heureusement pour ce faire, il existe des outils tels que Puppet ou Chef qui permettent à travers un langage de personnaliser les configurations par machine, en évitant autant que possible de se répéter tant que ce n’est pas nécessaire.
Ces outils permettent par ailleurs bien souvent aussi d’installer automatiquement les livrables, ce qui peut permettre d’économiser un temps précieux à faire des choses plus intéressantes.
Gestion des bases de données
Une problématique qui revient également souvent est la gestion des bases de données. En effet là encore il faut pouvoir versionner les changements opérés de façon à pouvoir monter si besoin une nouvelle base sur un nouvel environnement sans avoir besoin d’y passer des semaines. Une bonne stratégie pour y arriver consiste tout simplement à créer un fichier SQL par mise à jour de la base de données et le versionner, et à garder dans le schéma une table contenant les informations de version. Un très bon outil implémentant cette stratégie est Flyway.
Stratégie de déploiement : le blue-green deployment
Parmi les stratégies les plus intéressantes on trouve ce qu’on appelle le « blue-green déployment ». Le concept est en fait assez simple : il s’agit d’avoir deux chaînes de serveurs identiques, on appellera la première la bleue, et la deuxième la verte, derrière un load balancer. L’idée est que lors d’une mise en prod une des chaînes doit être à l’état de la version précédente, tandis que l’autre doit rester à la version précédente. Dès lors on peut installer tranquillement la nouvelle version sur une chaîne, alors que la production tourne sur l’autre, et la mise en production de la nouvelle version est tout simplement une bascule du load balancer.
Les avantages de cette approche sont les suivantes :
- Dès lors que la nouvelle version est validée, ce qui se fait en général en moins d’une semaine, la chaîne inutilisée peut servir de pré-production pour la version à venir.
- En cas de problème majeur il est très facile de revenir à l’état antérieur, puisqu’il suffit de faire une bascule.
La gestion de la base de données
Une problématique qui se pose concerne la base de données, puisqu’il faut éviter de perdre des données en cas de retour à l’état antérieur, tout en évitant aussi le coût des migrations de base d’un serveur à l’autre qui peut être très important.
Une manière de s’en sortir consiste en fait à utiliser la même base de données pour les deux chaînes. Cela implique néanmoins que la base de données soit compatible avec la version N et la version N – 1, puisqu’une bascule peut être faite à tout moment. Dès lors cela nécessite que pour passer de la version N – 1 à la version N, seuls des ajouts de champs ont été faits dans la base. Aussi, les champs, plus gérés dans la version N, seront supprimés une fois que la version N – 1 aura été supprimée du serveur.
Le mot de la fin
Comme dans tout le reste de la stratégie devops, l’idée est que si on doit avoir mal, autant le faire souvent pour ne pas avoir beaucoup mal à chaque fois. En l’occurrence il vaut mieux faire des déploiements fréquents, plutôt que de passer des semaines à fixer un déploiement majeur qui contiendra des dizaines de nouvelles fonctionnalités dont on aura depuis longtemps oublié le fonctionnement et les tenants et aboutissants. De même pour les tests qui doivent être automatisés et le reste. Bref faites vous mal souvent, mais pas beaucoup à chaque fois. 😀
Débloque les + belles offres tech en 10 mins
Cet article vous a plu ? Vous aimerez sûrement aussi :
Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.
Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.
