Docker, déploiement et PHP
Si l’écosystème des conteneurs s’est autant démocratisé ces dernières années, c’est notamment grâce à l’apparition de Docker dont les ambitions sont clairement affichées sur le site: “Build, Ship, and Run Any App, Anywhere”, que l’on pourrait traduire par “construisez, déployez, et exécutez n’importe quelle application, n’importe où”. Si la promesse est intéressante, la mise en place d’une infrastructure autour de Docker peut ne pas être chose facile.
A l’heure actuelle, énormément d’environnement de développement et de système d’intégration continue fonctionne autour de Docker. Mais ce n’est pas nécessairement le cas des applications en production, car derrière cette promesse de portabilité se cache un certain nombre de contraintes et construire une application tournant au sein d’un conteneur n’est pas nécessairement une chose aisée, surtout en PHP.
Pour mettre en place avec succès une infrastructure autour de conteneur, de nombreuses entreprises ont établi un ensemble de bonnes pratiques. Parmis ces dernières, l’un des plus importante est qu’un conteneur doit correspondre à une application. Si cela est quelque chose de pertinent et facile dans le cas d’une application Go (qui une fois compilé correspond à un binaire embarquant toutes ses dépendances) ou d’une application Java (il est possible pour une archive Java d’embarquer son propre serveur HTTP pour fonctionner de manière autonome), tout n’est pas aussi facile dans le cas d’une application PHP.
Effectivement, une application Web PHP ne peut fonctionner de manière autonome. Cette dernière tourne généralement au travers de deux dépendances: un serveur HTTP (type Apache, Nginx, …) et un module PHP (qui, couplé au serveur HTTP permet d’exécuter la machine virtuelle du langage). Si nous souhaitons donc avoir un conteneur autonome et capable de faire tourner notre application PHP, nous devrions donc avoir un conteneur embarquant PHP et un serveur HTTP. Mais cette manière de procéder est-elle en adéquation avec les bonnes pratiques citées précédemment ?
Si nous considérons notre application comme un service à part entière, oui. Par contre si nous considérons le serveur HTTP (le point d’entrée d’une requête auprès de notre application) et le code PHP (notre application à proprement parler) comme deux services distincts, alors on peut considérer que nous sommes en train d’enfreindre les bonnes pratiques des conteneurs (à plus forte raison, si l’on voit un conteneur comme un processus isolé).
Il y a bien entendu la théorie et la pratique, et même si j’ai ma propre idée sur la mise en place d’un environnement de conteneur pour les applications PHP sur lesquelles je travaille, j’ai trouvé intéressant de poser la question sur Twitter pour avoir des retours d’expériences.
Les retours que j’ai pu avoir sont très intéressant et révèlent de nombreux avis différents ainsi que divers infrastructures. Je pense d’ailleurs publier prochainement une synthèse des échanges que j’ai pu avoir.
Et si vous souhaitez participer, il n’est pas encore trop tard !
Dites les gens qui utilisent #Docker pour déployer des projets #PHP en prod, est-ce que votre conteneur "applicatif" embarque PHP et le serveur Web (nginx, apache, ...) traitant les requêtes, ou est-ce que vous séparer les deux concepts dans des conteneurs séparés ? RT appréciés
— Jérémy DECOOL (@jdecool) 29 août 2018