Quand utiliser Docker en production ?

Pour votre confort et votre sécurité, nous avons nettoyé le transcript des hésitations, répétitions et autres touches humoristiques qui habillent naturellement nos webinaires, pour ne conserver que la substantifique moelle du message que nous souhaitons transmettre.

Cédric : Le sujet du jour, c’est Docker en production.

Et pour être honnête, reparler de ce sujet nous travaille depuis longtemps.

Chez Berstech, notre approche est rationnelle et minimaliste : la VM reste notre unité de travail de référence.

On a d’ailleurs écrit il y a longtemps un article expliquant pourquoi on ne recommande pas Docker de façon systématique.

Aujourd’hui, on vous dit quand on le recommande et surtout, ce qu’on met en place pour bien faire les choses.

Quand utiliser Docker ?

Cédric : On utilise Docker quand il le faut vraiment. Le premier cas, c’est le legacy ou l’éditeur qui l’exige.

Olivier : Oui, par exemple, on a déjà dû faire tourner une application sous PHP 5 impossible de ressortir une vieille Debian, donc on l’a dockerisée. C’était la solution raisonnable.

L’autre cas typique, c’est GitLab. GitLab et Docker s’associent bien pour une raison précise : GitLab est une grosse bête, très fragile, avec ses propres règles d’administration qu’on ne trouve pas toujours à notre goût.

Plutôt que de modifier son environnement et prendre des risques, on lui laisse son conteneur et on construit autour. Ça nous permet d’utiliser le produit dans l’environnement qu’il attend, avec un maximum de chances que tout se passe bien.

Quand ne pas utiliser Docker ?

Olivier : Ce qui est encore plus important, c’est de savoir quand ne pas l’utiliser.

Prenons une architecture derrière et une base de données.

Cédric : Pour la base de données on ne l’utilise pas, c’est catégorique ?

Olivier : Absolument. Ne mettez pas votre base de données dans un Docker, sauf en développement.

La base de données, c’est un composant à la fois massif et subtil, qui se comporte comme un hippopotame en furie quand quelque chose se passe mal.

La plupart des incidents vraiment stressants ont lieu au niveau de la base de données.

Si vous rajoutez une couche Docker entre le disque et le moteur SQL, vous ouvrez la porte à des problèmes rares, certes, mais potentiellement catastrophiques corruption de données, arrêts brutaux, redémarrages inattendus. Et comme toutes vos données s’y trouvent, il n’y a aucun bénéfice à prendre ce risque.

Cédric : Tu l’as pourtant fait toi-même, récemment ?

Olivier : Oui, il y a deux mois, sur une durée de 15 jours, le temps de passer d’une version de PostgreSQL à une autre. On avait un problème précis, une solution temporaire et une deadline claire. On avait prévenu tous les clients. C’était une exception justifiée et limitée dans le temps pas une pratique générale.

Les règles à respecter quand Docker est en prod

Olivier : Premier point : un Docker ne doit jamais prendre les flux extérieurs directement. Il doit toujours y avoir un proxy devant HAProxy, Apache, Nginx géré dans les règles de l’art par l’équipe d’administration. C’est ce composant qui gère les flux entrants, qui est mis à jour régulièrement et dont la configuration est stable et réfléchie. Toute modification passe par un processus contrôlé.

Cédric : Et pour les accès ?

Olivier : Deuxième point crucial : ne donnez jamais l’accès au socket Docker (docker.sock) à quelqu’un qui n’y a pas droit. Celui qui a accès au démon Docker est root sur la machine on a même un webinaire qui le démontre.

Les développeurs peuvent avoir accès à l’intérieur de leurs conteneurs, mais la machine hôte, les ports ouverts, la gestion réseau c’est du ressort de l’équipe d’adminsys.

Et si votre Docker est exposé directement lors d’un incident, vous aurez du mal à isoler ce qui pose problème et toute intervention peut avoir des conséquences en cascade.

Cédric : D’où l’intérêt du mode rootless ?

Olivier : Exactement. Docker en mode rootless, c’est la meilleure configuration en production. Ça oblige à ranger les choses proprement dès le départ et c’est douloureux quand on n’y est pas habitué, parce qu’on perd certains réflexes acquis avec les droits root.

Mais c’est exactement le but. Podman offre les mêmes garanties de ce point de vue. Pour nous, Docker rootless ou podman sont quasiment interchangeables pour un usage en production.

Les sujets souvent oubliés

Cédric : Il y a deux autres points qu’on néglige souvent : le monitoring et les logs

Olivier : D’abord, le monitoring : on ne peut pas se contenter de surveiller l’hôte. Il faut monitorer les conteneurs individuellement leur nombre de processus, leur état, leurs ressources.

Ensuite, les logs. Beaucoup de conteneurs logguent dans tous les sens, y compris sur la sortie standard. Faites un docker logs sur un GitLab qui tourne depuis dix ans c’est vertigineux.

Il faut avoir une stratégie de gestion des logs dès le départ, sinon vous perdez la visibilité sur ce qui se passe en prod.

Les images Docker

Cédric : Chez Berstech on va plus loin sur ce point.

Olivier : Oui. On n’autorise pas n’importe quelle image en production.

Nos images sont des images Debian durcies, retravaillées, maintenues et signées par notre équipe.

Ça nous permet de savoir exactement ce qu’il y a dedans, d’appliquer rapidement les correctifs de sécurité et d’aider nos clients à diagnostiquer des incidents. La semaine dernière par exemple, un client avait un timeout 504.

Parce qu’il utilisait nos images, on a pu identifier très rapidement que le problème venait d’une valeur mal configurée dans Nginx et régler ça en quelques minutes plutôt que de se renvoyer la balle.

La question des backups

Cédric : Un dernier point souvent sous-estimé : la sauvegarde.

Olivier : En production, on sauvegarde les données c’est évident.

Mais avec Docker, il faut aussi pouvoir reconstruire ses images. On a croisé récemment un Dockerfile de cinq ans dont certaines dépendances n’existent plus en ligne des versions supprimées pour des raisons de sécurité. Si vous ne pouvez pas rebuilder votre image, conservez-la précieusement. Et si vous ne pouvez ni la rebuilder ni expliquer pourquoi elle est en prod, c’est un vrai problème.

En résumé

Pour résumer notre position : Docker est un outil puissant, bien conçu, qui fonctionne très bien. Mais c’est une pelleteuse, pas un marteau. Il faut l’utiliser pour ce qu’il fait vraiment bien : encapsuler un logiciel éditeur complexe, isoler un environnement, standardiser un déploiement et le cadrer avec une chaîne de sécurité solide au-dessus.

Et ne jamais oublier que la prod, ce n’est pas le jour de la mise en ligne. C’est tout ce qui suit et notamment les incidents. C’est pour ça que chaque décision d’architecture doit être pensée en mode “qu’est-ce qui se passe quand ça casse à 3h du matin ?”