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).