Bonjour à tous,

Aujourd’hui, cet article me tient particulièrement à cœur pour plusieurs raisons comme vous allez pouvoir le découvrir. C’est en réalité un retour d’expérience personnel suite à une migration sous Docker et n’a pas pour objectif de vous expliquer son fonctionnement (et pas non plus celui de docker-compose). Si ce genre d’articles vous intéresseraient, faîtes le moi savoir :)

Pourquoi “seulement” maintenant ?

Il y a quelques années, Docker était vraiment à la mode avec une hype assez importante dans le petit monde des administrateurs systèmes et des développeurs. Mon esprit de contradiction assez important ainsi que des problèmes de sécurité ont fait qu’il était hors de question pour moi de toucher à cette technologie (bien que non nouvelle car LXC a été créé plusieurs années auparavant). Concernant la sécurité, les problèmes sont toujours d’actualité en 2020 et ne sont pas prêts de disparaître. Je pense notamment à tout ce qui est lié à l’utilisateur root mais c’est un sujet assez vaste où je ne suis pas le plus approprié à l’heure actuelle pour vous en parler.

J’administre un serveur (VPS d’OVH au démarrage, serveur dédié de Kimsufi maintenant) depuis début 2016. On peut dire que c’est relativement récent, mais j’ai pu acquérir pas mal d’expérience, notamment sur mes migrations d’un serveur à un autre (3 migrations en 4 ans au final). Cette activité est quelque-chose qui me plait depuis le début, je n’ai pas compté les heures que j’ai pu y passer, mais ça représente énormément d’heures, c’est certain !

Actuellement, administrer mon serveur est une activité qui me plaît toujours autant, il y a toujours des choses à améliorer et à peaufiner. En revanche, je me dis que je pourrai m’en lasser un jour, je préfère prévenir de cela en amont. De plus, si mon serveur tombe, certes tout est sauvegardé, mais il me faudrait bien 2 jours pour tout réinstaller, cela voudrait dire dédier un week-end entier à cela …

Bref, passer sous Docker me permet de mieux maîtriser les services que j’héberge et que j’utilise et me permets également de pouvoir tout redéployer facilement et sereinement.

Les problématiques les plus importantes

Les différents problèmes que nous allons aborder ici vont contrecarrer directement les arguments pro-Docker du genre:

Le “Ça marche sur mon ordi” c’est le problème principal que règle Docker.

Mais nous verrons qu’il y a des solutions à certains de ces problèmes ! C’est juste que ce genre d’arguments exagèrent selon moi le gain que peut apporter Docker ou équivalent.

Le problème des versions

Comme je le disais dans le précédent paragraphe, un des objectifs principaux de cette migration sous Docker est de pouvoir restaurer mes services en 2 temps 3 mouvements. Or le souci majeur que l’on retrouve avec les images Docker est qu’elles ne sont pas figées dans le temps.

Prenons par exemple le célèbre MariaDB. Je faisais des tests avec l’image officielle ayant la version 10.4.13. Entre 2 machines différentes, je me rends compte que je n’ai pas le même comportement en réalisant exactement les mêmes actions sur la même architecture sur la même distribution …

Au final, une version sous Docker n’est pas l’équivalent d’un tag sous Git, et c’est un gros problème selon moi. En effet, l’image Docker avec la version 10.4.13 correspond au tag 10.4.13 sous Git, c’est assez logique jusque-là. En revanche, il faut rajouter un packaging Docker à ce tag Git, et quand il y a un bug dans ce packaging, il est corrigé et une nouvelle image avec la même version remplace l’ancienne. C’est selon moi une très mauvaise pratique largement répandue dans l’univers Docker, si on change l’image, on devrait passer en 10.4.13-1 par exemple.

Par contre, je peux tout à faire comprendre qu’il existe des images dont les versions évoluent (latest, ou 10.4 qui seraient écrasées par chaque version corrective).

Le problème que ça engendre est simple, quelque chose qui fonctionne à un instant T avec Docker sous une version spécifique ne fonctionnera peut-être plus un an après dans les mêmes conditions avec les mêmes numéros de version.

D’ailleurs, petit aparté, si seulement les versions pouvaient respecter la règle du X.Y.Z avec X pour majeur, Y pour mineur et Z pour correctif, il serait bien plus facile de s’y retrouver (cette remarque n’est pas propre à Docker mais de façon générale).

La solution aux versions

La solution que j’ai adoptée est relativement simple, j’héberge mon propre registre Docker où je stocke toutes les images que j’utilise. Je récupère par exemple l’image de la dernière version de bitwarden_rs et la stocke dans mon registre. Ensuite, dans mes fichiers docker-compose, je n’utilise que des images provenant de mon propre registre.

Je vous expliquerai plus en détail dans un futur article le processus que j’ai mis en place d’un point de vue plus technique.

Le problème des architectures

Mon serveur Kimsufi est sous AMD 64 bits, j’ai un Raspberry-Pi (sous ARM 32 bits) chez moi que j’avais l’habitude (avant ma migration sous Docker) d’utiliser en mode backup quand j’ai un souci avec un service sur le Kimsufi. Le problème que ne résout pas non plus Docker est que les images qui tournent sur une architecture ne fonctionnent pas forcément voire ne sont pas disponibles du tout sur une autre architecture. Un bon exemple pourrait être MariaDB qui n’est pas disponible sous ARM 32 bits.

Pour ce problème, je n’ai pas encore trouvé de solution qui me convienne simplement.

Le problème des mises à jour

Un problème courant que je remarque chez beaucoup d’utilisateurs de Docker est de mettre latest ou équivalent dans des fichiers docker-compose. C’est pratique pour être toujours à jour, mais c’est une horreur pour savoir ce qui tournait à un instant T: on ne maîtrise plus rien.

La solution aux mises à jour

Dans mes fichiers docker-compose, je n’utilise que des images présentes sur mon propre registre. De plus, je n’utilise que des versions figées. L’intérêt est de pouvoir revenir à n’importe quel moment sur la version utilisée à n’importe quel autre moment. En effet, tout est bien sûr sauvegardé et les fichiers docker-compose sont également versionnés sous Git.

Ensuite, pour être au courant des dernières mises à jour, j’ai un flux RSS par logiciel/image Docker que j’utilise. Je répertorie ensuite ces versions dans un tableur pour m’y retrouver simplement et savoir quand je dois mettre à jour certaines images. Par exemple certaines versions correctives ne nécessitent pas toujours une mise à jour immédiate, mais je suis conscient (via mon tableur en couleur) que je ne suis pas sur la dernière version.

Distinction test/production

Bien que je fasse tout ça sur mon temps personnel et majoritairement pour mon usage personnel/familial/proche (j’ai tout de même quelques services accessibles à tous). Il me semble important de bien faire la distinction entre mes serveurs de tests (des machines virtuelles en l’occurrence) et mon serveur de production.

En effet, je dispose donc de mon serveur, une machine Debian 10 AMD 64 bits, ainsi que de plusieurs machines virtuelles dans lesquelles je peux faire mes tests avant de déployer en production. Indispensable si c’était dans un environnement professionnel, c’est également très confortable pour un usage personnel (restreint principalement aux proches).

Ne connaissant pas Docker avant ma migration, une machine virtuelle permet également de pas mal itérer et de découvrir beaucoup de subtilités sans pour autant impacter les services du serveur de production. De plus, les machines de tests et de production ayant les mêmes architectures et caractéristiques, si ça marche sur la machine de test, je n’ai qu’à pousser la configuration sous Git pour la déployer sur le serveur de production, le travail de configuration est déjà fait :)

Conclusion

J’ai migré la majorité de mes services, ça fonctionne vraiment bien. J’ai également pu tester en condition réelle un redéploiement sur un autre serveur, car le dernier que j’avais étais tombé en rade (mort du disque dur).

Pour un passage sous Docker, l’une des principales difficultés rencontrées restera l’appréhension du fonctionnement de Docker et de docker-compose. N’hésitez pas à faire un peu de théorie avant de passer à la pratique (les 2 étant indispensables si vous souhaitez vous en sortir !).

L’article du mois d’août sera la continuité de celui-ci, mais on rentrera cette fois dans la pratique avec des exemples concrets. N’hésitez pas à me faire un retour dans les commentaires si cet article vous a plu (ou non) !