The Doppler Quarterly (FRANÇAIS) Hiver 2016 | Page 42

Démonter les idées préconçues sur Docker Dan Griffith Six idées préconçues à démonter pour prouver qu’un futur mis en conteneurs est plus proche que vous ne le pensez. Les conteneurs Docker ont réussi à décrocher le titre de « technologie la plus en vue de l’année ». Cependant, cet engouement pour les conteneurs Docker n’a pas convaincu l’intégralité de la commu- nauté informatique de leur importance, loin s’en faut. La méfiance envers la séquence typique de surestima- tion due au classement Gartner semble avoir fait passer la discussion à propos des conteneurs de l’étape de la nouveauté technologique à la désillusion, sans passer par les attentes irréalistes. Chaque jour ou presque amène son lot de critiques envers les conte- neurs en général et Docker en particulier. Ces cri- tiques mettent souvent l’accent sur le contraste sup- posé entre le potentiel de la technologie de conteneurs Docker et son manque de maturité et d’expérience pour une utilisation en situation réelle de production. Mon expérience d’ingénierie avec Docker m’a offert une perspective assez différente de l’état actuel et futur des conteneurs. J’admets volontiers que les conteneurs Docker sont une technologie sur laquelle on manque un peu de recul, et que des écarts fonctionnels importants doivent être comblés en mise en réseau, stockage et sécurité pour que les conteneurs deviennent un composant majeur de l’in- frastructure principale. Toutefois, j’avancerais que nous sommes plus proches de l’adoption et de l’utili- sation généralisées des conteneurs que ce qu’on pense, et que l’ubiquité des conteneurs est déjà en marche. Cet exposé met en lumière les idées préconçues les plus fréquentes sur Docker et la mise en conteneurs, pour mieux les démonter. 40 | THE DOPPLER | HIVER 2016 Idée préconçue n°1 : Pour mieux comprendre les conteneurs Docker, il faut les considérer comme de petites machines virtuelles Comme beaucoup de professionnels de l’informatique avec une expérience de virtualisation conséquente, le concept de conteneurs Docker qui ne seraient que des « mini-me » de machines virtuelles (VM) me paraissait une première base logique. L’équivalence entre les conteneurs et les VM est un postulat simple, élégant, facile à comprendre, et totalement erroné. D’ailleurs, les architectes Docker ne manquent jamais de contre- dire cette théorie au cours des sessions de formation de démarrage, en disant franchement que les conte- neurs ne sont pas des VM et ne doivent pas être traités comme telles. Certes, les conteneurs Docker remplis- sent la même fonction que les VM, en proposant un sous-ensemble de ressources de calcul, de stockage, de bibliothèques, ou encore de mise en réseau à un processus d’application. Cependant, des différences importantes existent, à un sujet en particulier. Une VM utilise un système d'exploitation complet qui s’exécute sur une couche de matériel simplifié en tant que logiciel, entièrement provisionnée pour le proces- sus d’application. Un conteneur, en revanche, ne provi- sionne que les ressources du système d'exploitation nécessaires à l’exécution de ses processus d’applica- tion spécifiques. L’installation d’une application dans une VM nécessite de construire et de configurer une instance complète d’une version de système d’ex- ploitation spécifique sur le matériel virtuel fourni par une version d’hyperviseur spécifique. Le provisionne- ment d’une application mise en conteneurs nécessite, en gros, un moteur Docker s’exécutant sur un noyau commun, une image Docker (ensemble d’instructions), et l’accès aux bibliothèques utiles (qui peut être con- struit à la demande).