Docker : Comment Dockerize Et Déployer plusieurs instances d'une Application LAMPE

J'ai besoin de déployer plusieurs instances de la même LAMPE (ou de la LEMP) application :

  • chaque instance sera accessible à partir d'un sous-domaine, avec l'avant loadbalancer/proxy
  • chaque instance doit avoir son propre db de données et des fichiers de données.
  • chaque instance peut être surveillé
  • limite de mémoire /processeur peut être défini pour chaque instance de l'application
  • facile à automatiser le déploiement d'une nouvelle webapp instance
  • environnement peut être facilement reproductible de test et de développement.

Application nécessite :

  • dameon processus (Nginx, MariaDB, PHPFPM)
  • binaires (composer, bower, ...)
  • d'autres systèmes spécifiques libs & config

Après la lecture de Docker de la documentation et de nombreuses howtos, je vois plusieurs solutions à dockerize cette application web :

Solution 1 : Utiliser un tout-en-un Conteneur

Tous la pile est dans un récipient :

  • webapp fichiers source, EMP démon processus, les fichiers binaires, ...
  • volumes montés pour mysql et webapp fichiers de données

Exemples :

Pros (à mon humble avis) :

  • Semble facile à automatiser deploiement, de surveiller, de les détruire....
  • Facile à utiliser en prod, de test et de l'environnement de dev.

Contre (à mon humble avis):

  • Monolithique
  • Difficile d'échelle
  • Ne pas utiliser toute la force de Docker

Solution 2 : Utiliser une pile de conteneurs par webapp instance

Pour chaque webapp déployer, une pile de conteneurs est déployé :

  • Un conteneur par processus : Nginx, Mysql, PHP-FPM,
  • Binaire conteneurs (composer, bower,...) peuvent être également dockerized, ou fusionnées dans le phpfpm conteneur
  • montage des volumes pour mysql et webapp fichiers de données

Exemples :

Pro (à mon humble avis) :

  • Découplé
  • processus isolé par exemple
  • Un processus par conteneur, pas besoin de gestionnaire du démon comme RUnit ou
    Supervisord

Contre (à mon humble avis) :

  • Semble plus compliqué de faire un travail
  • Difficile à maintenir, à voir une “grande image” de tous les conteneurs états, des liens, version...

Solution 3 : Mixin les 2 solutions précédentes

  • Une “app” récipient avec : app src fichiers, nginx, phpfmp, compositeur, git..
  • Un récipient pour la db mysql, ce qui peut être partagé ou non avec l'application conteneur

Je suis de plus en plus de Dev que Ops, aussi il est confus pour moi.

Donc, Des Questions :

  1. Quels sont les critères, les avantages/inconvénients à considérer au moment de choisir entre les thèses des solutions?
  2. Howto pour gérer tous les conteneurs à piles si je choisis la Solution 2, pour avoir une "grande image" de tous les conteneurs états, des liens, version... ?
  3. App src fichiers (PHP) peut être construit dans le conteneur ou monté en volume, par exemple. /var/www ?
  • L'exécution de plusieurs processus dans un seul conteneur a des implications en matière de sécurité ainsi. Voir ceci (un peu datée) de la liste de recommandations de sécurité par l'équipe Docker/CEI.
InformationsquelleAutor Koryonik | 2014-07-24
  1. 18

    Je suis récemment allé à travers l'analyse sur Docker pour ce type de configuration. Je sais qu'il y a certains qui considèrent que le Panneau comme une sorte de MicroVM, mais de mon point de vue est le Docker philosophie se penche de plus simple vers le processus par conteneur. Cela suit bien avec le principe de Responsabilité Unique dans la programmation. Le plus un conteneur Docker ne, le moins réutilisable et plus difficiles à gérer. J'ai posté toutes mes pensées ici:

    http://software.danielwatrous.com/a-review-of-docker/

    Je suis ensuite allé à construire une LEMP pile à l'aide de Docker. Je n'ai pas trouver beaucoup de valeur à décomposer le PHP et Nginx processus de séparer les conteneurs Docker, mais le Web et les fonctions de Base de données sont dans des contenants séparés. Je montre aussi comment gérer de liaison et de partage de volume pour éviter de courir SSH démons dans vos contenants. Vous pouvez suivre ce que j'ai fait ici comme un point de référence.

    http://software.danielwatrous.com/use-docker-to-build-a-lemp-stack-buildfile/

    À votre point au sujet de l'augmentation complexité pour la seule fonction par conteneur, vous êtes correct. Il va regarder et se sentir comme vous avait distinctes, réparties niveaux. Applications de très grande taille ont fait cela pendant des années et qu'il ne l'augmentation de la complexité quand il s'agit de communication, de gestion et de sécurité. Bien sûr, il apporte un certain nombre d'avantages.

    • Pourquoi avez-vous choisi de créer vos propres contenants l'aide d'ubuntu pour le PARTIR de conteneur plutôt que de l'utiliser nginx et mysql conteneurs fournis par le Docker? Serait le Support fourni pour ne pas être plus simple?
    • Le tutoriel a eu un peu fins. L'un était de montrer une LEMP pile entre plusieurs machines virtuelles. L'autre était de démontrer Dockerfile. Je suis très intéressé dans l'infrastructure dans le code, j'ai donc choisi cette approche. Si vous allez à productionalize ce que j'ai commencé avec, vous pouvez trouver que les images disponibles sont plus commodes.
    InformationsquelleAutor Daniel Watrous
  2. 9

    Les deux solutions sont possibles. Cependant, je voudrais aller avec la solution 2 - un conteneur par processus, car il est plus compatible avec le Panneau "philosophie".

    La bonne chose à propos de Docker est, que vous pouvez créer une pile d'applications (comme la vôtre) indépendant de blocs de construction (les images des applications simples). Vous pouvez combiner les blocs de construction et les réutiliser. Si vous jetez un oeil à la officiel le Panneau de registre vous trouverez la plupart des composantes pré-images de la version. E. g. vous trouverez une Nginx à https://registry.hub.docker.com/u/dockerfile/nginx et une base de données MySQL à https://registry.hub.docker.com/_/mysql. Ainsi, la configuration de votre pile devient assez facile si vous choisissez d'utiliser un conteneur par processus/application:

    (Remarque, c'est juste un exemple, je ne suis pas familier avec PHP et d'autres choses...)

    Pour obtenir des images:

    docker pull mysql
docker pull dockerfile/nginx
docker pull tutum/apache-php

docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=mysecretpassword -d mysql
docker run -d -p 80:80 -v <sites-enabled-dir>:/etc/nginx/sites-enabled -v <log-dir>:/var/log/nginx dockerfile/nginx
docker run -d -p 80:80 tutum/apache-php

    Vous pouvez configurer votre pile très facilement. Et, si vous le souhaitez, vous pouvez modifier certains des composants simples. E. g. vous pouvez modifier la base de données MySQL à MariaDB, sans toucher à un autre composant.

    Le plus compliqué à propos de cette solution est la façon de configurer votre pile. Pour lier vos contenants, jetez un oeil à https://docs.docker.com/userguide/dockerlinks. Vous pouvez utiliser cette approche pour relier par exemple votre conteneur de l'application avec votre MySQL contenant.

    • Merci pour votre réponse. Je suis totalement d'accord la Solution 2 est plus compatible avec le support de la philosophie. Mais les principaux inconvénients (à mon humble avis), est de garder une "grande image" de tous les conteneurs membres & liens. J'ai essayé de Chantier et de Gaudi, mais je ne sais pas si le meilleur moyen n'existe pas.
    • Je pense chantier est cool de garder une vue d'ensemble. Cependant, je ne pense pas qu'il a tout de soutien au déploiement. Vous pouvez prendre un coup d'oeil à la fig.
    InformationsquelleAutor Thomas Uhrig