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 MySQL, et j'avais plusieurs hôtes virtuels pour différentes parties de l'application web. Quand j'étais satisfait des résultats que j'avais sur ma machine locale, je me connectais au serveur et à git pull dans l'environnement de transfert. En supposant que tout était travaillant aussi bien sur le serveur que sur ma machine, je ferais la même chose pour la production.
Un nouveau départ ...
Alors maintenant, je commence une toute nouvelle application web à partir de zéro, et je veux le faire "de la bonne façon". J'ai lu à propos de 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 encore y avoir plusieurs questions que je n'arrive pas à trouver réponses pour:
Devrait-il y avoir des conteneurs Docker séparés pour le serveur web (tel Qu'Apache), le serveur de base de données (tel que 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.
Puisque Docker semble fournir des conteneurs prêts à l'emploi pour des choses comme le web et serveurs de base de données, il semble que ces choses au moins devraient être dans des conteneurs séparés. Les différentes parties de mon application web devraient-elles aussi être dans des conteneurs séparés?
Les conteneurs Docker semblent être conçus pour être remplaçables plutôt que d'avoir à mettre à jour le logiciel à l'intérieur d'eux. Qu'en est-il des données qu'ils écrivent que je ne veux pas perdre?
Le serveur de base de données va gérer les fichiers liés au contenu de ma base de données (que je vais vouloir sauvegarder). Le serveur web créer 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 (parce que 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 "Volume Docker" séparé? Si elles vont dans les volumes Docker, devrais-je utiliser un volume séparé pour la base de données, le serveur web, l'application, etc.? Puis-je toujours accéder facilement au contenu en utilisant SFTP à partir de ma machine locale comme je le fais maintenant? Je ne veux pas perdre toute 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 gérer directement les conteneurs Docker, donc cela semble être un moyen raisonnablement bon 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 génial pour obtenir des "meilleures pratiques" appropriées pour le développement et la production D'applications Web de type LAMP, Il ne semble pas y avoir beaucoup de choses que j'ai trouvées!
2 réponses
Devrait - il y avoir des conteneurs Docker séparés pour le serveur web (tel Qu'Apache), le serveur de base de données (tel que MySQL) et chaque partie de l'application web?
Il n'y a pas de réponse correcte à 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 hub docker fournit des conteneurs prêts à l'emploi pour php, bases de données, etc et il est facile à utiliser. D'un autre côté, vous devez lier ensemble pour leur permettre d'interagir. Pour un environnement de dev et si vous utilisez plusieurs contenants, je vous conseille d'utiliser docker-composer.
Un autre chemin consiste à construire une image docker la plus proche de votre machine de production (en supposant que vous n'ayez 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. Ceci peut être réalisé de différentes manières. Jetez un oeil à 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 une base de données ou sur un volume docker accessible à tous.
Les conteneurs Docker semblent être conçus pour être remplaçable plutôt que d'avoir à mettre à jour le logiciel à l'intérieur d'eux. 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 les volumes: vous pouvez monter un répertoire à partir de l'hôte docker dans un volume de conteneur, ou vous pouvez avoir conteneurs de volumes de données, ou volumes nommés.
Les volumes Docker sont importants concept 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, le montage d'un répertoire sur l'hôte docker est la solution.
En ce qui concerne les sauvegardes, jetez un oeil au guide de l'utilisateur docker 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 pour la production le serveur?
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 puppet correctement pour votre environnement de développement si tout ce travail ne sera pas utilisé pour l'environnement de production. Avoir un Vagrantfile qui fournit une machine virtuelle avec docker est vraiment facile avec juste shell provisioning ; IMHO puppet / chef/... sont overkill.
Vous demandez le droit questions mais il n'y a pas de réponse qui 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
- rendez votre environnement de développement différent de la production en le gardant aussi simple et simple 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, j'aimerais ajouter quelques points supplémentaires.
Vagabond, marionnette / Chef et docker-composer
Lorsque vous provisionnez une machine virtuelle avec Vagrant, vous utilisez généralement Puppet ou Chef pour installer les paquets requis pour votre serveur ... avec quelques scripts shell. PuPHPet est une excellente source pour configurer une pile LAMPbasée sur une machine virtuelle et apprendre comment Puppet et Vagrant travaillent ensemble dans une configuration un peu plus complexe. Une alternative est Protobox au fait.
Lorsque vous utilisez conteneurs Docker avec Vagrant de la même manière que vous le faites avec les machines virtuelles. Ensuite, avec vagrant up, vous exécutez essentiellement des conteneurs docker avec le fournisseur Docker . Vagrant va construire les conteneurs pour vous à partir d'un Dockerfile ou utiliser une image existante, plus ou moins comme docker-compose (fig) et exécutez-les.
Une raison majeure de choisir Vagrant pour votre configuration Docker est, si vous ou votre équipe travaillez partiellement dans un environnement Windows, puisque Vagrant vous permet de garder votre configuration cohérente, quel que soit votre système hôte (voir Host VM).
Si vous êtes sur OS X, vous pouvez utiliser docker-compose avec une machine virtuelle de boîte virtuelle, si vous êtes sur Linux, vous pouvez utiliser Docker nativement. Il est également toujours possible de se connecter au boot2docker (ou à une autre machine virtuelle hôte Docker) via ssh, peu importe si vous êtes sous Windows ou OS X.
Remarque: Vous ne devrait pas SSH dans vos conteneurs, mais c'est un autre sujet.
Dès le mois de février 2015
docker-compose se sent un peu plus vif pour moi 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 machine virtuelle hôte différente, par exemple. par projet, si vous préférez une telle configuration.
Note: il y a aussi un provisionneur Docker qui est plus lié à un processus de construction Puppet.
Devrait-il être des conteneurs Docker séparés pour le serveur web (tel Qu'Apache), le serveur de base de données (tel que MySQL) et chaque partie de l'application web?
Lorsque vous utilisez des conteneurs Docker, vous exécutez essentiellement des processus isolés et isolés. L'utilisation d'un superviseur doit être évitée et n'est pas non plus nécessaire pour une pile de lampes.
Donc ma réponse est certainement: Oui, il devrait y avoir des conteneurs séparés!
Quand je parle de parties de l'application web, je des choses méchantes 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 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 Réponse de @ Thomasleveil je vous recommande é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'application web doit être traité comme une application cliente accédant à vos backends de base de données et de stockage (services) et ne pas dépendre des données des volumes lors de l'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 serveur de production?
Je ne connais pas les capacités d'orchestration de Puppet, mais pour construire des conteneurs, si vous utilisez Vagrant, Je ne vois pas le besoin de Puppet, à cause du provisionneur Docker natif de Vagrant.
Bonus
pour toutes ces choses décrites ci-dessus, vous pouvez jeter un oeil à mon modèle D'application PHP 12factor basé sur le Framework Yii 2.0 avec une pile LAMP dockerisée. avec Docker, vous pouvez également facilement plug-in reverse proxies ou conteneurs de test de sélénium 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 démarrés en quelques secondes.