Docker : ce que cela change pour vos infrastructures (Partie 1)

Docker : ce que cela change pour vos infrastructures (Partie 1)

Vous en avez forcément entendu parler. Il y a quatre ans, de jeunes diplômés de l’école Epitech secouaient l’IT mondiale avec leur techno de containers, baptisée Docker. Si le concept existait déjà depuis longtemps, cette fois ces containers permettaient d’aller plus vite, plus simplement. A l’heure où il fallait réinventer l’agilité de son IT, la techno arrivait au bon moment. En peu de temps, Docker a connu un succès fulgurant.

Il nous semblait donc important d’aborder ce sujet sur ce blog, avec une série d’articles pour mieux appréhender cette nouvelle approche : quel impact sur les infras, la sécurité, le stockage…Nous vous livrons ici une première partie qui pose les bases de Docker et des containers.

Les containers, incontournables sur fond de transformation digitale

Aujourd’hui c’est une évidence : il faut containeriser ses infras. Pourquoi ? Parce que le container est l’un des piliers pour réussir sa transformation digitale, l’outil indispensable pour assurer l’innovation nécessaire aux entreprises. Une techno qui s’inscrit dans la mouvance Devops, où il faut penser « service continu » pour les applications. Et une techno qui sait aussi tirer parti des bénéfices qu’apporte le Cloud aujourd’hui.

Où l’on pense microservices

Il y a en effet une évolution au niveau des architectures applicatives. On parle de microservices : l’application est éclatée en plusieurs petits services, et peut ainsi évoluer plus facilement. Par exemple, il est encore fréquent aujourd’hui qu’une application bancaire se stoppe parfois quelques heures pour raison de maintenance. Avec un micro-service, il devient possible de mettre à jour en continu, et ajouter des éléments sans impacter l’application de base.

L’idée est bonne, mais incompatible avec les infras actuelles : impossible de mettre chaque micro-service, en général très éclaté, dans une machine virtuelle sans faire exploser les coûts. Le container vient résoudre cette problématique.

Container versus machine virtuelle

Vous le savez, une machine virtuelle imite un serveur. Un serveur virtualisé contient un OS complet avec ses pilotes, bibliothèques et application. Chaque machine virtuelle a besoin d’un hyperviseur pour tourner, ce dernier d’exécutant sur un OS hôte, qui lui-même fait fonctionner le serveur physique. La virtualisation a fait ses preuves, mais elle consomme beaucoup de mémoire, ce qui limite le nombre de VM prises en charge.

Un container, lui, permet de partager un système d’exploitation hôte unique, avec ses fichiers binaires et pilotes. L’équivalent de l’hyperviseur est assuré par un moteur de containeurisation, comme Docker, qui s’installe par-dessus l’OS hôte. Chaque container ne contient que l’application. On utilise donc un OS hôte pour plusieurs containers. Une approche qui réduit le gaspillage des ressources. En effet, le container, qui n’a plus la charge d’un OS, exige moins de mémoire, et est plus petit et facile à manipuler. De plus Docker permet au serveur d’héberger potentiellement beaucoup plus de conteneurs que de machines virtuelles. On parle d’un facteur de 10 à 100 fois plus d’instances Dockers que de VM sur un serveur.

Une architecture en plusieurs couches

Un environnement Docker est un stack applicatif composé : du moteur Docker, qui porte le rôle de containerisation, du registre Docker et potentiellement d’un orchestrateur de containers.

Chaque image Docker est composé d’un ensemble de librairies OS nécessaires à l’exécution, et d’un ensemble applicatif portant le cas d’usage souhaité.

Ces images sont centralisées et versionnées dans le registry, sorte de dépôt d’image spécifique à Docker et s’appuyant sur un backend de stockage au choix du client. Le registry peut être privé, public ou local, selon le besoin.

Avantages, lors de la mise à jour d’une partie des logiciels, une nouvelle image portant le périmètre applicatif ciblé peut être généré et déployé en remplacement de celle en place.

Enfin, l’orchestrateur, peut être employé pour créer des flux d’orchestration de déploiement d’environnements applicatifs clé en main, reposant sur des containers.

L’orchestrateur gère notamment, la génération d’image, leur déploiement, leur adressage réseaux, et leur positionnement au sein du cluster. Tous ces mécanismes doivent être bien maîtrisés pour réussir le déploiement de containers dans son infra, et leur sécurisation.

 

Les containers doivent-ils remplacer les infras virtualisées ?

Tous nos clients se posent la question : si les containers sont plus « souples » qu’une VM, faut-il se débarrasser de son infra virtualisée ? La réponse est NON. Il ne faut pas choisir entre les infras virtualisées et les containers. Les deux peuvent tout à fait coexister.

Les infrastructures virtualisées bénéficient d’un écosystème fort qui assure la sécurité et la stabilité de l’hyperviseur. Certaines approches préconisent de faire tourner les containers sur un hyperviseur, pour avoir le meilleur des deux mondes. Dans ce contexte, la question de la sécurité des containers devient incontournable : en effet, on ne sécurise pas Docker comme on sécurise habituellement ses infras. Nous reviendrons en détail sur cet aspect dans le prochain billet. Restez connectés !

 

 

About The Author

Fabien Swiergel

Responsable du Pôle Datacenter Automation. Fabien apporte aux clients SCC son expertise dans la cadre de projets d’infrastructures allant jusqu’à la mise en place de Cloud privés ou hybrides.

Recevez par mail les articles et actualités de Au coeur des InfrasJe m'inscris à la Newsletter