SIGMA s’est lancé sur la voie de la conteneurisation dès le 2e semestre 2014. Trois ans et demi plus tard, il déploie sa propre plateforme PaaS pour permettre aux équipes métier de ses clients de disposer d’un environnement complet d’intégration et déploiement continus. Récit technique du processus et détail de la réflexion ayant amené à cette innovation.
Historiquement, les équipes d’exploitation ont eu recours à LXC sur Debian pour automatiser le déploiement d’environnements d’exécution d’applications web. Utilisé pour isoler du MySQL ou du Apache/PHP dans le cadre des activités de développement web du Groupe SIGMA, LXC était une couche système. Un « scripting » était nécessaire pour simplifier la mise en œuvre par les administrateurs. Le résultat était plutôt stable mais la méthode restait anecdotique par rapport au reste de l’exploitation traditionnelle.
Dès 2014, un cas client basé sur Docker
En 2014, Docker s’impose de plus en plus chez les développeurs mais peu au niveau des administrateurs système. C’est un outil qui permet de se créer simplement des environnements isolés et duplicables à souhait afin de tester ses développements (généralement sur sa propre machine) ou envisager un début d’intégration continue. Il sert à standardiser la construction d’une image d’application ou d’outil qui est mise en commun entre les développeurs d’une équipe. Au second semestre 2014, à la sortie de la version 1.2 de Docker, SIGMA « infogérance » saisit l’opportunité de répondre à un besoin client en s’appuyant sur cette technologie. L’objet du défi : monter une offre SaaS avec son application. L’idée paraît simple sur le papier mais elle induit plusieurs challenges à relever :
- application mono-tenant (produit distribué en boîte),
- budget très limité par client,
- réactivité attendue pour du « as a Service »,
- simplicité d’évolution des versions applicatives.
L’aspect mono-tenant a été traité en utilisant les conteneurs Docker afin de créer pour chaque client un environnement complet de l’application entre bases et services. L’utilisation de conteneurs a aussi constitué une partie de la réponse à la question budgétaire. En autorisant la localisation de plusieurs environnements sur une même machine physique, le conteneur permet de se passer de la surcouche de virtualisation de l’OS nécessaire avec une solution comme VMWare. Bénéfices additionnels, Docker apporte l’intégration simplifiée dans le provisionnement ainsi que l’optimisation des espaces disques. La réactivité du « as a Service » a été envisagée via la construction d’une interface utilisateur et de workflow de provisionnement, basés sur l’outil OpenSource ProcessMaker. La solution offre un portail qui permet de provisionner automatiquement un environnement applicatif complet pour chaque nouveau client de la solution. Pour que l’éditeur de l’application bénéficie d’un outil simple pour les évolutions applicatives, on associe Docker et ProcessMaker avec un GitLab. Bien sûr il ne faut pas oublier notre rôle d’administrateur et garant du service. Nous avons ainsi outillé la plateforme avec une CMDB spécifique Configuration Management DataBase (iTop), de la supervision (Nagios, Supervisord, influxdb/graphana) et des outils de gestion d’identité (OpenLDAP, Teampass).
Le schéma ci-dessus présente le principe de fonctionnement :
(1a) L’équipe de « dev » pousse son code dans le gestionnaire et (1b) lance la construction de l’image packagée de l’application. L’équipe de « dev » lance le workflow de mise à jour des conteneurs applicatif déployés en production. L’automate prend le code de l’application et du conteneur dans le dépôt (1c) et construit une nouvelle image Docker de l’application (1d). Commandé par l’équipe de « dev », l’automate effectue la mise à jour des différents conteneurs en production (1e). Le distributeur du produit vend le produit à un client et lance (2a) le provisionnement de l’environnement du client. Le moteur de workflow génère le nouveau conteneur associé au client (2b/2c), enregistre les informations de résolution de nom du conteneur (2d) et renseigne les outils de configuration (2e/2f). Le distributeur récupère les comptes de connexion à l’application (3a) et forme les utilisateurs à l’application (3b). Les utilisateurs peuvent se connecter à leur environnement dédié (4b) sur une URL qui leur est propre (4a).
SIGMA réalise le suivi de l’état de santé de la plateforme avec sa suite d’outils de gestion de capacité et de supervision (5b). En se basant sur le référentiel dynamique de conteneurs (5a), la supervision alerte en cas de dysfonctionnement d’un d’entre eux (5c).
Pour faciliter l’adoption de cette philosophie, le « dev » déclenchant ses mises à jour en production, et de la technologie chez les « ops », nous avions préféré à l’époque rester sur un OS Linux standard (Debian) plutôt que de partir sur CoreOS ou RancherOS, encore non matures en 2014. La structure de l’application, le BCase de la solution et l’automatisation réalisée avec ProcessMaker n’ont pas fait ressortir l’intérêt de la mise en œuvre d’un orchestrateur de conteneurs comme Kubernetes.
Au premier semestre 2015, le système rentre en production. Les « ops » commencent à en mesurer l’intérêt mais aussi les limites… la sécurité et la stabilité en particulier. Docker évolue rapidement, nous sommes passé de 1.4 à la conception, la 1.7 au démarrage et la 1.8 moins de 2 mois après. Actuellement nous sommes en version 17.05, un rythme perturbant pour les équipes de production mais nécessaire pour suivre les patchs de sécurité et de stabilité. Aujourd’hui, une cinquantaine de clients finaux sont provisionnés sur la plateforme.
Micro-service accélérateur du besoin de réactivité
En 2016, grâce à la synergie entre ses activités d’Édition et d’Infogérance, SIGMA s’est ensuite lancé dans l’intégration et le déploiement continus d’une application micro-services avec des conteneurs Docker. L’équipe produit, organisée avec des « dev » et des « ops », est partie d’une feuille blanche au niveau de l’architecture technique. Ses contraintes :
- livrer rapidement diverses fonctionnalités pour étoffer une application existante,
- s’assurer que les modules livrés soient évolutifs pour la charge mais aussi le multitenant,
- garantir une empreinte financière minimale de l’architecture,
- respecter les standards de développement SIGMA.
Une architecture applicative à base de micro-services a alors été retenue avec, en composants communs, Service Discovery, Config Server et un bus Redis. Docker est aussi intégré pour favoriser le déploiement de ces composants et les micro-services développés. L’architecture applicative déterminée, il a fallu ensuite mettre en œuvre l’infrastructure pour développer et déployer :
- un Gitlab pour la gestion du code source, des playbook, de la configuration applicative,
- une PIC à base de Jenkins, Ansible et Docker,
- un Registry Docker privée pour la centralisation des images pour les différents environnements,
- une centralisation des traces techniques et applicatives,
- des hôtes Docker pour le build et le run des conteneurs.
Une plateforme PaaS par Sigma, ouverte mais cadrée
En 2017, nous avons accompagné plusieurs clients sur l’implémentation de chaînes d’intégration et déploiements continus pour leurs développements. Les outils sont identiques au cas présenté ci-dessus avec un souhait important de réactivité. L’implémentation et l’administration de ces solutions prennent du temps : à la fin de l’année, le Groupe SIGMA déclenche un projet de mise en œuvre d’un PaaS (Platform as a Service) pour répondre de façon industrialisée à ce type de besoin. L’exercice 2018 est celui du déploiement de la solution PaaS du Groupe SIGMA. A travers ce portail, nous cherchons à proposer aux équipes métier de nos clients la possibilité de disposer d’un environnement complet d’intégration et déploiement continus avec :
- un gestionnaire de sources,
- un outil de gestion de flow d’intégration continue,
- des outils de build, de tests, de qualimétrie de code,
- un catalogue d’images de middleware sures,
- plusieurs environnements d’exécution allant jusqu’à une publication exposée à l’utilisateur final.
Le challenge des équipes d’infogérance est l’intégration des outils d’exploitation. En effet, l’autonomie des équipes produit ne doit pas être le synonyme d’une dégradation des engagements de services vis-à-vis de l’utilisateur final. La maîtrise des sources sur la plateforme et la supervision de l’étendue des déploiements en fonction de niveau de services peuvent s’avérer complexes. L’expérience acquise grâce aux différentes plateformes montées depuis 2015 nous pousse désormais à choisir une solution packagée (RedHat OpenShift Container Plateforme) afin de faciliter l’intégration des différents outils et d’accélérer l’adoption.
Fortes de ce choix, les équipes du Groupe SIGMA vont pouvoir se concentrer sur la maintenance et la mise à jour de cette solution PaaS grâce à :
- la création et le maintien d’un catalogue d’images de middleware afin de garantir la compatibilité « production » de ce que produirons les équipes de développement.
- la sécurisation des applications déployées,
- l’interfaçage avec les outils d’exploitation pour une supervision pertinente des services déployés par les utilisateurs,
- la maîtrise par les clients des déploiements réalisés par les équipes.
À lire également
Pour en savoir plus, consultez nos autres articles, livres blancs et webinaires.
