Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

eZHumanCAPTCHACode reload
retour

Les conteneurs et les machines virtuelles

Les conteneurs et les machines virtuelles

Livrer des applications est un sujet à part entière, mais l’environnement de développement est un thème primordial.

Prenons un projet web développé en PHP. Traditionnellement le déploiement de ce type d’application était réalisé sur des serveurs physiques dédiés sur lesquels tourne un service HTTP. Que ce soit Apache httpd, Apache Tomcat, ou encore Nginx, les sources du site étaient déposées sur le serveur, dans un répertoire précis. Le moteur de base de données était bien souvent installé sur le même serveur, parfois sur une autre machine. Le coût d’exploitation et la complexité d’infrastructure était une contrainte
pour le développeur qui devait gérer différentes con figurations applicatives, et pour les exploitants qui devaient s’assurer de la bonne gestion du système et du réseau.

Les hyperviseurs sont essentiels. Une machine nue est aujourd’hui capable de superviser des dizaines de machines virtuelles, isolant ainsi les déploiements sur des environnements dédiés. Il existe d’excellents hyperviseurs en open source comme KVM ou Xen, qui une fois orchestrés par OpenStack ou Mesos sont capable de rivaliser avec des VMWare, Azure, AWS... Bien que le serveur soit virtualisé, le principe reste équivalent à celui d’un serveur dédié. L’autre revers est que pour virtualiser un environnement complet (un système d’exploitation installé et viable), le serveur doit être capable de supporter la charge de son OS hôte ainsi que les OS invités, sans compter l’émulation du matériel (CPU, mémoire, carte vidéo...) et la couche réseau associée. En d’autres termes, les ressources nécessaires pour exécuter une Machine Virtuelle sont importantes.

Du point de vue développeur, son poste de développement est largement capable de supporter une machine virtuelle pour travailler avec un environnement proche de celui de production. C’est sans compter sur l’émergence des conteneurs applicatifs qui a relativement modifié le visage des principes de déploiement et de services.
Plutôt que de virtualiser une machine complète, il n’est nécessaire que de créer un environnement d’exécution dans lequel un service est démarré pour fournir l’application. Avant d’aller plus loin sur la conteneurisation d’application, il faut rappeler que la technique d’isolation de processus dans un environnement fermé existe depuis des années : le "chroot" permettait déjà de réduire l’impact d’une installation de service dans un répertoire dédié et de plus ou moins l’isoler du reste de l’OS hôte. Le but des conteneurs applicatifs est donc d’isoler un processus dans un système de fichiers à part entière - il n’est plus question de simuler le matériel et les services d’initialisation du système d’exploitation sont ignorés. Seul le strict nécessaire réside dans le conteneur, à savoir l’application cible.

De fait, une solution de conteneur telle que OpenVZ, nspawn ou encore LXC peut tout à fait faire office de conteneur applicatif. Il est en effet possible de ne pas démarrer un OS via un "init" et donc de reproduire le comportement que nous connaissons avec Docker ou Rkt. Cependant, dans une approche "micro-service", nous seront plutôt voué à parlé de conteneurs applicatifs, et plus particulièrement de Docker.

Le revers de la médaille est que la garantie que le développement fonctionne sur l’environnement de production repose sur le fait que les serveurs de production soient en mesure de faire tourner des conteneurs. Si le système n’utilise pas de gestion de conteneurs, l’application sera tout de même capable de tourner et de répondre, mais le paramétrage s’éloigne de celui utilisé par les développeurs.

Certaines solutions de conteneur permettent un démarrage "quasi-complet", par exemple LXC va effectuer une séquence de boot et permet de faire tourner l’ensemble des services nécessaires à une application (par exemple une base de données et le serveur WEB) - mais d’autres, comme Docker demandent à ne faire tourner qu’un seul service. Bien que la mauvaise pratique d’utiliser un processus englobant les services tels que "supervisor" est souvent rencontrée, il est fortement recommandé d’utiliser un conteneur par service et de lier les conteneurs entre eux. Cette opération étant simplifiée par Docker-compose par exemple mais aussi dans les solutions de clusterisation tels que
Kubernetes .

Nous approchons donc d’un mode de fonctionnement applicatif dont le terme est aujourd’hui bien connu :le micro-service .

Notons bien l’un des intérêts qui fait souvent office de fer de lance : les conteneurs peuvent être exactement identiques à ceux utilisés en production . Moyennant, bien entendu, un travail en amont de la part des développeurs et des agents de production. Nous sommes donc bel et bien dans le monde du DevOps , une fois de plus.
Le principe de micro-service permet aussi de soulager les environnements car il n’est plus nécessaire de démarrer un OS complet (voir figures 2.3 et 2.4). Cela simplifie grandement le paramétrage de l’environnement de travail et sa réutilisation, nous sommes donc aussi dans une logique d’industrialisation . Aussi, il sera aisé de tester plusieurs versions de services puisque ce dernier est un simple conteneur éphémère.

À ce jour, Docker est nativement supporté par Linux et OSX est en passe de permettre aussi son exécution. Windows est en reste à cette heure, mais Microsoft défend sa solution Azure et intègre déjà des solutions pour réussir à faire tourner Docker sur sa plateforme.

Sur un environnement de production, nous pouvons alors imaginer plusieurs manières d’exploiter une application :

  • les applications sont déployées sur une VM proche de celle des développeurs
  • les conteneurs sont déployés sur des environnements préparés
  • un gestionnaire de conteneur tels que Kubernetes peut aussi être utilisé.

Et pour nous aider, nous pouvons compter sur OpenShift, OpenStack, Mesos, et tout un panel d’autres solutions qui ont émergé ces dernières années.
Pour faire simple : la production et le développement l’informatique évoluent dans le même sens - c’est la clef du paradigme de DevOps.