+++ title = "LXD/LXC, Docker et autres joyeusetés (partie 3 sur beaucoup potentiellement…)" date = 2019-06-30 draft = true [taxonomies] tags = [ "docker", "lxc", "système" ] +++ J’aurais aussi pu appeler ça : 1 fille, 2 garçons, 3 possibilités. Ah, c’est donc ça un titre putaclic… Coucou mes rondoudous, c’est Tonton Bingo. Comme tu le sais probablement, ça fait un moment que je ~~tourne en rond~~ réfléchis à comment je vais faire évoluer mon auto-hébergement. Et même si je suis maintenant à peu près persuadé que la meilleure solution est LXC+Ansible, ça n’empêche pas d'étudier les alternatives le plus sérieusement du monde. Et ça permet éventuellement de faire des choses intéressantes. Aujourd'hui donc, je vais m’attaquer à un problème autour duquel je tourne depuis [un bon moment|/post/2018/08/16/LXD/LXC%2C-Docker-et-autres-joyeuset%C3%A9s-%28partie-2-sur-beaucoup-potentiellement%E2%80%A6%29] : quelle est la meilleure solution pour faire tourner des applis PHP dans Docker ? Alors, oui, j’ai déjà abordé le sujet, mais de façon assez générique. Je voulais voir ''concrètement'' comment on pourrait faire en prenant des exemples de la vie réelle. Et même si j’ai déjà dressé la liste des avantages/inconvénients de chaque méthode, je me suis dit que ce serait intéressant de les vérifier « pour de vrai ». Donc, oui, il va y avoir de la redite, mais c’est pour la bonne cause. ## Donc c’est quoi en fait une appli PHP ? Commençons par la base, à savoir comment c’est gaullé une appli PHP. Généralement, il y a un serveur de présentation (dans mon cas, ça va être majoritairement du NginX), un serveur d’exécution (PHP-FPM) et très souvent une base de données (MariaDB, mais ça peut être autre chose). Les configurations à base d’Apache mélangent allègrement présentation et exécution, ce qui n’est franchement pas ma tasse de thé (je trouve ça très crade et les conséquences en terme de sécurité et de performance peuvent réellement être inquiétantes). Mais le principe reste toujours le même : quand le client (le navigateur) demande une page '.php', le serveur de présentation va transmettre le chemin de la page en question à PHP-FPM, qui va exécuté l’ensemble de la pile PHP, puis renvoyer du texte (généralement du HTML ou du JS), après avoir éventuellement interagi avec la base de données. Deux conséquences à cela : 1. NginX n’est pas conscient qu’il y a une base de données (c’est pas son boulot) ; 2. NginX et PHP-FPM doivent avoir les mêmes chemins sur le serveur local pour que cela fonctionne (c’est le chemin qui est transmis par NginX vers PHP-FPM et pas le fichier à exécuter lui-même). Il arrive également assez souvent que l’application PHP ait besoin d’écrire dans des répertoires (fichiers temporaires, compilation de gabarits, téléversement de données, etc…). Voilà, maintenant qu’on a clairement établi les règles du jeu, voyons comment on peut empaqueter une application PHP dans du Docker. Pour l’exemple, on va utiliser phpBB. Il contient à peu près ce qu’on peut faire de pire en matière d’applications PHP (base de données, fichiers temporaires, fichiers persistents, etc…). ## Solution 1 : conteneurs génériques et répertoire de données ## Solution 2 : embarquer l’application dans les conteneurs (ou solution NextCloud) ## Solution 3 : embarquer l’application dans UN conteneur (ou solution Mastodon)