Quels sont les avantages de dockerize nginx et php dans différents conteneurs?

Je viens de commencer à travailler avec Docker et Kubernetes et j'ai regardé beaucoup de piles, dans lesquelles certaines personnes construisent nginx + php dans une seule image et certaines construisent une image avec nginx et une autre avec php (monter le même chemin et entourer les deux conteneurs dans le même déploiement dans Kubernetes).

Quels seraient les avantages de construire deux images docker au lieu d'installer les deux nginx + php dans la même?

PHP avec nginx se fait généralement en utilisant php-fpm qui est un processus distinct.

Garder l'idée centrale de docker d'un processus (voir la fin de la réponse pour plus de détails sur ce point) par conteneur, il est logique d'avoir le processus nginx et le processus php-fpm dans des conteneurs séparés.

Comme la communication entre nginx et php-fpm se fait via fastcgi, le conteneur php-fpm peut également être sur un hôte séparé, ce qui permet d'utiliser un cluster de conteneurs php-fpm derrière nginx.

Après le mur de commentaires, voici un peu plus de contexte, la documentation de docker contient un paragraphe sur l'idée qu'un conteneur ne devrait avoir qu'une seule préoccupation .

L'idée principale d'un conteneur Linux ( lxc ) est d'exécuter un processus dans un espace de noms isolé au niveau du processeur et de la mémoire, docker ajoute en plus de cela une isolation au niveau du système de fichiers.
L'avantage est que la compromission d'un processus au sein de cet espace de noms ne permettra pas de lire la mémoire d'autres processus et en tant que telle devrait empêcher toute autre compromission sur l'hôte.

Tout en parlant de nginx et de php-fpm, ils fonctionnent en binôme mais chacun a sa propre préoccupation, nginx fera la partie HTTP, le routage, la validation des en-têtes, etc. et php-fpm fera l'interprétation du code et retournera la partie html à nginx . Bien qu'il soit habituel que les deux servent ensemble une seule demande, ce n'est pas obligatoire.

Selon le contexte, il peut être plus facile d'avoir un conteneur comprenant toute la pile d'une application, sur un poste de développeur par exemple. Mais idéalement pour une utilisation en production, essayez de garder le moins d'interaction à l'intérieur du conteneur, avoir des processus séparés dans le même conteneur avec supervord apporte sa part de problème en termes de processus zombie et de gestion des journaux (exemple d'histoire ici à des fins d'illustration uniquement).

Enfin, je vais citer la page d'accueil avec un peu d'emphase:

Même si «un processus par conteneur» est souvent une bonne règle de base, ce n'est pas une règle stricte et rapide. Utilisez votre meilleur jugement pour garder les conteneurs aussi propres et modulaires que possible .

Il n'y a pas de "règle miracle" qui s'applique à tout, c'est toujours un équilibre entre la complexité au sein du conteneur et la complexité orchestrant les conteneurs eux-mêmes.

En fait, un point manquant ici est l'évolutivité horizontale. Il y a longtemps, un article de Jamie Alquiza a abordé ce sujet:

http://archive.is/pDzz0

En bref, vous mettez votre php-fpm à l'échelle horizontalement pour atteindre des performances plus élevées. La mise à l'échelle de Nginx + php-fpm ensemble ne vous apporte aucun avantage. Je vous encourage à faire des tests de résistance (par exemple Tsung, Gatling, etc.; veuillez ne pas faire Apache ab, qui est un très vieux jouet) vous-même pour vérifier ce que l'article dit. J'ai personnellement plusieurs expériences du monde réel prouvées que l'article est vrai en général.

Mais il y a deux inconvénients (peut-être pas pour Kubernetes) pour les machines / VMs bare metal:

1. Comment configurer Nginx pour découvrir dynamiquement les modifications du conteneur php-fpm? C'est la partie facile.
2. Comment partageons-nous les mêmes volumes / systèmes de fichiers après la mise à l'échelle? Les conteneurs Nginx et php-fpm doivent lire exactement le même contenu pour atteindre la cohérence. Cela vous laisse le moins de puzzle (et le plus amusant) sur lequel travailler.

EDITÉ: Maintenant, c'est presque la moitié de l'année 2019. L'ancien modèle, php-fpm + nginx dans le même pod, a une utilisation différente. Si vous êtes familier avec le maillage de service, alors nginx (ou ce que l'on appelle Nginmesh) sert de side-car pour gérer le trafic en direction est-ouest. Le trafic en direction est-ouest était principalement utilisé pour s'authentifier parmi les services ou d'autres fonctionnalités sophistiquées, alors que le php-fpm pur ne pouvait pas le faire.

Il n'y a aucun avantage significatif qui l'emporte sur la gestion de deux conteneurs. Tant que vous avez une relation 1: 1 entre les processus et qu'ils servent un seul objectif, placez-les dans le même conteneur.

L'avantage est: vous pouvez exécuter plusieurs conteneurs php-fpm en back-end, nous l'appelons cluster PHP, via le nombre de ports. Exemple de port 9000, 9001, 9002 .. et ainsi de suite