La Poste industrialise ses déploiements pour tester plus rapidement ses idées

Le défi de sortir d’une plateforme obsolète

Il y a encore 18 mois, les projets de La Poste étaient surtout freinés par un problème technique. L’inertie et l’obsolescence minaient des plateformes logicielles censées exécuter les nouvelles applications, qu’il s’agisse de d’apps mobiles, de sites web ou autres.

« Tous nos outils étaient de versions repackagées par nous des logiciels du commerce. Parce que nous avions des normes internes très strictes, nous ne déplions jamais les versions originales. Nous personnalisions l’arborescence des fichiers, changions les privilèges. Et nous faisions cela pour tout : Apache, MySQL ».

Ce modèle était si rigide que les évolutions vers les fonctions modernes étaient compliquées. Ce qui a débouché sur deux problèmes : « nos outils étaient de plus en plus obsolètes et nos déploiements de plus en plus longs. Nous pouvions ainsi passer des semaines, voire des mois rien que pour mettre en place l’environnement sur lequel doit s’exécuter une application ».

Pour résoudre cette situation, La Poste commence par se doter d’un Cloud IaaS interne, sur une base de cluster VMware. Celui-ci est opérationnel début 2016.

« L’intérêt de ce Cloud IaaS est de pouvoir faire des snapshots. C’est-à-dire que nous pouvons sauvegarder étape par étape nos environnements applicatifs au fur et à mesure que nous les mettons au point. Ainsi, si un problème survient, nous ne sommes pas obligés de tout recommencer, nous repartons depuis la dernière copie fonctionnelle », raconte Guilhem Vianes.

Mais le IaaS n’est que la structure de base. A ce stade, toute la chaîne de production des applications doit encore se faire à la main avec son lot de manipulations fastidieuses, d’essais et d’erreurs humaines qui freinent toujours la mise en production des nouveaux projets.

Red Hat OpenShift, pour configurer un pipeline de déploiement automatique

Guilhem Vianes et son équipe cherchaient en réalité depuis le milieu de l’année 2015 une solution qui industrialiserait la mise en production des applications de La Poste. Après deux mois de tests des différentes options proposées par le marché, ils arrêtent leur choix sur OpenShift 3 de Red Hat, un environnement qui présente le double avantage d’être bon marché et basé sur des logiciels Open Source, « ce qui nous évite la sensation d’être verrouillés sur un produit ».

A partir de janvier 2016, l’équipe configure trois clusters OpenShift parmi les machines virtuelles du cluster VMware.

Le premier sert juste à tester OpenShift. Le second est le cluster dit de Build, à savoir des containers (exécutés par OpenShift) qui vont servir à exécuter les applications fraichement compilées à des fins de tests. Le troisième est le cluster dit de Run ; il s’agit d’une copie conforme du Cluster de Build, mais les applications qui y sont exécutées sont accessibles aux utilisateurs finaux.

Reste ensuite à configurer le pipeline de développement, à savoir l’enchaînement de commandes qui transforment un code source écrit par un développeur en une application exécutable dans son environnement fonctionnel complet.

Ce travail durera jusqu’en mai 2016. En plus des automatismes inclus dans OpenShift (le déploiement automatique de certains containers selon le type d’applications, toute la procédure de compilation des codes sources jusqu’à leur installation dans un container, etc.), l’équipe de Guilhem Vianes ajoute des procédures qui adaptent cette chaîne de développement aux méthodes d’exploitation de La Poste.

Les outils Open Source qui complètent la solution

« Nous orchestrons ainsi les différentes versions des logiciels avec Jenkins, gérons les codes sources avec Git, vérifions la qualité du code avec les règles automatiques de SonarQube et faisons des tests automatiques des applications au travers d’un navigateur web avec Selenium. Tous ces outils sont des logiciels Open Source qui ne sont pas inclus dans OpenShift », précise Guilhem Vianes.

Est également ajoutée une analyse des fichiers de logs pour surveiller les déploiements. Cela se fait avec le logiciel Elastic Search et les tableaux de bord personnalisables de sa couche graphique Kibana.

« Toute la mise en place a certes été compliquée à faire. Nous y sommes parvenus en fonctionnant en mode agile, avec les équipes de Red Hat qui nous faisaient plancher sur les fonctions successives au moyen de sprints de 15 jours », se souvient le Chef de projet.

Mettre en production en appuyant juste sur un bouton

Au final, la chaîne de production ainsi configurée remplit amplement son office. « Désormais, le chef de projet dépose son code source dans Git, il demande le déploiement via Jenkins sur le cluster de Build et en quelques minutes l’application est prête à être testée par les développeurs, par les gens qui font la recette, puis par la pré-production. Auparavant, faire toutes ces opérations à la main nous prenait une bonne demi-journée et nous coûtait beaucoup de stress ». En l’occurrence, toute l’opération se résume à appuyer sur le bouton qui correspond au bon squelette de déploiement.

Depuis mai 2016, une trentaine d’applications ont ainsi été mises en exploitation sur le Cluster de Run. Outre les nouveaux projets, l’équipe travaille aussi à y porter les applications historiques (130 en tout) afin qu’elles bénéficient d’un redéploiement automatisé qui leur associera des versions d’Apache, PHP et autres MySQL qui ne soient plus obsolètes. « Les versions obsolètes de ces logiciels nous coûtent cher en maintenance. Porter les applications historiques sur le nouveau cluster OpenShift qui met automatiquement à jour les composants fonctionnels, nous permet donc de réaliser des économies », se félicite Guilhem Vianes.

Surtout, comme la chaîne de mise en production s’occupe de tout, il n’est pas nécessaire de réécrire ces applications. « Nous avons juste quelques lignes à changer dans les scripts d’installation et coder des tests de non régression qui garantissent qu’une application est compatible avec les dernières versions des composants. En tout, la migration d’une application historique nous prend désormais 50 jours-homme ».

Le bénéfice de la standardisation en plus

L’objectif de faire disparaître l’inertie est atteint. « Nous avons aujourd’hui divisé par 10 le délai entre une idée et sa mise en production pour les utilisateurs finaux. Dit autrement, cela signifie que nous avons plus de temps pour développer plus d’applications, tester plus d’idées et explorer plus de marchés. Nous sommes devenus beaucoup plus réactifs », se réjouit le chef de projet.

Il constate un autre bénéfice au fait d’avoir utilisé OpenShift : la containerisation des applications.

« La containerisation apporte une couche d’abstraction à nos applications. C’est la promesse que ce que nous déployons aujourd’hui en internet sur notre Cloud IaaS VMware, nous pourrons le déployer demain n’importe où ailleurs, pourquoi pas des chez des prestataires. Nos applications sont devenues portables, standard », applaudit-il.

Il confie d’ailleurs avoir fait son choix pour OpenShift alors qu’il était en version 2, mais ne l’avoir pas déployé avant que la version 3 ne soit disponible. « Nous avons fait cela car nous savions que la version 3 apporterait les containers, en intégrant Docker et l’orchestrateur Kubernetes », glisse-t-il au MagIT.

A l’avenir, justement, Guilhem Vianes utilisera très probablement CloudForms, le logiciel de Red Hat qui permet de déployer des applications de la même manière quelle que soit l’infrastructure sous-jacente.

Il envisage également de déployer le SDS GlusterFS de Red Hat, qui lui permettrait de ne plus stocker les données de ses applications sur des baies de stockage SAN fort coûteuses.