volumes_from - docker compose yml español

¿Archivo env diferente pero mismo yml con Docker Compose? (3)

Buenos ejemplos claros, sin embargo, esto inicialmente no me funcionó hasta que actualicé la base.yml para llamar a la cáscara de la ceniza.

base.yml

base: image: busybox command: ash -c ''echo "${WHO:-Simon} says, /"${SHOUTOUT:-Silence is golden.}/""''

Me parece bastante común que tenga varios entornos (por ejemplo, test y prod), pero los contenedores Docker que deseo iniciar son los mismos en ambos entornos. La única diferencia es la configuración de la aplicación que quiero especificar usando un env-file . Puesto que tengo varios contenedores y dependencias entre ellos, quiero usar la función docker-compose . Pero afaik solo puedo especificar un env-file dentro del env-file docker-compose.yml (ver docs ). Si este es el caso, necesito clonar mi docker-compose.yml original en dos archivos diferentes (uno para prueba y otro para producto) solo para apuntar a diferentes archivos env. Esto significa que tengo que mantener dos archivos docker-compose.yml lugar de uno y, si realizo algún cambio, necesito actualizar ambos archivos.

¿Esto es realmente de acuerdo con el diseño? ¿Por qué no docker-compose me permite especificar --env-file cuando hago docker-compose up o docker-compose run ?

No es una inclusión directa desde la línea de comandos, pero si necesita una solución env_file antes de que la fusión # 1765 (la solución para https://github.com/docker/compose/issues/1377 ) se convierta en una versión, puede usar la directiva env_file junto con la directiva env_file . Para mayor comodidad, los archivos de los ejemplos simples a continuación se reproducen en este repositorio .

Estúpido ejemplo simple

`base.yml`

base: image: busybox command: bash -c ''echo "${WHO:-Simon} says, /"${SHOUTOUT:-Silence is golden.}/""''

`one.env`

WHO=Da Schwartz SHOUTOUT=Get to...

`one_glue.yml`

one: extends: file: base.yml service: base env_file: - one.env

`two.env`

WHO=Da Schwartz SHOUTOUT=...da choppa!

`two_glue.yml`

two: extends: file: base.yml service: base env_file: - two.env

Utilizar

% for i in base one_glue two_glue ; do docker-compose --file "${i}.yml" up ; done Recreating dockercomposeextendsenv_base_1... Attaching to dockercomposeextendsenv_base_1 base_1 | Simon says, "Silence is golden." dockercomposeextendsenv_base_1 exited with code 0 Gracefully stopping... (press Ctrl+C again to force) Recreating dockercomposeextendsenv_one_1... Attaching to dockercomposeextendsenv_one_1 one_1 | Da Schwartz says, "Get to..." dockercomposeextendsenv_one_1 exited with code 0 Gracefully stopping... (press Ctrl+C again to force) Recreating dockercomposeextendsenv_two_1... Attaching to dockercomposeextendsenv_two_1 two_1 | Da Schwartz says, "...da choppa!" dockercomposeextendsenv_two_1 exited with code 0 Gracefully stopping... (press Ctrl+C again to force)

Un ejemplo aún más simple.

Lo anterior funciona si te beneficias con el uso de archivos .env . Si no está tan limitado, puede mantener la configuración de la variable de entorno en los archivos .yml "pegamento" específicos del entorno:

`red_glue.yml`

red: extends: file: base.yml service: base environment: - WHO=Stallion - SHOUTOUT=I am...

`blue_glue.yml`

blue: extends: file: base.yml service: base environment: - WHO=Stallion - SHOUTOUT=...the law!

Utilizar

% for i in red_glue blue_glue ; do docker-compose --file "${i}.yml" up ; done Creating dockercomposeextendsenv_red_1... Attaching to dockercomposeextendsenv_red_1 red_1 | Stallion says, "I am..." dockercomposeextendsenv_red_1 exited with code 0 Gracefully stopping... (press Ctrl+C again to force) Creating dockercomposeextendsenv_blue_1... Attaching to dockercomposeextendsenv_blue_1 blue_1 | Stallion says, "...the law!" dockercomposeextendsenv_blue_1 exited with code 0 Gracefully stopping... (press Ctrl+C again to force)

Un poco mas complicado

Para lo que vale, el enfoque descrito en esta respuesta permite diferentes archivos .env por instancia, en lugar de por invocación / entorno. (Sin embargo, no estoy seguro de cuán beneficioso es esto en la práctica). En otras palabras, podría hacer algo como esto:

`testing.yml`

# Only instance1 and instance2 are needed for testing instance1: extends: file: base.yml service: base env_file: - test.env # environment-specific - instance1_test.env # instance-specific instance2: extends: file: base.yml service: base env_file: - test.env - instance2_test.env

`production.yml`

# All four instances are used for production instance1: extends: file: base.yml service: base env_file: - prod.env # environment-specific - instance1_prod.env # instance-specific instance2: extends: file: base.yml service: base env_file: - prod.env - instance2_prod.env instance3: extends: file: base.yml service: base env_file: - prod.env - instance3_prod.env instance4: extends: file: base.yml service: base env_file: - prod.env - instance4_prod.env

Puede comenzar a ver que las extends son bastante poderosas, mucho más que lo que permite la fusión # 1765 .

Ver la actualización # 2 a continuación. ¡Esto es ahora posible!

Esta es una característica muy solicitada de Docker Compose. Desafortunadamente, la respuesta en este momento es que no puedes. Recomiendo suscribirse a estos problemas de GitHub para tener una mejor idea de cuándo y si se implementa esta característica:

El problema # 495 es en realidad el más comentado en su repositorio de problemas en este momento. Definitivamente no estás solo en querer hacer esto.

Actualizar:

El último seguimiento de problemas se encuentra en https://github.com/docker/compose/issues/1377 .

Actualización # 2:

Esta funcionalidad se ha fusionado y está disponible a partir de Docker Compose 1.5.0. Consulte https://github.com/docker/compose/blob/129092b7/docs/yml.md#variable-substitution para obtener información de uso.