Docker s'est imposé au fil des ans comme une solution universelle pour gérer les environnements de développement. Il faut dire que la conteneurisation, popularisée par Docker, présente un avantage substantiel lorsqu'il est question d'installer des environnements et travailler localement.
- Docker est reproductible ;
- Docker offre des silos isolant l'environnement de travail ;
- Docker permet de gérer le système comme une stack de développement.
Mais le passage en production est souvent un exercice complexe : le réseau, les volumes et autres briques viennent complexifier les opérations sur les machines de production.
Avant d'entrer dans le cœur du sujet, nous devons préciser que Docker est une solution tout à fait satisfaisante pour un grand nombre d'entreprises qui souhaitent le déployer et ont les compétences techniques, et les ressources humaines adéquates.
Chez Bearstech nous déployons très régulièrement des conteneurs Docker notamment dans le cadre de notre workflow DevOps. Mais lorsque qu'un projet est prêt pour la production, nous faisons souvent le choix de la VM sans conteneur.
Cet article vise à expliciter cette démarche et communiquer sur notre conception de l'administration système.
Nous avons organisé une série de webinars sur les limites de Docker : Le côté obscur de Docker où nous parlons d'exemples concrets où Docker se comporte d'une drôle de façon.
Les avantages de Docker en production
Docker en production présente des avantages notables que nous reprenons ici pour contextualiser notre perspective, c'est en pleine connaissance de cause que nous faisons le choix de ne pas déployer Docker systématiquement en production et nous devrons donc répondre à ces enjeux lorsque nous présentons notre approche.
- D'abord, il peut permettre dans certaines conditions de densifier l'infrastructure en exploitant un maximum des ressources de la machine hôte.
- Les applications sont isolées dans des containers ce qui offre en principe des niveaux de sécurité supplémentaires.
- Le développement, la pré-production et la production sont identiques et facilement reproductibles.
- L'ensemble des éléments nécessaires pour le fonctionnement des apps peuvent être gérés directement par les développeurs en éditant les Dockerfile et Docker Compose.
Pourquoi nous ne déployons pas Docker en production
Les inconvénients de Docker en production
Abordons d'abord les contraintes de Docker en général, puis nous explorerons ensemble les enjeux de Docker dans notre cas particulier.
Passé un certain nombre de conteneurs déployés, un orchestrateur devient incontournable, ajoutant une couche de complexité supplémentaire.
La gestion du réseau et la communication entre les conteneurs est elle aussi complexe et nécessite l'usage de reverse proxy comme træfik.
L'immense latitude qu'offre Docker présente des risques de sécurité : quand on peut tout faire… on peut aussi faire n'importe quoi. D'autant, qu'il peut devenir très délicat de vérifier et auditer les images Docker. Ceci est d'autant plus délicat que l'on demande à des développeurs de prendre la responsabilité (et donc le savoir-faire) des administrateurs systèmes (par ex. penser à mettre à jour le paquet système SSL en plus de ses propres dépendances applicatives, etc.)
Pour finir, Docker ajoute un grand nombre de couches logicielles supplémentaires qui coûtent en ressources. Par exemple un conteneur Nginx par projet, alors qu'il peut être mutualisé et fournir ainsi une scalabilité bien supérieure (colle : comment "tuner" 100 NGinxes de façon coopérative sur une même VM ?). Pour nombre de projets, Docker coûte plus qu'il apporte.
Docker dans le cadre de nos prestations d'infogérance
Bearstech gère des infrastructures informatiques depuis 2004 et nous travaillons au quotidien pour améliorer la performance, la sécurité et la disponibilité des services de nos clients.
Pour répondre à ces objectifs, nous avons déployé une large expertise de la gestion des VMs. Cela constitue évidemment un biais, mais nous savons bien sûr dépasser nos a priori et proposer les solutions les mieux adaptées à nos clients.
Nous travaillons depuis 2014 avec Docker, notamment dans le cadre de notre Workflow DevOps. Le conteneur n'était alors pas une nouveauté pour nous, puisque nous exploitions LXC depuis 2009 pour des projets spécifiques à haute densité.
Mais pour assurer nos missions dans les meilleurs conditions et à un coût raisonnable, nous faisons le choix de l'homogénéité sur l'ensemble de notre infrastructure, ne dérogeant à cette approche que lorsque le besoin client ne peut pas être satisfait par cette règle générale. Il faut noter, qu'il s'agit de la même raison pour laquelle nous ne déployons pas de bare metal pour nos clients.
Par ailleurs, Docker n'offre pas les garanties satisfaisantes lorsqu'il est question de bases de données :
- En premier lieu, sur les gros volumes de données Docker perd en performance et en maintenabilité. Or, chez Bearstech, nous pensons que la base de données est le componsant le plus sensible des systèmes que nous infogérons.
- Ensuite, les possibilités offertes par Docker permettent de contourner les bonnes pratiques de sécurité auxquelles nous nous astreignons, particulièrement dans un contexte de données sensibles.
Mais quid de la reproductibilité ? Certainement Docker nous permettrait d'accélérer la portabilité des environnements ? Oui, c'est indiscutable, Docker est un avantage sur ce point. C'est d'ailleurs son principal argument. Mais notons que nous avons chez Bearstech une démarche infrastructure as code qui nous offre la flexibilité et l'efficacité nécessaire pour répondre aux attentes spécifiques de chaque client.
De notre point de vue, les apports de Docker en la matière nous imposent des contreparties parfois bien trop coûteuses, pour un objectif déjà rempli par nos solutions de virtualisation (et conteneurisation).
Un autre avantage qui s'accompagne de compromis trop coûteux : la question de l'exploitation optimale des ressources. Nous avons souligné que Docker est très souvent un facteur favorable pour la densification de l'infrastructure.
L'exploitation maximale des ressources déployées est nécessaire aussi bien sur le plan budgétaire, qu'écologique. Mais au final, le choix entre virtualisation et conteneurisation dépend de stratégies plus ou moins établies.
Docker peut ironiquement mener souvent à des infrastructures moins denses : il nous est souvent demandé de déployer des clusters entiers de VMs avec des conteneurs pour une poignée d'applications en production - ce qui se justifie techniquement quand on doit garantir des performances prévisibles -, alors qu'une infrastructure nettement plus simple sans conteneur fournirait un service équivalent avec moins de ressources matérielles.
Chez Bearstech nous avons atteint un niveau de densification de notre infrastructure satisfaisant sans avoir à complexifier nos systèmes et nos procédures en ajoutant une technologie comme Docker, aussi puissante soit-elle. La conteneurisation est redondante avec notre approche de la virtualisation et les contraintes de Docker dépassent largement d'hypothétiques gains.
Docker présente un autre problème majeur dans le cadre de nos prestations : nous l'avons dit, il permet aux développeurs de gérer le système comme du code. Cet avantage, lors de la phase de prototypage devient un écueil pour l'exploitation des services en production.
Nos garanties en tant que prestataire (l'exploitation irréprochable des services, leur sécurité, les temps de réponse de notre d'astreinte) n'est pas compatible avec la possibilité donnée par Docker aux développeurs de gérer ses environnements via les Dockerfiles et Docker Compose.
Nous pourrions mettre en place des protocoles restreignant cette liberté, en imposant des Dockerfiles et des fichiers docker-compose.yml made in Bearstech mais dans cas, les contraintes apportées par cette approche rendent le choix de Docker beaucoup moins pertinent.
Notre rôle en tant qu'infogérant, que ce soit sur notre infrastructure, sur les services d'OVHCloud, de Google ou AWS est d'apporter des garanties quant à la sécurité, la disponibilité et la performance des applications.
Nous pouvons répondre à toutes les attentes de nos clients sans surcouche Docker et en tant qu'acteurs rationnels, nous préférons généralement la simplicité, sauf si la complexité est justifiée par des avantages clairs et mesurables.
