La conteneurisation
En tant qu’administrateur nous faisons face à l’émergence de nouveau outil favorisant le maintien en condition opérationnel (MCO) des systèmes d’information. Parmi ces outils, la conteneurisation, et plus spécifiquement Docker, peut s’avérée être un complément judicieux à la virtualisation, offrant une flexibilité accrue aux systèmes d’information. Avant de commencer les différentes mises en pratiques, examinons ce qu’est la conteneurisation.
Les architectures informatiques
Pour vraiment saisir les avantages de la conteneurisation, il est essentiel de prendre en compte l’évolution au fil des années des architectures logicielles.
Application monolithique
Cela nous amène à revisiter le concept des applications monolithiques. Dans ce modèle d’architecture, tous les éléments logiciels sont conçus au sein d’une même plateforme unifiée.
Cependant, ce schéma ne favorise pas la modularité, c’est-à-dire la capacité d’apporter de la souplesse au sein du système d’information. Par conséquent, ces applications fonctionnent avec leurs propres bases de données, qui ne sont pas partagées avec d’autres applications. De plus, leur méthode d’authentification interne n’est pas compatible avec les technologies de type SSO (Single Sign-On).
Au fil du temps, les entreprises ont progressivement adopté un nombre croissant d’applications pour automatiser leurs processus métiers. Chaque service au sein de l’entreprise disposait de sa propre application pour gérer ses processus spécifiques. Toutefois, le besoin d’harmoniser certaines données s’est rapidement fait sentir. Par exemple, les informations relatives à l’identité d’un employé étaient pertinentes à la fois pour le service de paie et le service des ressources humaines en charge de la gestion de carrière. Dans le cadre d’une architecture monolithique, chaque service devait créer sa propre fiche employée dans son propre logiciel, entraînant non seulement des risques d’erreurs, mais également des pertes de temps considérables.
Les architectures SOA
Les architectures monolithiques ont évolué vers les architectures SOA, centrées sur les services. L’architecture SOA considère les applications et bases de données comme des services dans un système d’information. Prenons l’exemple des services de paie et de ressources humaines. Les données saisies dans le logiciel RH deviennent accessibles à l’application de gestion des paies. Cette architecture divise le code en plusieurs blocs indépendants appelés services. Une application devient alors un réseau de services interconnectés.
Ce type d’architecture nous permet de gérer les aspects applicatifs. Cependant, l’inconvénient majeur de ce modèle réside dans la nature des services. Si une application est une composition de services, ces services forment un bloc solide et immuable.
Architecture microservice
LLa transformation du bloc solide en un bloc malléable accroît la flexibilité. Chaque service de l’application devient modifiable indépendamment. Une modification d’un service n’impacte pas les autres services, sauf en cas de dépendance directe.
Lorsqu’une mise à jour de l’authentification est effectuée, les données protégées deviennent alors inaccessibles. En revanche, les données libres d’authentification restent quant à elles disponibles. Par ailleurs, modifier le système d’impression n’affecte donc pas l’utilisation globale de l’application
Isolation des processus sous Linux
Pour créer une telle architecture, nous aurons besoin d’un environnement capable de générer des services autonomes et de les regrouper.
Les namespaces
En 2002, une fonctionnalité permettant l’isolation des processus a été introduite dans le noyau Linux (version 2.4.19). Cette fonctionnalité, appelée « Namespaces », autorise des processus à utiliser des ressources qui sont déjà utilisées par d’autres ressources.
Les systèmes partagent désormais des ressources comme une carte réseau, grâce à la virtualisation. Ainsi, la machine physique et les hyperviseurs utilisent simultanément cette ressource. Pendant ce temps, le processus maintient une isolation adéquate entre les utilisateurs de la ressource.
Les Cgroups
En plus de la fonctionnalité des Namespaces, une autre capacité a été introduite : celle de regrouper et contrôler des fonctionnalités du noyau, connue sous le nom de cgroups (control group). À l’intérieur d’un groupe sous notre contrôle, il est possible d’agréger une portion de nos ressources. Par exemple, cela peut consister en l’allocation de 25 % de notre CPU, 25 % de notre mémoire RAM et 10 % de notre espace disque.
Les ressources peuvent être gérées collectivement. Les fonctionnalités des Namespaces et des Cgroups peuvent collaborer de concert. Le projet qui a fusionné ces deux capacités au sein du noyau est le projet LinuX Container (LXC), lancé en 2007 qui était les prémisses de la conteneurisation. Comme son nom l’indique, ce projet vise à créer des conteneurs.
La difficulté rencontrée avec ce projet réside dans la question de la portabilité. Comme nous l’avons expliqué précédemment, les fonctionnalités des cgroups et des Namespaces sont intégrées au sein du noyau. Ainsi, si nous transférions le conteneur vers une autre machine, des effets indésirables pourraient apparaître. Ces défis peuvent être résolus en ajoutant une couche supplémentaire à LXC, afin de gérer les disparités entre la machine qui va conteneurisé et celle qui l’exécutera. Cette surcouche a été introduite en tant que projet open source en 2013 sous le nom de Docker.
Conteneurisation avec Docker
Docker est multiplateforme, c’est-à-dire qu’il peut être installer sur Windows, Linux ou MacOS. Pour illustrer nos exemples, nous installerons docker sur une distribution Alamlinux. Docker se décline en deux versions :
- Docker-CE (Community Edition).
- Docker-EE (Enterprise Edition)
Les fonctionnalités en termes de conteneurisation proposées par les deux éditions sont identiques en tout point. La différence se base au niveau du support proposé par Docker. La version Docker-CE qui est une version gratuite propose un support via la communauté des utilisateurs alors que la version Docker EE avec un support payant et proposé d’autres services. Il existe trois offres payantes pour Docker-EE :
- De base: vous obtenez la plate-forme Docker pour une infrastructure certifiée, ainsi que le support de Docker Inc. Vous avez également accès aux conteneurs Docker certifiés et aux plugins Docker depuis Docker Store.
- Standard: Comprend les mêmes fonctionnalités que le niveau de base, mais avec une gestion avancée des images et des conteneurs, une intégration utilisateur LDAP / AD et un contrôle d’accès basé sur les rôles.
- Avancé: Comprend une analyse de sécurité Docker supplémentaire et une surveillance continue des vulnérabilités.
La tarification générale de chaque niveau est généralement basée sur