Outils pour utilisateurs

Outils du site


docker_integration

Intégration de docker ?

Avant que le serveur telnet ne tombe et que l'on soit obligé d'improviser une migration rapide, il était prévu d'utiliser docker pour accueillir chacune des applis / services de telnet. Les buts :

  • Rendre les migrations futures plus faciles
  • Mieux cloisonner/organiser le serveur
  • Permettre à n'importe qui d'emporter avec soi une copie d'une appli (karibou ?) pour faire du dev dans son coin

Ça, c'est le discours de docker. Mais dans la pratique cela n'est pas si simple. Au contraire, il devient vite extrêmement complexe d'administrer et de maintenir une architecture dockerisée.

Si quelqu'un compte un jour intégrer docker sur le serveur, il trouvera ci-dessous une liste non exhaustive des difficultés que j'ai eu à l'utiliser. Avant de lire la suite il est préférable de savoir ce qu'est docker et de connaître son fonctionnement de base.

J'ai écrit cette partie après avoir

aptitude purge docker.io

et je regrette de ne pas avoir fait des copies des sorties des commandes dont je parle plus bas pour illustrer mes propos.

Persistance des données

Quelque chose que j'ai eu du mal à comprendre avec docker, c'est l'éphémérité des données.

Il y a des images, qui correspondent à des classes pour faire un parallèle avec la programmation orientée objet. Si on veut créer une “machine virtuelle”, un conteneur dans le jargon, on instancie une image. Cela implique que si le contenu de du conteneur évolue (base de données par exemple), l'image (la classe) ne bouge pas. Mais si on veut que la nouvelle version devienne le modèle de référence, il faut créer une nouvelle image à partir du conteneur, avec un nouveau nom.

Si on ne fait que des petites modifs de temps en temps ça peut aller. Mais en général sur un serveur où il y a du dev et où on cherche des solutions pour que ça fonctionne (pendant la migration), cet aller-retour entre l'image et le conteneur devient vite ingérable (on ne sait plus quelle version apporte quoi).

Heureusement, docker permet de lier une partition du système avec une partition du conteneur. Si on a une partie d'une appli qui doit rester fixe, c'est très intéressant parce que même si le conteneur est supprimé les données sont toujours sur le système : pas besoin des allers-retours ci-dessus. J'avais prévu d'utiliser cette feature pour que les comptes ftp des clubs (sur le système) donnent directement accès aux données utilisées par le conteneur.

Maintenance des images

La communauté recommande de fonctionner avec des dockerfiles. Un dockerfile permet de générer une image à partir d'une image source (disons debian jessie), sur laquelle on va exécuter des commandes (apt-get install php) pour obtenir une image de base. Grossièrement c'est ça. L'idée derrière c'est que les images peuvent être backupée très facilement, puisqu'on est en mesure de la régénérer à partir d'un fichier. Je trouve l'idée juste géniale.

Mais dans la pratique, quand il faut mettre en place ce fichier image, et s'il est amené à évoluer, on perd énormément de temps. De manière générale, déboguer des images/conteneurs n'est pas du tout pratique. On est tout le temps obligé de recompiler, obligé d'installer des paquets, d' apt-get update. Certains utilitaires de base ne sont pas installés sur la debian par défaut comme netstat ou un éditeur de texte décent.

Dans la partie précédente, j'ai parlé de la persistance des données. Pour être plus précis, un conteneur peut être running ou stopped. Quand on l'arrête, il est toujours disponible en mémoire (comme une vm éteinte qui conserve son état). Si on lance plusieurs instances en faisant à chaque fois des petites modifs de test, l'historique des conteneurs en activité grossit très rapidement et on oublie vite ce qu'il y avait dessus (même en essayant de s'organiser).

Il y a une option quand on lance un conteneur pour le supprimer dès qu'il sera stopped, mais elle n'est pas disponible quand le conteneur est lancé en mode daemon, soit 90% des conteneurs qui sont lancés. Coïncidence ? J'ai parfois des doutes sur la volonté de l'équipe docker de faire un outil ergonomique.

Que mettre dans les conteneurs ?

Si ce ne sont pas les données, ce sont les services. Un php/python + un apache + un mysql ? Pour rappel le but est de rendre chaque appli exportable facilement.

Un apache par docker [+ un serveur web sur le système qui route les requêtes], c'est bourrin, surtout quand on se dit qu'on pourrait faire un seul apache et faire communiquer le langage du conteneur en mode fastcgi (http://fr.wikipedia.org/wiki/FastCGI).

Autre argument contre le fait de stocker un apache dans chaque conteneur, c'est la persistance de la configuration. Si on fait des modifs complexes sur le vhost qu'on veut retrouver plus tard, on est tenté d'utiliser une partition système (comme pour les données). Mais là ça devient moche, parce que s'il faut lier la configuration de chaque service avec une partition système différente, on va se retrouver avec des liens dans tous les sens.

Le cas du mysql dans chaque docker est discutable, car certaines applis veulent utiliser les mêmes bases (karibou). Ce qui est recommandé par la communauté, c'est de faire un conteneur séparé et de lier les deux (dire au premier de nater son port 3306 sur celui du deuxième). Encore une fois, on a besoin d'une partition système pour ne pas perdre ses bases. Et d'encore une autre pour la configuration de mysql.

Certains le savent déjà : par défaut mysql ne permet pas aux hôtes externes de s'y connecter. Or mysql ne permet pas de trier les hôtes s'y connectant : c'est soit un hôte défini soit tout le monde. Donc si on veut un mysql global à toutes les applis, il faut aussi rajouter une règle de pare-feu sur le système qui empêche l'extérieur de se connecter sur le port 3306 pour maintenir cette sécurité.

Ça commence à faire beaucoup de complexité juste pour lier deux conteneurs. Imaginons maintenant qu'il faille en lier 3 ou 4, ça fait énormément d'arguments à se souvenir pour la commande qui instancie le conteneur… Il faut presque documenter ces lignes de commandes.

Et même si on arrive à tout lier correctement, on pleure le jour où on veut changer un des conteneurs d'un cluster. Il ne me semble pas qu'il y ait d'autres manières de faire que de relancer chaque conteneur un par un en changeant les arguments (et la doc), et donc de faire une interruption de service.

Pour revenir à la problématique initiale de savoir ce qu'on met dans un conteneur, si on ne veut ni code, ni apache, ni mysql, ni configuration, il ne reste donc plus que php. S'il est vrai qu'on gagne en terme de sécurité (contexte d'exécution), on perd probablement en performance (avoir plusieurs instances de php qui tournent en même temps). Au départ, on privilégiait docker sur php-fpm alors que finalement cette solution est beaucoup plus simple à utiliser.

Bonus : intrusion de docker sur le système

Quand on a de nombreux conteneurs sur un même serveur, les commandes :

df -h

et

netstat -tlnp

crachent des résultats immondes. Il faut compter dans les une ligne de plus par conteneur, et ces gros pâtés n'apportent pas vraiment d'information pertinente.

Docker créé de nombreuses règles iptables pour organiser le réseau des conteneurs. C'est a priori légitime, mais si on a déjà un firewall sur le système on ne peut plus le réinitialiser à coup de :

iptables -F
iptables -X

Conclusion

Je ne comprends pas la raison pour laquelle docker a connu un tel succès et pourquoi autant d'articles en ont vanté les mérites. Après avoir réfléchi à comment il pourrait être utile à telnet, je n'ai pas trouvé de réponse à cette question. Plus je lisais des hacks proposés par la communauté sur stackoverflow ou slideshare, moins je voyais d'alternatives à cette gestion complexe d'un parc applicatif tel que je l'ai décrite.

Je me suis rarement posé autant de questions sur “pourquoi docker fait les choses comme ça ?”, parce qu'on ne dirait pas que cette solution rend plus facile la vie des sysadmins. Il facilite probablement les migrations, mais certainement pas l'administration. Et quitte à choisir, je préfère créer un compte utilisateur et modifier de la conf en 2 minutes plutôt qu'en 40, même si pour les migrations ça implique de se prendre la tête une fois tous les 3 ans.

Quoi qu'il en soit, il est possible que docker soit intéressant dans certains cadres d'utilisation (scripting ?), mais pas dans le notre. À moins que je ne sache pas utiliser docker et que je me sois trompé sur certains points (je l'espère pour eux). Mais si c'est le cas, je veux bien le détail de l'explication.

docker_integration.txt · Dernière modification: 2017/10/10 11:30 par deldel