Ad majorem lulzis gloriam
Vomito ergo sum


LXD/LXC, Docker et autres joyeusetés (partie 2 sur beaucoup potentiellement…)

Posted on

Où l'on met beaucoup d'ambiance dans cette boîte jaune…

Docker, c'est bien, mais c'est quand même pas idéal pour tout

En y regardant de plus près, on se rend rapidement compte que Docker a avant tout été imaginé pour faire tourner des applications stateless (sans état), donc des trucs qu'on peut tuer et redémarrer à loisir.

Du coup, pour faire du statefull (base de données, applications persistentes, etc…), c'est déjà nettement plus compliqué (sans être impossible hein, mais disons que ça risque de galérer un peu). L'idée même du conteneur est d'être une structure jetable mais fournie avec les piles (toutes les librairies et une grande partie de la logique de fonctionnement).

Des cas simples…

Il existe donc des cas d'usages finalement relativement simples :

Il y a probablement d'autres cas, mais ça résume, je trouve, assez bien le type d'applications que j'héberge actuellement.

et des cas plus compliqués…

Le souci avec PHP, c'est qu'en gros, ça fait un peu tout ce qui a été cité avant : généralement, il faut une base de données, des fichiers persistents et des fichiers de configuration (en plus de la configuration « système » elle-même). Et l'exécution PHP requiert que le process naisse, interprète, exécute et meurt. Nous sommes loin de l'application dans un seul exécutable…

Du coup, plusieurs approches sont possibles :

(re)faire de l'Apache est honnêtement au-dessus de mes forces, je me suis donc penché sur les méthodes utilisées par quelques très grosses applications PHP : NextCloud et WordPress.

Les approches sont en générales assez similaires :

Dans tous les cas, ça marche très bien pour du lab. Le souci, c'est que ça fait des images relativement lourdes et surtout, c'est intéressant si l'on veut distribuer le logiciel en même temps que son environnement. Si on a déjà le logiciel (avec tout ce qu'il faut dedans), je ne vois pas bien l'intérêt.

D'autant plus qu'en cas de mise à jour, il faut de toutes manières aller écraser l'ensemble du contenu du volume persistent : la détection d'une nouvelle version me semble relativement hasardeuse en fonction des cas et surtout on perd la possibilité de faire un rollback en redémarrant simplement la version précédente du conteneur : vous démarrez NextCloud 13.0.2, un truc merde, vous ne pouvez plus revenir en arrière.

On perd du coup une grande partie de l'intérêt des conteneurs. Pareil pour les base de données : si le schéma ou les données sont touchées par la mise à jour, c'est en fini en cas de problème.

C'est un peu ce qui me fait dire que Docker et PHP ne sont peut-être pas vraiment fait pour s'entendre. Ça pourrait être bien pire, mais c'est loin, très loin d'être idéal.

Retour à la case départ

Cela me ramène donc à mon idée d'origine :

Cette approche permet d'avoir finalement une pile d'exécution PHP assez générique et qui convient à presque tous les usages : les conteneurs permettent d'avoir des environnements d'exécution bien séparés, les base de données sont clairement disjointes, les données persistentes sont bien rangées dans un coin.

Cela pose quand même quelques autres petits inconvénients :

ais au moins, de cette manière, pour faire tourner une application, est relativiment simple. Cela nécessite :

Bref, ça fait quand même beaucoup beaucoup de bordel pour pouvoir faire tourner chaque application. Je suis par contre complètement incapable de dire si c'est plus ou moins efficace en terme de maintenabilité :

Foutaise !

Si tu as bien tout suivi, tu as retenu au moins une chose : tout dockériser, c'est surtout maîtriser l'ensemble de la chaîne de montage de chaque image. Partir du principe que les images toutes faites vont convenir me semble hautement illusoire. Si l'on ne veut pas s'éparpiller, on a grandement intérêt à acquérir les bases logistiques nécessaires pour produire de l'image à tour de bras.

Finalement, peu importe qu'on le déploie avec simplement du Docker, avec du Docker-compose, du Docker Swarm, du Kubernetes, du RancherOS ou n'importe quel autre orchestrateur de conteneurs. Maîtriser le contenu des images est finalement plus important que dans maîtriser le contenant.

Au prochain numéro, on essaiera (tant bien que mal) de voir quelle solution sont adoptables pour faire du reverse-proxy.