web-dev-qa-db-fra.com

Docker plusieurs environnements

J'essaie d'enrouler ma tête autour de Docker, mais j'ai du mal à le comprendre. J'ai essayé de l'implémenter dans mon petit projet (pile MERN), et je me demandais comment distinguer les environnements de développement (peut-être de staging) et de production.

J'ai vu un exemple où ils ont utilisé 2 fichiers Docker et 2 fichiers Docker-compose, (chaque paire pour un env, donc Dockerfile + docker-compose.yml pour prod, Dockerfile-dev + docker-compose -dev.yml pour dev).

Mais cela me semble un peu exagéré. Je préférerais l'avoir seulement dans deux fichiers.

Un des problèmes est également que, par ex. pour le développement, je veux installer nodemon globalement, mais pas pour la poduction.

Dans une solution parfaite, j'imagine exécuter quelque chose comme ça

docker-compose -e ENV=dev build
docker-compose -e ENV=dev up

Gardez à l'esprit que je ne comprends toujours pas complètement Docker, donc si vous avez découvert certaines de mes idées fausses sur Docker, vous pouvez les signaler.

dockerdocker-composedockerfiledevelopment-environment
17
maciejmatu

Vous pouvez prendre quelques indices de " tilisation de Compose en production "

Vous souhaiterez presque certainement apporter des modifications à la configuration de votre application qui conviennent mieux à un environnement en direct. Ces changements peuvent inclure:

  • Suppression de toutes les liaisons de volume pour le code d'application, afin que le code reste à l'intérieur du conteneur et ne puisse pas être modifié de l'extérieur
  • Liaison à différents ports sur l'hôte
  • Définition des variables d'environnement différemment (par exemple, pour réduire la verbosité de la journalisation ou pour activer l'envoi d'e-mails)
  • Spécification d'une stratégie de redémarrage (par exemple, redémarrage: toujours) pour éviter les temps d'arrêt
  • Ajout de services supplémentaires (par exemple, un agrégateur de journaux)

Le conseil n'est alors pas tout à fait similaire à l'exemple que vous mentionnez:

Pour cette raison, vous souhaiterez probablement définir un fichier de composition supplémentaire, par exemple production.yml, qui spécifie la configuration adaptée à la production. Ce fichier de configuration doit uniquement inclure les modifications que vous souhaitez apporter à partir du fichier de composition d'origine.

docker-compose -f docker-compose.yml -f production.yml up -d

Ceci mécanisme prioritaire est mieux que d'essayer de mélanger la logique de développement et de production dans un seul fichier de composition, avec une variable d'environnement pour essayer de sélectionner un.

Remarque: Si vous nommez votre deuxième dockerfile docker-compose.override.yml, un simple docker-compose up lirait automatiquement les remplacements.
Mais dans votre cas, un nom basé sur l'environnement est plus clair.

20
VonC

Docker Compose lira docker-compose.yml et docker-compose.override.yml par défaut. nderstanding-Multiple-Compose-Files

Vous pouvez définir une valeur par défaut docker-compose.yml et différents fichiers de composition d'écrasement. Par exemple, docker-compose.prod.ymldocker-compose.test.yml. Gardez-les au même endroit.

Créez ensuite un lien symbolique nommé docker-compose.override.yml pour chaque env.
Piste docker-compose.{env}.yml fichiers et ajoutez docker-compose.override.yml à .gitignore.
En prod env: ln -s ./docker-compose.prod.yml ./docker-compose.override.yml
Dans le test env: ln -s ./docker-compose.test.yml ./docker-compose.override.yml
La structure du projet ressemblera alors à ceci:

project\
  - docker-compose.yml       # tracked
  - docker-compose.prod.yml  # tracked
  - docker-compose.test.yml  # tracked
  - docker-compose.override.yml # ignored
          #linked to override composefile for current env 
  - src/
  - ...

Alors vous avez terminé. Dans chaque environnement, vous pouvez utiliser le fichier compose avec la même commande docker-compose up

Si vous n'êtes pas sûr, utilisez docker-compose config pour vérifier si elle a été remplacée correctement.

3
kehao