Quel serait un bon workflow docker webdev?


121

J'ai l'impression que docker pourrait grandement améliorer mon flux de travail webdev - mais je n'ai pas tout à fait réussi à comprendre comment aborder un projet en ajoutant un docker à la pile.

La pile logicielle de base ressemblerait à ceci:

Logiciel

  • Image (s) Docker fournissant une pile LAMP personnalisée

    • Apache avec plusieurs modules
    • MYSQL
    • PHP
    • Certains CMS, par exemple Silverstripe
  • GIT

Flux de travail

Je pourrais imaginer que le flux de travail ressemble un peu à ce qui suit:

Développement

  1. Écrivez un Dockerfilequi définit un conteneur LAMP répondant aux exigences énoncées ci-dessus
    • REQ: La machine doit démarrer apache / mysql juste après le démarrage
  2. Créer l'image docker
  3. Copiez les fichiers nécessaires pour exécuter le CMS dans par exemple ~/dev/cmsdir
    • Mettre ~/dev/cmsdir/sous contrôle de version
  4. Exécutez le conteneur docker, et en quelque sorte monter ~/dev/cmsdirà /var/www/sur le récipient
  5. Remplir la base de données
  6. Travaillez dans /dev/cmsdir/
  7. Valider et arrêter le conteneur Docker

Déploiement

  1. Configurer un hôte distant (par exemple avec ansible)
  2. Transférer l'image du conteneur vers l'hôte distant
  3. Récupérer cmsdir-project via git
  4. Exécutez le conteneur Docker, tirez dans la base de données et montez cmsdirdans/var/www

Maintenant, tout cela semble assez beau sur le papier, MAIS je ne suis pas sûr que ce soit la bonne approche.

Des questions:

  1. Lors du développement local, comment puis-je faire en sorte que la base de données persiste entre les redémarrages de l'instance de conteneur? Ou aurais-je besoin d'exécuter sql-dump à chaque fois avant de faire tourner le conteneur?

  2. Dois-je avoir des instances de conteneur distinctes pour la base de données et le serveur Apache? Ou serait-il suffisant d'avoir un seul conteneur pour le cas d'utilisation ci-dessus?

  3. Si vous utilisez des conteneurs séparés pour la base de données et le serveur, comment pourrais-je automatiser leur rotation de haut en bas en même temps?

  4. Comment monterais-je réellement /dev/cmsdir/dans le /var/www/répertoire des conteneurs ? Dois-je utiliser des volumes de données pour cela?

  5. Ai-je manqué des pièges? Tout ce qui pourrait être simplifié?


1
Cette question semble intéresser pas mal de gens. Quelqu'un semble avoir récemment écrit une série d'articles sur le sujet. Comme il est pas fini à partir de maintenant, je vais poster le lien dans ce commentaire: project-webdev.blogspot.de/2015/05/...
jottr

Réponses:


46
  1. Si vous avez besoin de la persistance de la base de données indépendamment de votre conteneur CMS, vous pouvez utiliser un conteneur pour MySQL et un conteneur pour votre CMS. Dans ce cas, vous pouvez avoir votre conteneur MySQL toujours en cours d'exécution et redéployer votre CMS aussi souvent que vous le souhaitez indépendamment.

    Pour le développement - une autre option est de mapper les répertoires de données mysql depuis votre machine hôte / de développement en utilisant des volumes de données. De cette façon, vous pouvez gérer les fichiers de données pour mysql (dans docker) en utilisant git (sur l'hôte) et "recharger" l'état initial à tout moment (avant de démarrer le conteneur mysql).

  2. Oui, je pense que vous devriez avoir un conteneur séparé pour db.

  3. J'utilise juste un script de base:

    #!/bin/bash
    
    $JOB1 = (docker run ... /usr/sbin/mysqld)
    $JOB2 = (docker run ... /usr/sbin/apache2)
    echo MySql=$JOB1, Apache=$JOB2
    
  4. Oui, vous pouvez utiliser le commutateur data-volumes -v. J'utiliserais ceci pour le développement. Vous pouvez utiliser le montage en lecture seule, donc aucune modification ne sera apportée à ce répertoire si vous le souhaitez (votre application devrait de toute façon stocker les données ailleurs).

    docker run -v=/home/user/dev/cmsdir:/var/www/cmsdir:ro image /usr/sbin/apache2
    

    Quoi qu'il en soit, pour le déploiement final, je construirais et créerais une image à l'aide de dockerfile avec ADD /home/user/dev/cmsdir /var/www/cmsdir

  5. Je ne sais pas :-)


6
J'ai écrit un tutoriel sur l'écriture d'un conteneur mysql qui implémente ce dont vous parlez dans # 1 txt.fliglio.com/2013/11/creating-a-mysql-docker-container
ben schwartz

48
Il faut certainement plus de tutoriels / meilleures pratiques sur ce processus. :(
Reza S

Ce tutoriel pourrait vous donner une certaine direction ..
Pithikos

Si vous souhaitez extraire du code de Github dans Docker, ce lien suggère des clés SSH en lecture seule (afin que l'image Docker puisse être répertoriée publiquement) slash-dev-blog.me/docker-git.html
jhtong

4
@RoyTruelove à partir de 2015, fig est désormais obsolète au profit de docker-compose
allan.simon


4

Je comprends que cet article date de plus d'un an en ce moment, mais je me suis récemment posé des questions très similaires et j'ai plusieurs bonnes réponses à vos questions.

  1. Vous pouvez configurer une instance de docker MySQL et faire en sorte que les données persistent sur un conteneur de données sans état, c'est-à-dire que le conteneur de données n'a pas besoin d'être actif

  2. Oui, je recommanderais d'avoir une instance distincte pour votre serveur Web et votre base de données. C'est la puissance de Docker.

  3. Découvrez ce repo que j'ai construit. Fondamentalement, c'est aussi simple que make build& make runet vous pouvez avoir un serveur Web et un conteneur de base de données fonctionnant localement.

  4. Vous utilisez l' -vargument lors de la première exécution du conteneur, cela liera un dossier spécifique sur le conteneur à l'hôte exécutant le conteneur.

  5. Je pense que vos idées sont excellentes et qu'il est actuellement possible de réaliser tout ce que vous demandez.

Voici une solution clé en main répondant à tous les besoins que vous avez listés.


1

J'ai mis en place une configuration de composition de docker facile à utiliser qui doit correspondre aux exigences de votre flux de travail de développement.

https://github.com/ehyland/docker-silverstripe-dev

Caractéristiques principales

  • DB persistante
  • Votre choix de HHVM+ NGINXou Apache2+PHP5
  • Déboguer et définir des points d'arrêt avec xDebug

Le fichier README.md doit être suffisamment clair pour vous permettre de démarrer.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.