Comment développer une application web LAMP en utilisant Docker, Puppet et Vagrant?
Dans les âges sombres, ma configuration habituelle pour le développement d'applications Web LAMP était de tester localement sur ma machine. PHP (dans mon cas), la base de données et le serveur Web ont tous été installés nativement.
Le serveur a été configuré avec des installations standard d'Apache et de MySQL, et j'avais plusieurs hôtes virtuels pour différentes parties de l'application Web. Lorsque j'étais satisfait des résultats obtenus sur ma machine locale, je me connectais au serveur et git pull dans l'environnement de transfert. En supposant que tout fonctionnait aussi bien sur le serveur que sur ma machine, je ferais la même chose pour la production.
Nouveaux débuts…
Alors maintenant, je démarre une toute nouvelle application Web à partir de zéro, et je veux le faire "de la bonne façon". J'ai lu des articles sur Docker, Vagrant et Puppet (et Chef, bien que je préfère personnellement le système de dépendances de Puppet plutôt que le processus itératif de Chef). Malgré toutes les recherches que j'ai faites, il semble toujours y avoir plusieurs questions pour lesquelles je n'arrive pas à trouver de réponses:
Devrait-il y avoir des conteneurs Docker séparés pour le serveur Web (comme Apache), le serveur de base de données (comme MySQL) et chaque partie de l'application web?
Quand je parle de parties de l'application Web, je veux dire des choses comme mysite.com , controlpanel.mysite.com , etc. Ces "parties" partageront la même base de données.
Étant donné que Docker semble fournir des conteneurs prêts à l'emploi pour des éléments tels que les serveurs Web et de base de données, il semble qu'au moins ces éléments devraient être dans des conteneurs distincts. Les différentes parties de mon application Web devraient-elles également être dans des conteneurs séparés?
Les conteneurs Docker semblent être conçus pour être remplaçables plutôt que de devoir mettre à jour le logiciel à l'intérieur. Qu'en est-il des données qu'ils écrivent que je ne veux pas perdre?
Le serveur de base de données gérera les fichiers liés au contenu de ma base de données (que je souhaiterai sauvegarder). Le serveur Web créera des journaux et mes applications Web géreront divers fichiers et caches, etc. Tous ces fichiers doivent être écrits en dehors des conteneurs de l'application (car je pourrais les remplacer lors de la mise à jour?), Alors où vont-ils? ? Directement dans le système de fichiers des machines hôtes? Ou dans un "Docker Volume" séparé? S'ils entrent dans des volumes Docker, dois-je utiliser un volume distinct pour la base de données, le serveur Web, l'application, etc.? Puis-je toujours accéder facilement au contenu à l'aide de SFTP depuis ma machine locale comme je le fais maintenant? Je ne veux perdre aucune commodité ici!
Est-ce une bonne idée d'utiliser Puppet pour créer et gérer les conteneurs Docker, à la fois pour le serveur de développement et le serveur de production?
Il semble que Puppet ait un support pour la gestion directe des conteneurs Docker, donc cela semble être un bon moyen de configurer facilement un serveur ou l'environnement de production (en utilisant Vagrant) à partir de zéro.
J'espère que j'ai posé quelques questions pertinentes; ce serait formidable d'obtenir quelques "meilleures pratiques" appropriées pour le développement et la production d'applications Web de type LAMP, c'est juste qu'il ne semble pas y avoir grand-chose que j'ai trouvé!
Devrait-il y avoir des conteneurs Docker séparés pour le serveur Web (comme Apache), le serveur de base de données (comme MySQL) et chaque partie de l'application Web?
Il n'y a pas de bonne réponse à cette question. Si vous utilisez Docker en production, essayez d'exécuter vos conteneurs Docker dans votre environnement de développement car ils seront en production. Sinon, utilisez simplement les conteneurs Docker de la manière la plus simple possible.
Le docker hub fournit des conteneurs prêts à l'emploi pour php, bases de données, etc. et il est facile de les utiliser. D'autre part, vous devez les lier entre eux pour leur permettre d'interagir. Pour un environnement de développement et si vous utilisez plusieurs conteneurs, je vous conseille d'utiliser docker-compose .
Un autre chemin consiste à créer une image docker la plus proche de votre machine de production (en supposant que vous n'avez qu'une seule machine) qui exécuterait la base de données, le serveur Web et php. Un conteneur à partir d'une telle image devrait exécuter plusieurs processus. Cela peut être réalisé de différentes manières. Jetez un œil à superviseur ou phusion/baseimage .
Quand je parle de parties de l'application Web, je veux dire des choses comme mysite.com, controlpanel.mysite.com, etc.
Vous pourriez les séparer. Si ces applications doivent partager des sessions, assurez-vous que les sessions sont stockées dans la base de données ou sur un volume docker accessible à tous.
Les conteneurs Docker semblent être conçus pour être remplaçables plutôt que moi d'avoir à mettre à jour le logiciel à l'intérieur. Qu'en est-il des données qu'ils écrivent que je ne veux pas perdre?
Docker a une chose appelée volume pour permettre aux données d'être écrites sur un système de fichiers hors du conteneur. Il existe différentes façons de travailler avec des volumes: vous pouvez monter un répertoire à partir de l'hôte docker sur un volume de conteneur, ou vous pouvez avoir conteneurs de volume de données , ou volumes nommés .
Les volumes Docker sont un concept important et il vaut la peine de prendre le temps de les maîtriser.
Si vous souhaitez accéder facilement aux données utilisées par vos conteneurs depuis votre Docker Host, monter un répertoire sur le Docker Host est la solution. Bien que cela puisse être délicat en ce qui concerne les autorisations et la propriété des fichiers
En ce qui concerne les sauvegardes, jetez un œil au Docker User Guide où tout ce que vous devez savoir en ce qui concerne les volumes est détaillé.
Est-ce une bonne idée d'utiliser Puppet pour créer et gérer les conteneurs Docker, à la fois pour le serveur de développement et le serveur de production?
La meilleure pratique consiste à opérer sur votre environnement de développement de la même manière que vous opérerez sur votre environnement de production. Il est inutile de configurer correctement la marionnette pour votre environnement de développement si tout ce travail ne sera pas utilisé pour l'environnement de production. Avoir un Vagrantfile qui fournit un VM avec docker est vraiment facile avec juste approvisionnement du Shell ; marionnette/chef/... à mon humble avis sont exagérés .
Vous posez les bonnes questions, mais aucune réponse ne convient à toutes les situations. À mon avis, il y a deux façons de faire les choses:
- faites en sorte que votre environnement de développement reproduise exactement votre environnement de production
- rendre votre environnement de développement différent de la production en le gardant aussi simple et direct que possible afin que les développeurs ne ressentent pas la friction induite par l'utilisation de nouveaux outils
Bien que la réponse de @Thomasleveil soit déjà très bonne et couvre toutes les parties importantes, je voudrais ajouter quelques points supplémentaires.
Vagrant, Puppet/Chef et docker-compose
Lorsque vous provisionnez une machine virtuelle avec Vagrant, vous utilisez généralement Puppet ou Chef pour installer les packages requis pour votre serveur ... ainsi que quelques scripts Shell. PuPHPet est une excellente source pour configurer une pile LAMP basée sur une machine virtuelle et apprendre comment Puppet et Vagrant fonctionnent ensemble dans une configuration un peu plus complexe. Une alternative est Protobox soit dit en passant.
Lorsque vous utilisez Docker containers avec Vagrant de la même manière que vous le faites avec les machines virtuelles. Puis avec vagrant up vous exécutez essentiellement des conteneurs Docker avec le Docker provider. Vagrant construira pour vous les conteneurs à partir d'un Dockerfile ou utilisera une image existante, plus ou moins comme docker-compose (fig) et exécutez-les.
Une raison principale de choisir Vagrant pour votre configuration Docker est, si vous ou votre équipe travaillez partiellement dans un environnement Windows, car Vagrant vous permet de garder votre configuration cohérente, quel que soit votre système hôte (voir VM hôte ).
Si vous êtes sous OS X, vous pouvez utiliser docker-compose avec une machine virtuelle Virtual Box, si vous êtes sous Linux, vous pouvez utiliser Docker en mode natif. Il est également toujours possible de se connecter au boot2docker (ou à une autre machine virtuelle hôte Docker) via ssh, que vous soyez sous Windows ou OS X.
Remarque: vous ne devez pas SSH dans vos conteneurs, mais c'est un autre sujet.
En février 2015
docker-compose me semble un peu plus rapide et gère également le démarrage, l'arrêt et la reconstruction des conteneurs plus efficacement.
Vagrant a l'avantage de spécifier une VM hôte différente, par exemple. par projet, si vous préférez une telle configuration.
Remarque: il y a aussi un provisioner Docker qui est plus lié à un processus de construction Puppet.
Devrait-il y avoir des conteneurs Docker séparés pour le serveur Web (comme Apache), le serveur de base de données (comme MySQL) et chaque partie de l'application Web?
Lorsque vous utilisez des conteneurs Docker, vous exécutez essentiellement des processus uniques et isolés. L'utilisation d'un superviseur doit être évitée et n'est également pas nécessaire pour une pile LAMP.
Donc, ma réponse est définitivement: oui, il devrait y avoir des conteneurs séparés!
Quand je parle de parties de l'application Web, je veux dire des choses comme mysite.com, controlpanel.mysite.com, etc.
Cela dépend de vos besoins, je vous suggère de lire la documentation de l'application 12factor , qui décrit les choses importantes à prendre en charge de manière très détaillée.
Les conteneurs Docker semblent être conçus pour être remplaçables plutôt que moi d'avoir à mettre à jour le logiciel à l'intérieur. Qu'en est-il des données qu'ils écrivent que je ne veux pas perdre?
En plus de la réponse de @ Thomasleveil, je vous recommanderais également un backend de stockage séparé pour les téléchargements d'utilisateurs comme Amazon S3, SFTP ou WebDAV.
À mon avis, votre conteneur d'applications Web doit être traité comme une application client accédant à votre base de données et à vos backends de stockage (services) et ne pas s'appuyer sur les données des volumes lors de son exécution dans un environnement de production.
Est-ce une bonne idée d'utiliser Puppet pour créer et gérer les conteneurs Docker, à la fois pour le serveur de développement et le serveur de production?
Je ne connais pas les capacités d'orchestration de Puppet, mais pour la construction de conteneurs, si vous utilisez Vagrant, je ne vois pas la nécessité de Puppet, en raison du provisionneur Docker natif de Vagrant.
Prime
Pour toutes ces choses décrites ci-dessus, vous pouvez jeter un œil à mon 12factor PHP modèle d'application basé sur Yii 2.0 Framework avec une pile LAMP dockerized. Avec Docker, vous pouvez également facilement brancher des proxys inverses ou des conteneurs de test Selenium dans votre projet, car ils existent en tant qu'images de pré-construction et peuvent être téléchargés et configurés en quelques minutes et a commencé en quelques secondes.