El nombre del proyecto no es importante. Me gusta la idea de un nombre de proyecto aleatorio. Aún mejor, ¿podríamos generar un hash de la ruta a fig.yml y usarlo?

De hecho, creo que el nombre del proyecto es bastante importante. Si desea poder hacer algo con las imágenes en una canalización de CI, necesita saber el nombre del proyecto para poder volver a etiquetarlas como otra cosa.

Ser capaz de anular el nombre del proyecto de las variables de entorno hace que sea fácil mantener estas variables únicas y predecibles. Creo que no importa lo que suceda, debemos admitir la anulación de las variables de entorno.

Me gusta la idea de hacer que el nombre del proyecto sea configurable desde un archivo. Creo que ocurrió una discusión similar en (# 45). Tener el nombre del proyecto en .fig/project-name parece que dará lugar a muchos archivos realmente pequeños. Creo que sería más fácil ponerlo en el fig.yml sí mismo (como se sugiere en el # 45, y una de las propuestas de redacción de la ventana acoplable).

¿Cuáles son las ventajas de ponerlo en un directorio y archivo separados?

La razón para ponerlo en un archivo separado tiene varias razones, intentaré explicar mi pensamiento detrás de esto;

• Para conservar el nombre que se usó para _iniciar_ el proyecto (es decir, --project-name=foobar ), que puede ser diferente del nombre del proyecto automático.
• Tener varias instancias o _versiones_ de un proyecto ejecutándose en el mismo servidor, sin que entren en conflicto entre sí
• O, en resumen, .fig/project-name tiene el nombre de _ esa instancia_ del proyecto.

Quizás el archivo debería llamarse instance-name o similar.

Me gusta la idea de hacer que el nombre del proyecto sea configurable desde un archivo.

Aunque _posible_ hacer esto con esta propuesta (creando manualmente el archivo project-name ), mi caso de uso principal era que _fig_ creara el archivo para guardar el nombre que se usó.

dará lugar a muchos archivos realmente pequeños.

Es cierto que la alternativa es omitir el directorio .fig , sin embargo, si se necesitan cosas adicionales en el futuro, se pueden agregar archivos adicionales sin saturar la raíz de su proyecto. Git lo hace de manera similar y creo que es un enfoque limpio.

Creo que sería más fácil ponerlo en fig.yml

Creo que ambas opciones pueden ser complementarias; use el nombre de fig.yml como predeterminado si el nombre no está anulado por una bandera o variable env. Ponga el nombre que realmente se usa para _iniciar_ el proyecto dentro de .fig/project-name

Ser capaz de anular el nombre del proyecto de las variables de entorno hace que sea fácil mantener estas variables únicas y predecibles. Creo que no importa lo que suceda, debemos admitir la anulación de las variables de entorno.

Curioso; ¿Cómo maneja la gestión de múltiples proyectos? Es decir, cd project-a && fig ps luego cd project-b fig <something> ?

¡Gracias por tus comentarios!

Curioso; ¿Cómo maneja la gestión de múltiples proyectos?

Normalmente ejecuto fig desde python-tox , lo que me permite configurar el entorno, por lo que nunca lo configuro realmente en mi shell. También suelo usar tmux, por lo que tengo shells diferentes para cada proyecto.

Creo que ambas opciones pueden ser complementarias

Genial, estoy de acuerdo.

No sé si estoy vendido en .fig/instance-name decir .fig-instance.yml que podría contener cualquier anulación específica de instancia, pero creo que esto es más un punto menor.

Pensando en el nombre del proyecto; Si entiendo correctamente su situación, es importante poder tener control sobre las _imágenes_ que se están produciendo, por ejemplo, myapp:build12345 , ¿o también los nombres de los _contenedores_? Sólo para "sentir" su situación.

Lo que pensaba detrás de los nombres de proyectos "aleatorios" era que, mientras Fig sea capaz de localizar los contenedores de un proyecto, los nombres bonitos no son importantes. Si yo, como usuario, puedo acceder al contenedor de un servicio a través de su nombre de servicio (por ejemplo, fig stop web ), el nombre del contenedor real no importa.

Incluso he estado pensando que fig podría realizar un seguimiento de los contenedores por ID en un almacenamiento local dentro del directorio .fig (lo que podría ser una ganancia de rendimiento en máquinas con muchos contenedores en ejecución). Pero eso es realmente algo para un tema aparte.

¿Alguna idea sobre la creación "implícita" del archivo 'nombre del proyecto' o "explícitamente" a través de fig init ? Quizás si tengo algo de tiempo durante las próximas vacaciones, pueda experimentar un poco (nunca codifiqué nada en Python, por lo que será _realmente_ experimental :))

¿Es importante poder tener control sobre las imágenes que se están produciendo, por ejemplo, myapp: build12345 , o también los nombres de los contenedores?

Supongo que la imagen es la realmente importante, pero poder garantizar que los nombres de los contenedores no entren en conflicto también es muy importante en los hosts compartidos. Veo que esta propuesta también tiene como objetivo abordar esa cuestión.

Pero sí creo que los nombres predecibles de los contenedores siguen siendo importantes. Puedo pensar en un par de tareas en las que es importante que los sistemas externos (no solo fig) puedan identificar un contenedor por su nombre:

• scripts de limpieza para eliminar contenedores antiguos, pudiendo identificar qué proyecto creó un contenedor
• depurar / inspeccionar contenedores

Ambos son bastante fáciles en este momento porque ya sé cuál será el nombre del contenedor. Si tengo que buscar un nombre, es algo más complicado.

Incluso he estado pensando que fig podría realizar un seguimiento de los contenedores por ID en un almacenamiento local dentro del directorio .fig

Es cierto que esto podría ser una ganancia de rendimiento, pero me preocupa que este sea el enfoque equivocado. Agregar cualquier estado persistente a fig introduce la posibilidad de muchos errores (que vienen junto con el estado). Preferiría ver esto manejado por un sistema de etiquetado en dockerd. Si fig es capaz de etiquetar contenedores y luego consultar todos los contenedores con esa etiqueta, mantiene todo el estado en un solo lugar (dockerd). Sé que se habló de esto en algún momento, no estoy seguro si está en la hoja de ruta.

¿Alguna idea sobre la creación "implícita" del archivo 'nombre del proyecto' o "explícitamente" a través de fig init?

Supongo que implícitamente sería más compatible con versiones anteriores. Me gustaría evitar un fig init menos que sea absolutamente necesario. En lugar de usar basedir, pude verlo implícitamente creando un nombre de proyecto de <basename>-<4 digit random id>

Solo puedo decir que si fig comienza a generar nombres aleatorios, ahora lo cambiaré porque ejecuto más de 1000 contenedores en un solo host y cuando ya no puedo identificarlos por su nombre, no es nada para mí.

@ frank-dspeed gracias por agregar su caso de uso. Si lo entiendo correctamente, usted _comienza_ sus contenedores con fig, pero _ "gestiona" _los directamente a través de Docker después de eso, haciendo uso de la convención de nomenclatura que utiliza Fig.

Quizás esto también le interese: https://github.com/docker/docker/pull/9882 : tener metadatos ofrecería más formas de identificar contenedores, no solo su nombre.

ah, sí, hice muchas propuestas de este tipo, por ejemplo, simplemente agregando nuevos campos y eso, pero terminé en ese caso simplemente agregando un ENV y luego lo tengo como archivo personalizado, puedo analizarlo: dart:

Creo que gestionar la falta de ambigüedad del nombre del proyecto no debería ser responsabilidad de fig.

cuando entendí su propuesta correctamente, la generación de un nombre aleatorio haría que la opción FIG_PROJECT_VARIABLE y --project-name fueran inútiles. que es útil para los servicios de "plantillas".

Creo que gestionar la falta de ambigüedad del nombre del proyecto no debería ser responsabilidad de fig.

No estoy muy seguro; Fig sobreescribiendo "silenciosamente" los contenedores de otros proyectos porque si se encuentra en un directorio con el mismo nombre a veces es desagradable.

cuando entendí su propuesta correctamente, la generación de un nombre aleatorio haría que FIG_PROJECT_VARIABLE y la opción --project-name-option fueran inútiles. que es útil para los servicios de "plantillas".

Siguiendo la discusión anterior, creo que algo como esto funcionaría

• Si se proporciona --project-name , úselo (y escriba / actualice el .project-name ? No estoy seguro)
• No se proporciona --project-name , pero FIG_PROJECT_NAME , use FIG_PROJECT_NAME (y escriba / actualice a .project-name ?)
• Ninguno de los anteriores, pero .project-name está configurado, use .project-name
• Ninguna de las anteriores; crea un nombre _ aleatorio_ y escríbelo en .project-name

desde la perspectiva de alguien que usa fig en scripts que se ocupan de un nombre y lo pasan a fig, almacenar un nombre en la ubicación del proyecto (que en mi caso es más bien una plantilla) no tiene sentido.

y aún así, sentí que era muy intuitivo que el nombre del directorio se usa en el nombre de los contenedores resultantes cuando acabo de ejecutar fig up .
y digamos, mira docker ps -a , eso no será muy útil si está lleno de nombres aleatorios.

¿Sería útil una opción --random-name en su situación?
además de eso, creo que la capacidad de anteponer algunos [a-zA-Z0-9_].* para reflejar algunos espacios de nombres sería útil para implementaciones más amplias.

¿Qué hay de usar fig.yml para almacenar dicha información?

schema-version: 1.1
project_name: foo
containers:
  web:
    build: .
   command: python app.py
    links:
     - db
    ports:
     - "8000:8000"
  db:
    image: postgres

Y para mantener BC, en compose / project.py :: from_config

<strong i="9">@classmethod</strong>
    def from_config(cls, name, config, client):
        if 'schema-version' not in config:
            config = {
                'schema-version': '1.0',
                'containers': config
            }
        dicts = []
        for service_name, service in list(config.containers.items()):
            if not isinstance(service, dict):
                raise ConfigurationError('Service "%s" doesn\'t have any configuration options. All top level keys in your docker-compose.yml must map to a dictionary of configuration options.' % service_name)
            service['name'] = service_name
            dicts.append(service)
        return cls.from_dicts(name, dicts, client)

@jderusse Estoy muy a favor de algo como lo que

de todos modos para llegar a una resolución sobre este boleto? Parece que el # 1233 propuesto le brinda lo mejor de ambos mundos al permitir que el usuario decida la acción que desea tomar sin romper ninguna compatibilidad con versiones anteriores.

Originalmente quería el nombre en docker-compose.yml , pero después de pensarlo más, me gusta mucho la idea de un archivo separado.

Un archivo separado le da la opción de mantenerlo fuera del control de versiones si lo desea (para los casos en los que desea que cada usuario pueda tener un nombre de proyecto diferente).

Con el nuevo soporte de red hay una solicitud de función para poder configurar el nombre de la red también (por defecto es el nombre del proyecto). Entonces, con un archivo de configuración separado, podríamos incluir cosas como el nombre de red predeterminado, la escala predeterminada, etc. Toda la metaconfiguración que no forma parte de la definición de la aplicación, pero sigue siendo relevante para ejecutar la composición.

Estoy de acuerdo con lo que dijo Dnephin. ¿Qué tal un archivo .docker-compose ? Podríamos enumerar las opciones predeterminadas para todos los argumentos de la línea de comandos allí.

@dnephin sgtm

@mikehaertl Usé una carpeta .docker-compose en mi ejemplo, pero un archivo también podría funcionar, dependiendo de la cantidad de información que queramos almacenar

@thaJeztah Oh, cierto, lo siento. Me lo perdí.

@mikehaertl acaba de .fig a .docker-compose ;-)

Correcto :)

De hecho, prefiero un archivo simple. ¿Qué tal el estilo ini? Opciones globales en la parte superior, opciones específicas del comando en una sección:

project-name = blabla

[build]
no-cache

Algunas ideas para información semi-relacionada que podemos querer almacenar en el mismo archivo o en el mismo directorio:

• nombre de la red (los usuarios pueden querer un nombre de red diferente al nombre del proyecto. Ya hemos tenido una solicitud para eso).
• versión de la API del cliente
• host de Docker
• valor de escala predeterminado

Ahora que admitimos varios archivos de redacción, también puede ser interesante incluir las rutas a los archivos de redacción para usarlos como configuración.

versión de la API del cliente

posiblemente docker_host ?

Eso también suena bien (agregado)

Me acabo de encontrar con este problema.

Estoy en un punto en el que la estructura básica de nuestra configuración de la ventana acoplable se ha establecido y ahora la estoy replicando en otros servicios. Dado que todos los proyectos tienen la misma estructura, todos usan el mismo subdirectorio (y por lo tanto, el nombre del proyecto predeterminado). Lo que significa que no puedo poner en cola de forma segura 2 servicios en el mismo host.

Es posible que tenga que cambiar la estructura para que el nombre del directorio del proyecto termine siendo el predeterminado, pero no estoy 100% seguro de lo que eso hace al copiar archivos en el momento de la construcción de la imagen.

Lo mismo aquí, resolví un problema similar con los objetivos de Makefile . Pero aún así, cuando desee ejecutar comandos docker-compose , debe usar -p customname .

En este momento, estoy tratando de descubrir cómo evitar que las configuraciones de composición de docker en /home/alice/myproject y /home/bob/myproject pisen los contenedores de los demás. ¿Hay alguna forma de derivar los nombres de los contenedores a partir de la ruta completa del archivo en lugar de solo el nombre del último directorio?

@ chris-martin Esto es solo una solución ...

alias docker-compose="docker-compose -p ${PWD}"

Sin embargo, docker-compose elimina / de los nombres de los proyectos?

¿Está documentado qué caracteres están permitidos en los nombres de los proyectos?

Terminé cambiando la estructura de mi directorio y colocando docker-compose.yml en la raíz del proyecto, que es una solución bastante decente

Otorga algo de protección, si tiende a poner todos sus repositorios de git en el mismo directorio (por ejemplo, $ HOME o $ HOME / projects), pero se vuelve problemático si usa otra estructura (digamos, un directorio por organización, como yo a menudo lo hacen), o si su máquina usa boot2docker, que tiende a filtrar información entre los usuarios en la misma caja, a menos que tenga cuidado de asegurarse de que la máquina docker le proporcione VM distintas.

Creo que el número 2294 o simplemente ser más higiénico con la máquina acoplable también solucionaría mis problemas.

También recomendaría ponerlo en la raíz del proyecto y tener un nombre de carpeta diferente.

En mi caso, me gustaría establecer el nombre del proyecto inicial porque tengo una máquina compartida en AWS y aunque tengo el docker-compose.yml en la raíz, un usuario puede clonar el repositorio en un directorio con un nombre diferente. Si eso sucede actualmente, entonces se encuentran con problemas para iniciar / detener contenedores.

Con la nueva sintaxis v2 esto podría implementarse como se menciona en https://github.com/docker/compose/issues/745#issuecomment -74028861

En realidad, es solo un container_name_prefix , ¿no?

@ schmunk42

En realidad, es solo un prefijo de nombre de contenedor, ¿no?

También se usa como volume_name_prefix , image_name_prefix y network_name_prefix , así que supongo que project_name es un término más genérico.

.docker-compose suena familiar a docker-compose.override.yml en muchos sentidos. Además, ¿por qué introducir otro formato de configuración (por ejemplo, ini) cuando ya tenemos YAML?
Por lo tanto, estoy a favor de la sugerencia de # 745 (comentario) de agregar una clave project_name al docker-compose.yml , para habilitar el caso de uso de @JosephEarl.

La personalización específica del usuario ya se puede implementar usando docker-compose.override.yml y excluyéndola a través de .gitignore .
Si se desea un tercer archivo de anulación explícitamente específico del usuario, sugeriría .docker-compose.local-override.yml .

Con respecto a la estructura del YAML, sugiero crear una nueva clave de nivel superior llamada project , que contiene project_name , y podría contener otras variables en el futuro. Esto evita contaminar el espacio de nombres de nivel superior. Para ilustrar:

project:
  project_name: "your-project"
  network_prefix: "abc"

Tenga en cuenta que, en lugar de usar network_prefix , puede ser más comprensible personalizar directamente los nombres de las redes. Según tengo entendido, hay dos casos:

• El primer caso es "simplemente dé a las redes un nombre único, pero no me importa cuál exactamente". Para este caso, project_name es suficiente.
• El otro caso son las redes a las que hacen referencia los sistemas externos. En este caso, probablemente sea mejor especificar explícitamente los nombres de las redes.

La propuesta sugerida anteriormente me suena bien, estoy de acuerdo en que no queremos introducir ningún archivo de configuración adicional

+1 en el concepto de este problema
Pero también +1 al usar una clave en docker-compose.yml lugar de agregar otro archivo a nuestros repositorios.

Para resumir los comentarios anteriores: Una propuesta para la secuencia de búsqueda del nombre del proyecto sería la siguiente; los elementos anteriores tienen prioridad sobre los posteriores:

1. Use --project-name si se especifica
2. Utilice COMPOSE_PROJECT_NAME si se especifica.
3. Utilice la tecla project_name de docker-compose.yml (o donde se almacene esa configuración).
4. Utilice basename del directorio del proyecto

No estoy seguro de la prioridad de 2 contra 3:

• Por coherencia con --project-name , COMPOSE_PROJECT_NAME definitivamente debe anular project_name: .
• Pero: Hacer que COMPOSE_PROJECT_NAME tenga prioridad sobre project_name: hace posible usar accidentalmente el nombre de proyecto incorrecto debido a la variable de entorno que se está configurando; esto puede ser difícil de depurar. ¿Quizás un mensaje de advertencia puede ser un problema en este caso?

¿Qué hay de introducir una nueva propiedad container_name_pattern con el valor predeterminado %(project_name)s_%(service_name)s_%(instance_number)s para mantener BC
este parámetro nos permite cambiarlo a hardcodedproject_%(service_name)s_%(instance_number)s y solucionar definitivamente este problema

Acabo de llegar este número después de buscar esta funcionalidad durante 10 minutos.

Lo primero que hice fue buscar la clave correcta en el documento Redactar archivo de referencia, así que +1 para project_name clave en docker-compose.yml

: +1: para la estrategia @ cr7pt0gr4ph7

+1 para la estrategia @ cr7pt0gr4ph7

Compose tiene sintaxis para la sustitución de entornos. En lugar de usar una variable de entorno para el nombre del proyecto, ¿quizás dejar que las personas lo hagan ellos mismos si les importa?

Por otro lado, la máquina acoplable usa el final para decidir en qué máquina se construirá una compilación, por lo que tal vez el nombre del proyecto y el objetivo deberían funcionar de la misma manera. Hmm, esta es una difícil.

https://github.com/docker/compose/issues/745#issuecomment -182296139 suena bien. La variable de entorno tendría prioridad sobre el valor en el archivo de redacción, que actúa como predeterminado (asumiendo que el nombre del proyecto pertenece al archivo de redacción).

Algo a considerar, ¿qué sucede cuando usas varios archivos de redacción y cada uno define un nombre de proyecto?

No creo que deba ser un error, que obligaría a los archivos a ser "primarios" o "extras", lo que no es el caso en este momento. Cualquier archivo se puede utilizar de forma aislada o en combinación con otros.

Tal vez una advertencia sea razonable, o tal vez simplemente la ignoremos por completo (ya que el valor se puede ignorar configurando una opción o variable de entorno también).

Algo a considerar, ¿qué sucede cuando usas varios archivos de redacción y cada uno define un nombre de proyecto?

Si hace algo como docker-compose -f compose1.yml -f compose2.yml up y ambos archivos definen el nombre del proyecto, el nombre utilizado debe ser de compose2.yml .

Creo que todos están en una solución que ya me gusta: -) Es decir, project_name en docker-compose.yaml. Solo quiero mencionar otro caso de uso para tener el nombre del proyecto en el archivo docker-compose.yaml:

En las páginas HTTP 500 Internal Server Error en mi proyecto, le digo al desarrollador cómo solucionar o solucionar el problema, por ejemplo, le digo que puede zcat database-dump.tgz | docker exec -i projectname_db_1 psql si el servidor nota que no hay una base de datos PostgreSQL y usuario ha sido creado, y luego quiero elegir projectname yo mismo, de lo contrario, los mensajes de ayuda no se pueden copiar y pegar en la consola.

Acepte que debería haber una advertencia cuando COMPOSE_PROJECT_NAME anule el nombre del proyecto en compose.yml; este comportamiento tiene sentido según los comandos de Docker existentes, pero no es particularmente lógico ni obvio para un recién llegado.

+1 para la estrategia @ cr7pt0gr4ph7

Intenté buscar algo antes de abrir un problema yo mismo, ya que no pude encontrar nada.
+1 por project_name en el archivo docker.compose.yml. Con v2, creo que esto tiene cada vez más sentido.

Acepte que debería haber una advertencia cuando COMPOSE_PROJECT_NAME anule el nombre del proyecto en compose.yml; este comportamiento tiene sentido según los comandos de Docker existentes, pero no es particularmente lógico ni obvio para un recién llegado.

Es un comportamiento bastante normal que las variables de entorno anulen la configuración de configuración y que los argumentos de la línea de comandos anulen la configuración de configuración y las variables de entorno.
¿Realmente somos una advertencia por eso? No es como si alguien creara accidentalmente una variable de entorno llamada COMPOSE_PROJECT_NAME .

¿Estaría bien crear un PR que solo use project_name de docker-compose.yml para que esto funcione? ¿O queremos cosas adicionales como usar el project_name del último archivo yml referenciado inmediatamente?

¿Qué tal esto?

version: "2"
project:
    default_name: "app"

Cambiaré mi implementación (https://github.com/docker/compose/pull/3118) para este formato. Pero no estoy seguro de que sea necesaria la sección project ....

+1 esté interesado en ver esta función

@timgriffiths , parece que esto es posible en el último RC agregando un archivo de entorno a su proyecto:

• https://docs.docker.com/compose/env-file/
• https://github.com/docker/compose/releases/tag/1.7.0-rc1

@deizel Así que miré el archivo de entorno, pero todavía creo que hay un buen caso de uso para poder definir el nombre del proyecto dentro del archivo de redacción.

En nuestra situación, tenemos Prod, Staging, UAT, Dev componen archivos solo para poder iniciar una versión diferente de nuestra pila de aplicaciones, y a veces queremos colocar un entorno de Staging y UAT en el mismo enjambre, para que pueda usar el entorno variables o lo que no, pero eso depende de que el usuario recuerde configurar esto, donde, como si estuviera en el archivo de redacción, todo se registraría en el repositorio y podríamos mantener todo en línea y simple de explicar a todos los usuarios.

+1 Tenemos una situación en la que nuestro archivo de redacción tiene referencias a volúmenes remotos preconfigurados. Compose agrega automáticamente el nombre del proyecto a los nombres de los volúmenes que luego no se montan debido a que los nombres no coinciden. Ser capaz de establecer explícitamente el nombre del proyecto en el archivo yml de redacción haría que la convención de nomenclatura fuera mucho más obvia para los demás involucrados en el proyecto en lugar de ocultar variables de entorno en archivos externos oscuros que podrían variar entre entornos.

@edevenport en su caso, podría usar la opción externa de volúmenes con nombre:

# docker-compose.prod.yml
volumes
  dbdata:
    external:
      name: my-project-db-data

Gracias @fesor , debería haber entrado en más detalles. De hecho, estoy montando volúmenes de glusterfs usando una configuración similar a esta:

    ...
    volumes:
      - media:/data/media:ro

volumes:
  media:
    driver: glusterfs

En este caso, media convierte en projectname_media en el host y no se puede montar a menos que el volumen glusterfs se cree antes de tiempo con el nombre del proyecto. Había pensado montar los volúmenes de glusterfs en el host manualmente y usar external en el archivo docker-compose, pero preferiría no tener que hacerlo manualmente en todos los nodos antes de tiempo.

@edevenport Lo entiendo. Pero puede agregar este volumen manualmente con docker volume create y usarlo:

    volumes:
      - media:/data/media:ro

volumes:
  media:
    external:
      name: my-glusterfs-media

Por lo tanto, no es necesario cambiar de proyecto y deshacerse de los prefijos.

El caso de @timgriffiths es algo más complejo y no tiene soluciones alternativas. Utilizo un contenedor simple alrededor de docker-compose solo para no recordar los nombres de los proyectos.

@fesor, por lo que hemos resuelto el problema simplemente pegando los archivos de

@timgriffiths Hice un PR (https://github.com/docker/compose/pull/3118); tal vez esto ayude. Pero no maneja su caso si tiene varios archivos de redacción.

@fesor que PR sería perfecto, ¿existe la posibilidad de fusionarlo?

Ahora Compose proporciona un archivo de entorno , por lo que el nombre del proyecto se puede conservar allí.

@mkuzmin es triste que haya COMPOSE_FILE pero no hay COMPOSE_OVERRIDE_FILE .

@fesor AFAIK puede especificar varios archivos

@ schmunk42 También podría especificar el nombre del proyecto. Pero esto no resuelve el problema. Quiero tener en el script de implementación algo como esto:

docker-compose up -d

en vez de

docker-compose -f $COMPOSE_FILE -f $COMPOSE_OVERRIDE_FILE \
            up -d

COMPOSE_PROJECT_NAME en el ejemplo anterior es especificado por CI. Y una característica como .env file es genial pero ... inútil en caso de persistencia del nombre del proyecto.

Utilizo .env para DRY env variables (y para docker-compose <1.7 tengo un contenedor simple), pero no resuelve ningún otro problema. @timgriffiths ya señaló el caso con la implementación en el clúster de enjambre.

COMPOSE_FILE=one.yml:two.yml es cómo configurar varios archivos. Así que solo incluye el archivo de anulación en $COMPOSE_FILE

@dnephin se perdió esa característica, genial.

Bueno ... sobre la implementación de enjambres, ya lo estoy manejando a través de COMPOSE_PROJECT_NAME en las variables ENV de mi trabajo de jenkin, por lo que solo tengo problemas con la implementación manual. Y mi implementación no permite que se anule el nombre del proyecto predeterminado, así que ...

Este problema tiene casi 2 años y aún no se ha resuelto. Me pregunto qué es exactamente lo que impide que el equipo de Docker finalmente agregue una solución adecuada. ¿Es realmente tan difícil agregar una nueva directiva de configuración simple para los archivos docker-compose.yml ?

Si bien la solución con .env es buena, no siempre se puede usar (es posible que su aplicación ya esté usando el archivo .env ). Y también sigue siendo una solución.

E incluso he visto otros problemas nuevos que pueden estar relacionados con el nombre del proyecto en las últimas versiones (# 3966).

Entonces, ¿cuál es el problema realmente?

¿Es realmente tan difícil agregar una nueva directiva de configuración simple para los archivos docker-compose.yml ?

¡No! El problema nunca ha sido la dificultad de implementación.

Si bien la solución con .env es buena, no siempre se puede usar (es posible que su aplicación ya esté usando el archivo .env ). Y también sigue siendo una solución.

No es una solución alternativa, ¡es una solución! El archivo .env contiene variables de entorno que Compose debe leer. Si tiene variables de entorno que su aplicación debe leer, colóquelas en un archivo diferente (por ejemplo, app.env ) y haga referencia a ellas con la opción env_file .

Entonces, ¿cuál es el problema realmente?

Agregar el nombre del proyecto a un archivo docker-compose.yml hace menos portátil, lo cual no es algo que queremos fomentar. Ahora que hay una manera (con .env ) de especificar persistentemente el nombre del proyecto sin sacrificar la portabilidad de docker-compose.yml , el caso para agregarlo como una opción de configuración es más débil. Esa es la razón principal por la que este problema no se ha movido.

Agregar el nombre del proyecto a un archivo docker-compose.yml lo hace menos portátil,

¿No podría ser esto opcional? Personalmente, nunca reviso mi docker-compose.yml solo proporciono un docker-compose-example.yml en mi repositorio que modifico localmente. Por ejemplo, durante el desarrollo, puedo agregar algunas variables de entorno adicionales o asignar volúmenes adicionales a mi contenedor. ¿Por qué no darnos también la opción de especificar el nombre del proyecto?

Siguiendo su argumentación, también debe mover todas las opciones network a .env ya que normalmente no son portátiles y dependen de la configuración de red de su máquina host.

Dicho de otra manera: ¿Qué hace que el nombre del proyecto sea tan especial? Ya hay muchas otras opciones en docker-compose.yml que no son realmente portátiles. ¿Por qué no darle al desarrollador la opción de elegir lo que sea mejor para su caso de uso?

También creo que la opción debería estar disponible. A medida que el uso de Docker se generalice, los proyectos con un solo desarrollador que utilice la contenedorización dentro de su flujo de trabajo se volverán cada vez más comunes. En esos casos de uso, el nombre del proyecto es constante. Un buen ejemplo de otro proyecto que permite una flexibilidad como esta es vagabundo con su Vagrantfile . Se dan cuenta de que ciertamente hay casos de uso para equipos grandes, pero también reconocen los escenarios de desarrolladores de lobo solitario.

Creo que implementar una opción de nombre de proyecto aquí es importante para su adopción. Podría desanimar a los desarrolladores individuales que no se preocupan por una "estrategia de configuración de nombre de proyecto escalable".

Agregar el nombre del proyecto a un archivo docker-compose.yml lo hace menos portátil, lo cual no es algo que queremos alentar. Ahora que hay una forma (con .env) de especificar persistentemente el nombre del proyecto sin sacrificar la portabilidad de docker-compose.yml, el caso para agregarlo como una opción de configuración es más débil. Esa es la razón principal por la que este problema no se ha movido.

¿Cómo agregar el nombre del proyecto a docker-compose.yml hace menos portátil?

En mi humilde opinión, en realidad es lo contrario, como lo muestra el # 3966 creado por @mikehaertl. Este problema muestra claramente que no tener el nombre del proyecto almacenado en docker-compose.yml hace que las cosas sean menos portátiles (como en: tener una mayor probabilidad de chocar con otros proyectos de redacción iniciados desde la misma máquina) ya que Compose se basa en una convención sobre el nombre de la carpeta contenedora que mucha gente, al menos inicialmente, no conocerá.

Agregar un archivo .env no solo agrega una cosa adicional para aprender para las personas nuevas que desean adoptar Compose, sino que también tendría que agregarlo a mi repositorio junto a docker-compose.yml para evitar estos colisiones No veo cómo eso sería diferente en cuanto a portabilidad que simplemente definir el nombre del proyecto en docker-compose.yml .

También estoy a favor de agregar el nombre en docker-compose.yml. El archivo .env se usa en otros marcos que uso y es importante que permanezca fuera del repositorio. Sin embargo, para mantener contenedores localizados entre mis desarrolladores, cuanto menos sepan sobre Docker (al principio), mejor. Quiero un punto de entrada simple que no choque con otros proyectos. No quiero explicar por qué las cosas son como son. Solo un simple

clonar repositorio
docker-componer

Mi solución alternativa ahora es crear el archivo que propuso @ schmunk42 .

El contenedor en sí no debería preocuparse por el nombre del proyecto. ¿Por qué usar variables de entorno como un mecanismo que solo debe preocuparle al host?

Me encantaría ver soporte para esto en el archivo docker-compose.yml . Si es necesario configurarlo a través de la variable de entorno, se puede definir dentro del archivo .env (si no se configura directamente en el host) y se puede utilizar mediante sustitución de variables en el archivo docker-compose.yml .

Si se permiten contenedores con nombre, ¿por qué no se permitirían los proyectos con nombre?

El caso de uso en el que una definición de nombre de proyecto en el archivo .yml sería útil es el siguiente:
Tenemos el mismo archivo docker-compose para diferentes servidores web (diferentes credenciales de base de datos, diferentes volúmenes de datos, algunas pequeñas diferencias como logotipo, etc.). Hay 3 servicios por aplicación en ejecución y están configurados en un archivo de redacción. Cuando se ejecutan varios servidores uno al lado del otro, sería bueno ver qué servicio pertenece a qué proyecto.

La sustitución de variables en el nombre del contenedor es útil, con $ COMPOSE_PROJECT_NAME como prefijo. Bueno, entiendo la solución de archivo .env, pero esto no la hace más "amigable para el desarrollador" en un entorno de implementación (CI).

Tener un contenedor de eliminación de docker-compose de un docker-compose totalmente diferente porque no había -p o el conjunto de variables de entorno y usted creó el docker-compose en una subcarpeta "docker" es un error crítico en mi opinión.

Simplemente, hay demasiado margen de error en implementaciones serias. Olvídese de especificar el nombre del proyecto, ya sea en -p, .env o en otro lugar: se desconecta durante un tiempo hasta que se da cuenta de lo que sucedió. Peor aún: el servicio de colisión se desconecta, no el que está trabajando. Tendrás un día feliz :(

@dnephin ¿Qué está

Tal vez soy el único aquí que tiene algunas preocupaciones con esto, pero de todos modos.
En nuestra configuración, modificamos solo los archivos .env y app.env para cambiar de entorno, pero esto se basa en tener varios archivos y fusionar archivos yml .

Si esto se implementa, piense en BC.

P.ej. si el nombre de un proyecto está definido en docker-compose.yml y .env este último debería tener prioridad. De lo contrario, las personas que dependen de administrar esto a través de .env , tienen problemas similares con las pilas superpuestas, como con el flujo de trabajo actual y confiando en los nombres de las carpetas.

@ schmunk42 No estamos diciendo que la función .env deba eliminarse. Si prefiere tener el nombre de su proyecto en .env , simplemente no lo configure en docker-compose.yml .

Pero otros prefieren tenerlo en su docker-compose.yml como muestra claramente la discusión aquí. Deberían poder hacerlo, si así lo desean. Es una característica opcional. Lo que prima si se configuran ambos es cuestión de definir una simple convención.

Atentamente, agregue proyectos con nombre. Caso de uso:
Proyecto uno:
docker-compose up --build --remove-orphans

• nginx
• contenido estático
  Proyecto dos:
  docker-compose up --build --remove-orphans
• nginx
• contenido estático

Cuando el proyecto dos comienza, mata los contenedores del proyecto uno con una salida 137 (código 128 + nivel 9).

Ahora tengo que ejecutar docker system prune y reconstruir redes todos los días para evitar tener docenas de contenedores muertos.

export COMPOSE_PROJECT_NAME=somethingnew

¿Puede alguien del equipo central finalmente explicar qué está retrasando esta característica? Es muy frustrante cómo se bloquean cosas que son tan fáciles de arreglar sin una buena razón.

El único argumento hasta ahora era mantener el docker-compose.yml portátil. Esto no tiene sentido, porque

• el nombre del proyecto en el archivo del compositor ya no lo hace automáticamente portátil
• ni todo el mundo tiene este requisito
  
  
  
  • ya tenemos otras opciones que pueden limitar la portabilidad de la misma manera: networks , port , ...
  
  

Todo depende en gran medida del caso de uso específico. Pero el hecho de que algunos no quieran esta opción no debería significar que todos tengan que seguir su opinión.

@mikehaertl Ya tienes nombres de proyectos persistentes. Simplemente coloque el archivo .env y configure la variable COMPOSE_PROJECT_NAME allí. Ya no veo ningún beneficio en el nombre del proyecto en el archivo de redacción.

@fesor Generalmente no tengo archivos .env bajo control de versiones porque contienen configuraciones específicas de la máquina / entorno; por eso también me gustaría ver que los nombres de los proyectos se puedan configurar en el archivo docker-compose.yml .

@fesor : Creo que @thasmo tiene razón en esto. El nombre del proyecto debe tener la opción de especificarse en el archivo compose.yml porque si es relevante para todos los desarrolladores que usan el proyecto, debe estar en control de versiones.

@fesor Lo siento, pero no creo que la preferencia personal sea un argumento real. La verdadera pregunta no es por qué no queremos usar .env o la variable de entorno. Es al revés: ¿Por qué no se colocó en el archivo de configuración al que pertenece?

Casi todas las opciones que puede pasar a docker en la línea de comando se pueden especificar en ese archivo. Solo el nombre del proyecto está excluido por algunas razones misteriosas. ¿Es esta una forma de apartheid entre argumentos? : ¡PI reclama los mismos derechos para todos! Deje que el desarrollador decida y no le imponga restricciones artificiales.

Y de nuevo: nadie te está quitando la opción anterior; solo finalmente queremos esta opción adicional. Eso es justo.

@dnephin : Parece que usted y todos los demás están contentos con la solución establecida en el refinamiento de cr7pt0gr4ph7 de este problema .

¿Estaría dispuesto a aceptar una solicitud de extracción que lo implemente, o tiene la intención de que uno de los mantenedores lo escriba?

@ cr7pt0gr4ph7

@dnephin @fesor tener el nombre del proyecto en * compose.yml facilita un esquema de configuración unificado

No tengo claro por qué es importante el nombre del proyecto. Ninguna parte del archivo de configuración debe depender de ningún nombre de proyecto específico.

La única cualidad importante del nombre del proyecto es que no entra en conflicto con el nombre de ningún otro proyecto, lo que en realidad es un argumento en contra de ponerlo en el archivo docker-compose.yml . Un desarrollador en un proyecto a menudo usará un nombre de directorio diferente para cada proyecto, por lo que el predeterminado suele ser correcto para la mayoría de los casos de uso.

Cuando el valor predeterminado no es correcto, hay una manera para que el desarrollador lo anule ( -p , o COMPOSE_PROJECT_NAME ), que pueden ser alias o poner en el archivo .env .

No estoy en contra de un archivo de proyecto que defina el nombre del proyecto, solo me gustaría entender por qué esta característica es tan crítica para algunos. Si es porque el archivo Compose requiere un nombre de proyecto específico, lo veo como un problema separado que debe abordarse de manera diferente,

Quería tener 4 archivos de composición en 1 directorio. El nombre del directorio es incorrecto por defecto aquí. La única opción que tengo es .env que solo funciona para 1 archivo de redacción en 1 directorio.

_Por qué descarto COMPOSE_PROJECT_NAME y -p: _
COMPOSE_PROJECT_NAME y -p, en mi opinión, no se guardan en producción, ya que debe recordar configurarlos. O cree una secuencia de comandos de inicio y recuerde no usar la ventana acoplable componer directamente. Cuando la Persona A confía en este mecanismo y la Persona B no lo sabe, eso es una falla cierta.
(Ya lo detallé arriba)

@dnephin Para mí y mi equipo, la lógica de la aplicación generalmente se almacena en una carpeta htdocs en nuestra carpeta de proyecto. Esto nos permite mantener otros documentos / recursos relacionados juntos en un directorio. Como desarrollador de operaciones con desarrolladores remotos. Es fácil para mí hacer que adopten Docker si no tengo que asumir nada sobre su estructura de carpetas. He dicho esto en el pasado, .env no es una opción para mí porque generalmente no es parte del repositorio que todos compartimos.

No tengo claro por qué es importante el nombre del proyecto. Ninguna parte del archivo de configuración debe depender de ningún nombre de proyecto específico.

Me pasó más de una vez, que hice un 'docker-compose down' en un host, ¡y tuve un contenedor diferente al que quería! Solo porque no lo recordaba, también había configuración en un archivo .env .

La única cualidad importante del nombre del proyecto es que no entra en conflicto con el nombre de ningún otro proyecto, lo que en realidad es un argumento en contra de ponerlo en el archivo docker-compose.yml. Un desarrollador en un proyecto a menudo usará un nombre de directorio diferente para cada proyecto, por lo que el predeterminado suele ser correcto para la mayoría de los casos de uso.

Quizás eso sea cierto para ti , no lo es para mí y para muchos otros. La estructura de mi aplicación es como myapp/app/docker-compose.yml . Entonces, todas mis aplicaciones comparten el nombre de directorio app . Y tengo más de 1 contenedor en un host.

Cuando el valor predeterminado no es correcto, el desarrollador tiene una forma de anularlo (-p o COMPOSE_PROJECT_NAME), que puede ser un alias o ponerlo en el archivo .env.

En serio, empiezo a sentir que estoy en una novela de Kafka aquí. ¿No es obvio que puede poner básicamente todas las opciones de la línea de comandos para docker en un docker-compose.yml , excepto por esta gran excepción?

En lugar de preguntarnos una y otra vez e ignorar nuestras respuestas, ¿por qué alguien no puede finalmente justificar la resistencia? Y no: "... pero no lo necesito" ¡no es un argumento válido!

@dnephin Tengo varios proyectos en sus propios repositorios git y para mantener limpios los directorios del proyecto raíz, coloco todas las cosas relacionadas con Docker en una subcarpeta llamada docker (el contexto de compilación se convierte en .. , todo funciona maravillosamente).

Para ejecutar varios proyectos en un solo servidor, actualmente tengo que crear docker/.env.dist en cada repositorio y cp docker/.env.dist docker/.env después de git clone . De lo contrario, el nombre del proyecto es solo docker , lo que obviamente no quiero. En algunos casos, .env contiene contraseñas, etc., por lo que se requiere copiar .env.dist todos modos, pero en la mayoría de los casos .env existe simplemente porque no hay forma de definir COMPOSE_PROJECT_NAME en docker-compose.yml .

Entiendo que puede haber fallas en la forma en que se inician y detienen los contenedores si el mismo COMPOSE_PROJECT_NAME se usa dos veces dentro de docker-compose.yml , pero eso ya está sucediendo si olvido copiar .env.dist o cuando asigno accidentalmente el mismo nombre en dos archivos .env en el mismo servidor. Para mí, sería ideal si pudiera definir default_compose_project_name directamente en docker-compose.yml y luego anular el valor en .env si, digamos que quiero ejecutar una copia provisional de algún proyecto . Esto sería 100% BC, pero más conveniente.

He dicho esto en el pasado, .env no es una opción para mí porque generalmente no es parte del repositorio que todos compartimos.

Tal vez, esa es la causa principal de todo, dije antes que docker-compose "secuestró" este archivo y nos vimos obligados a cambiar el nombre de nuestras cosas a app.env .

Quizás docker-compose.env hubiera sido la elección correcta.

FWIW: Solo estamos cambiando los archivos .env en producción, los archivos yml se fusionan con docker-compose.override.yml si es necesario.

Una solución alternativa es también definir sus archivos yml de una manera que no comiencen sin un archivo .env , por ejemplo. usando una variable image: $IMAGE .

Esta es una solución para mis 4 archivos acoplables: ¿componer archivos en 1 caso de directorio arriba de @ schmunk42 ? De Verdad?

@RobIsHere Pero necesitas usar -f todos modos, ¿verdad?

En respuesta a @dnephin en este comentario :

No tengo claro por qué es importante el nombre del proyecto.

Es importante porque afecta el nombre de los contenedores Docker que docker-compose administra. Si olvida establecer el nombre del proyecto, docker-compose ps no encontrará los contenedores que ha creado antes con docker-compose --project-name <project_name> up -d <container_name> .

Además, cuando ejecuta el comando global docker ps , el nombre del proyecto se incluirá en la lista de contenedores que se están ejecutando, para que sepa de dónde provienen. Por ejemplo, si está probando varios proyectos de código a la vez que todos usan MySQL y cada uno tiene un contenedor mysql , entonces docker ps mostrará una lista ambigua de contenedores. Por lo tanto, el nombre del proyecto es importante en el contexto de muchos proyectos de Docker que se ejecutan en la misma máquina.

Ninguna parte del archivo de configuración debe depender de ningún nombre de proyecto específico.

No tiene sentido tener que establecer el nombre del proyecto en un lugar diferente de _todas las demás variables asociadas con el proyecto de Docker Compose_.

La única cualidad importante del nombre del proyecto es que no entra en conflicto con el nombre de ningún otro proyecto, lo que en realidad es un argumento en contra de ponerlo en el archivo docker-compose.yml.

Por las razones expuestas en mi primer párrafo, esta no es la _ "única cualidad importante del nombre del proyecto" _. Es para facilitar su uso y comprensión.

Un desarrollador en un proyecto a menudo usará un nombre de directorio diferente para cada proyecto, por lo que el predeterminado suele ser correcto para la mayoría de los casos de uso.

En el caso no predeterminado en el que un desarrollador coloca _todos_ los archivos Docker relacionados en el directorio docker , que es una forma perfectamente razonable de organizar un proyecto Docker, la magia que establece el nombre del proyecto creará nombres de proyectos en conflicto. Entonces, los mismos conflictos que menciona ocurren en este caso en particular. No es necesario proteger al desarrollador contra las colisiones de nombres de proyectos cuando, de todos modos, establecen explícitamente el nombre del proyecto.

Cuando el valor predeterminado no es correcto, el desarrollador tiene una forma de anularlo (-p o COMPOSE_PROJECT_NAME), que puede ser un alias o ponerlo en el archivo .env.

Establecer variables de entorno es un nivel adicional de complejidad que no es necesario. Cuando comparte un proyecto entre desarrolladores con control de versiones, tiene sentido usar solo archivos. Tener que incluir parámetros de línea de comandos con cada invocación es tedioso y propenso a errores. Y el archivo .env no se puede compartir en el control de versiones porque se supone que contiene variables _específicas del usuario_, no _específicas del proyecto_. Por lo tanto, las formas actuales de establecer un nombre de proyecto son insuficientes.

No estoy en contra de un archivo de proyecto que defina el nombre del proyecto, solo me gustaría entender por qué esta característica es tan crítica para algunos. Si es porque el archivo Compose requiere un nombre de proyecto específico, lo veo como un problema separado que debe abordarse de manera diferente,

Todas las variables que afectan el funcionamiento de docker-compose deben ir en el mismo lugar, el archivo docker-compose.yml . Las formas actuales de establecer un nombre de proyecto introducen una complejidad innecesaria.

Casi todas las personas suscritas a este número están de acuerdo con estos puntos.

Agregar la capacidad de establecer el nombre del proyecto en docker-config.yml ni siquiera entrará en conflicto con ninguna funcionalidad actual. No hay razón para no implementarlo.

@ schmunk42 La última vez que verifiqué, Docker no nos permitió elegir el nombre de nuestro archivo .env. ¿Me perdí algo (es difícil mantenerse al día con los cambios)? Cambiarlo a algo como docker-compse.env lo arreglaría para mi caso de uso. El problema que tengo es que estoy usando dos tecnologías muy populares que requieren un archivo .env. El framework PHP Laravel no rastrea ese archivo en el repositorio y en entornos de producción a veces no existe.

Descubrí que esto era un verdadero bloque de stubbling cuando adopté Docker por primera vez porque, como lo ilustra myapp/htdocs/docker-compose.yml . En los primeros días, al adoptar Docker, eliminé accidentalmente otros contenedores que no tenía la intención de hacerlo. Hubiera sido mejor si la ventana acoplable nombrara su proyecto al azar en lugar de usar el nombre de la carpeta en mi caso.

Tengo varios otros desarrolladores remotos que están comenzando a adoptar Docker. Como equipo, siempre es más fácil para mí instruir a estos desarrolladores que siempre / solo docker-compose up para que estas aplicaciones se ejecuten. Cuanto menos sepan estos primeros usuarios sobre Docker, mejor. Una vez que vean el poder que hay detrás, lo aprenderán por sí mismos.

Entonces, para resumir, los casos de uso parecen ser cuando el valor predeterminado no es apropiado. Ya existen formas de anular el valor predeterminado, pero podrían ser propensas a errores y no obvias para los primeros usuarios.

Los casos en los que el valor predeterminado no es apropiado son:

• varios archivos de redacción en el mismo directorio (ya requiere que especifique -f para ejecutarlos)
• usando el mismo nombre de directorio para todos los proyectos (supongo que esto también requiere que especifique -f , la posible solución es usar un nombre de directorio único).

@dnephin Yo agregaría, un obstáculo menos posible para los primeros usuarios de Docker.

@dnephin También tenía estas preocupaciones en este comentario :

Originalmente quería el nombre en el docker-compose.yml, pero después de pensarlo más, realmente me gusta la idea de un archivo separado. Un archivo separado le da la opción de mantenerlo fuera del control de versiones si lo desea (para los casos en los que desea que cada usuario pueda tener un nombre de proyecto diferente).

Establecer el orden de precedencia de resolución del nombre del proyecto de esta manera resolverá ese problema (los números más grandes anulan los más pequeños):

1. docker-compose.yml
2. La variable de entorno COMPOSE_PROJECT_NAME
3. La opción de línea de comandos --project-name

La última vez que lo verifiqué, la ventana acoplable no nos permitió elegir el nombre de nuestro archivo .env.

@fiveanddone AFAIK no puede hacer eso, pero también movería el problema, ya que entonces tendría que saber qué archivo ENV necesitaría para el proyecto.

En nuestro caso con phd5 , movimos el (app) -environment a src/ y .env es únicamente el "control-environment-file", traté de explicar eso aquí .
No me gusta esto y no lo habría cambiado por mi cuenta. Sé que esto podría no ser posible para muchos proyectos.
Pero tener un .env de su aplicación en el mismo nivel que su docker-compose.yml vuelve súper molesto, porque a) obtiene variables en su "entorno de control" que no pertenecen allí yb) tiene que reenviar estas variables a su contenedor, si las necesita allí y c) ya no puede anularlas / cambiarlas en su archivo app.env .

@dnephin ¿Qué hay de introducir docker-compose.env como el archivo env preferido y usar .env como respaldo? Hiciste lo mismo con fig.yml una vez.

No creo que eso solucione el problema para todos. El nombre del archivo .env parece un problema diferente.

Creo que el meollo del problema es este:

El diseño original de docker-compose up era un comando único (corto) que se podía ejecutar para que los servicios se ejecutaran. Esto es lo que los desarrolladores esperan de él. Sin embargo, ese comportamiento no se puede lograr para algunos usuarios (en estos casos ).

Hay muchas formas de solucionar el problema, pero ninguna parece funcionar para todos.

Creo que el orden de precedencia (de mayor a menor) debe ser algo como esto:

1. --project-name (siempre anula)
2. COMPOSE_PROJECT_NAME variable de entorno
3. Un valor predeterminado definido por el usuario, separado de cualquier archivo versionado
4. Un valor predeterminado definido por el proyecto, que se puede registrar
5. El nombre del directorio (el predeterminado cuando no se especifica nada)

(3) se podría lograr con un archivo .docker/project-name (como se propone en el OP)
(4) podría lograrse con un campo en el archivo docker-compose.yml

Es lamentable que sea necesario que haya tantas formas diferentes de establecer el nombre del proyecto.

@dnephin con respecto a 3, permitir que un usuario establezca un valor predeterminado, para eso son las vars env, no es necesario crear un archivo

Hmm ... ¿Y si generalizamos un poco el problema y simplemente introducimos la sección default_environment en docker-compose.yml ? De esta forma podremos configurar COMPOSE_PROJECT_NAME sin introducir un campo especial en el yaml, pero también podremos definir otras variables predeterminadas, que probablemente estarán presentes en otras partes del archivo. Esto reducirá el número de casos en los que .env.dist necesita copiarse a .env y el costo de olvidarlo será menor.

Ejemplo de uso:

# ~/projects/sketches/sketch-42/docker/docker-compose.yml
version: "2"
default_environment:
  - SUBDOMAIN=sketch-42
  - ROOT_HOST=example.com
  - COMPOSE_PROJECT_NAME=sketch-42
services:
  web:
    build:
      context: ../
      dockerfile: docker/Dockerfile
    environment:
      - VIRTUAL_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - VIRTUAL_PORT=80
      - VIRTUAL_NETWORK=proxy
      - LETSENCRYPT_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - LETSENCRYPT_EMAIL=admin@${ROOT_HOST}
    restart: always
    networks:
      - proxy

networks:
  proxy:
    external:
      name: proxy

Este yaml es muy similar al que tengo muy a menudo: describe un boceto de vis, que siempre tiene un servicio llamado web , pero también puede respaldarse con un mini servidor API y tal vez un contenedor con una base de datos. Se supone que https://github.com/jwilder/nginx-proxy se encuentra al frente de todo y escucha los puertos reales 80 y 443.

Por el momento, no importa si estoy en una máquina local o en un servidor remoto, debo recordar mantener .env y también asegurarme de que _todas_ las variables de entorno estén configuradas allí. Si, digamos, me he olvidado de SUBDOMAIN , el contenedor se inicia, pero el servidor web permanece roto.

Con la sección default_environment a mi disposición, podría tener todas mis variables de producción en su lugar en un archivo y no tendría que copiar .env.dist cuando esté en el servidor. En la máquina local, en el ejemplo anterior, pondría una sola variable en .env , que sería ROOT_HOST=example.com.dev (¿o tal vez podría incluso export ROOT_HOST=example.com.dev en el perfil bash? )

Para resumir, la sección default_environment en docker-compose.yml no solo puede resolver el problema que estamos discutiendo actualmente, sino que también puede habilitar algunos trucos extra agradables, ¡además de ser 100% BC y fácil de entender!

WDYT?

Eso suena bien, puede resultarme útil en algunos escenarios.

Sin embargo, tenga en cuenta que a la luz de la discusión anterior (acalorada), su
solución se traduce aproximadamente a esto: "En lugar de agregar un nuevo archivo a la
yml, ¿qué tal si agregamos una nueva sección? " :)

El martes 28 de febrero de 2017 a las 00:02 Alexander Kachkaev [email protected]
escribió:

Hmm ... ¿Y si generalizamos un poco el problema y simplemente introducimos
sección default_env en docker-compose.yml. De esta manera definimos
COMPOSE_PROJECT_NAME sin introducir un campo especial en el yaml, pero
También podrá definir otras variables predeterminadas, que probablemente serán
presente en otras partes del archivo. Esto reducirá el número de casos
cuando .env.dist debe copiarse a .env y el costo de olvidarse de
hacerlo será menos.

Ejemplo de uso:

~ / proyectos / bocetos / sketch-42 / docker / docker-compose.yml

versión 2"
default_env:
SUBDOMAIN = croquis-42
ROOT_HOST = example.com
COMPOSE_PROJECT_NAME = sketch-42
servicios:
web:
construir:
contexto: ../
dockerfile: docker / Dockerfile
medio ambiente:
- VIRTUAL_HOST = $ {SUBDOMAIN}. $ {ROOT_HOST}, www. $ {SUBDOMAIN}. $ {ROOT_HOST}
- PUERTO_VIRTUAL = 80
- VIRTUAL_NETWORK = proxy
- LETSENCRYPT_HOST = $ {SUBDOMAIN}. $ {ROOT_HOST}, www. $ {SUBDOMAIN}. $ {ROOT_HOST}
- LETSENCRYPT_EMAIL = admin @ $ {ROOT_HOST}
reiniciar: siempre
redes:
- proxy

redes:
apoderado:
externo:
nombre: proxy

Este yaml es muy similar al que tengo muy a menudo: describe un vis
sketch, que siempre tiene un servicio llamado web, pero también se puede respaldar
por un mini servidor API y tal vez un contenedor con una base de datos. Es asumido
que https://github.com/jwilder/nginx-proxy se sienta al frente y escucha
a los puertos reales 80 y 443.

Por el momento, no importa si estoy en una máquina local o en un servidor remoto,
Necesito recordar mantener .env y también asegurarme de que todos
las variables de entorno se establecen allí. Si, digamos, me he olvidado
SUBDOMAIN, el contenedor se inicia, pero el servidor web permanece roto.

Con la sección default_env a mi disposición, podría tener toda mi producción
variables en su lugar y no tendría que copiar .env.dist en el servidor.
En la máquina local, simplemente pondría una variable en .env, que sería
ROOT_HOST = example.com.dev (o tal vez incluso podría exportar
ROOT_HOST = example.com.dev en el perfil de bash?)

Para resumir, la sección default_env en docker-compose.yml no solo puede
resolver el problema que discutimos ahora, pero también puede permitir algunos usos más agradables
escenarios!

WDYT?

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/compose/issues/745#issuecomment-282885661 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAQJJZumr10j3i17gPxrSyA-n8CwvsXTks5rg1X_gaJpZM4DLBNs
.

Tener el "project_name" dentro de docker-compose.yml resolvería un problema con nuestra pila.
Tenemos un repositorio monolítico con un árbol estandarizado que maneja múltiples proyectos, que se parece más o menos a esto:

projectA/infrastructure/docker-compose.yml
projectB/infrastructure/docker-compose.yml
...

Obviamente, es más complejo que eso en el mundo real, por lo que no podemos simplemente mover el archivo docker-compose.yml a la carpeta "projectA / projectB".

Tenemos una CLI en la raíz que pregunta qué proyectos arrancar, y dado que el nombre del proyecto depende directamente de la carpeta principal del docker_compose.yml, enfrentamos conflictos.

Como no escribimos nosotros mismos el comando docker-compose (incluido dentro de nuestro script CLI), no podemos simplemente agregar el argumento "-p" al comando manualmente.
Una solución para nosotros sería generar siempre un project_name dentro del script CLI para que siempre tengamos una "-p" al llamar a docker-compose, basado en la ruta absoluta, pero suena raro.

Un tipo aquí dijo "funciona la mayor parte del tiempo porque en la mayoría de los proyectos, el docker-compose.yml se encuentra dentro de la carpeta raíz del proyecto, y los proyectos tienen un nombre diferente, evitando conflictos", simplemente no puedo estar de acuerdo esta. No siempre está dentro de la carpeta raíz.

¿Por qué es posible definir el "nombre_contenedor" en un archivo docker-compose.yml (deshabilitando el escalado) para un servicio, pero no se puede definir un "nombre_proyecto" para el archivo docker-compose.yml en sí, al mismo nivel que "versión" / "servicios" / "redes" / "volúmenes"?

Esto parece necesario con el uso de scale para que los nombres de los contenedores sean obvios. (por ejemplo, <project_name>_<container_name>_1 ).

Esto ayudará cuando use el nombre del contenedor para dns.

Vine aquí con la esperanza de que esto se hiciera. Se fue decepcionado. 3 años +

Sí, es uno de los problemas de usabilidad más estúpidos de Docker y no se soluciona.

Pasamos mucho tiempo discutiendo con los desarrolladores al respecto, y aunque hubo consenso, no se admitió que sea un mal diseño.

Es frustrante porque hay un apoyo obvio de los usuarios para esto, pero como no encaja con los propios casos de uso de los desarrolladores, nos quedamos repitiendo este año tras año.

¿Cuál es el punto de docker-compose si necesitamos agregar opciones usando cli?
Tuve algunos contenedores sobrescritos gracias al esquema de nombres.

Hoy estaba configurando otro proyecto docker-compose con otro archivo .env para darle al proyecto un nombre persistente. Así que pensé en revisar este problema ya que han pasado algunos años desde la última vez que lo revisé. ¿Pero nada nuevo aquí por lo que puedo ver? Supongo que tendré que seguir usando la solución alternativa .env . Para mí, nombrar un proyecto en el archivo yaml parece lo más básico que puede hacer, pero supongo que hay algo sobre esto que simplemente no entiendo, ya que aún no se ha resuelto.

Tener que especificar el nombre del proyecto externamente (por línea de comando o variable) pero no poder configurarlo en el archivo docker-compose.yml , el archivo que especifica absolutamente todo lo demás, es simplemente absurdo. Hay muchos casos en los que un proceso puede necesitar abordar una pila específica de servicios en función de un archivo docker-compose.yml arbitrario, independientemente del nombre del directorio principal, el entorno de shell o la presencia de una línea específica en un .env específico docker-compose.yml para que mis trabajos puedan extraerlo y usarlo.

Esto parece suceder una y otra vez con este proyecto. Docker es una tecnología maravillosa, pero a veces me pregunto si los desarrolladores realmente tienen alguna experiencia en el mundo real, o si son solo piratas informáticos de 18 años que creen que saben más. La gente quiere usar estas cosas para un trabajo real, no perder su tiempo constantemente buscando soluciones.

Supongo que mientras tanto el equipo está ignorando este problema. Tratar de convencer a los desarrolladores de Docker puede ser un verdadero dolor de cabeza.

Los argumentos claros se contrarrestan con una lógica extraña que no tiene mucho sentido. Se ignora la opinión de los usuarios del mundo real de que todos vienen aquí por la misma razón. Es una pena.

No quiero que mis trabajos de CI tengan que "averiguar" continuamente cuál debería ser el nombre del proyecto; debería estar claramente indicado en el docker-compose.yml para que mis trabajos puedan extraerlo y utilizarlo.

¿Tiene el problema de que su pila se llame como "build1234" y / o cómo le gustaría usar el nombre de la pila en otro lugar, como docker exec build1234_myservice script.sh ?

Puede que no se ajuste a ningún caso de uso, pero por tenerlo dicho ...

En nuestras configuraciones solo cambiamos los archivos .env cuando configuramos un proyecto (clon). Si necesitamos cambios o una configuración dinámica, reutilizamos las variables de .env en docker-compose.yml . Una ventaja es que docker-compose le advierte (o falla) si falta una variable.

No quiero decirte que tienes que cambiar tus flujos de trabajo, porque también me molestó este problema.
Es básicamente algo así como, tratamos los cambios en docker-compose.yml más como cambios en el código fuente, mientras que .env es únicamente configuración. Pero también estoy de acuerdo en que hay varias opciones en docker-compose.yml , como network que dependen en gran medida del proyecto. Volviendo a lo anterior; Definiría una variable .env para la red. 🤐

No quiero decirte que tienes que cambiar tus flujos de trabajo, porque también me molestó este problema.

Pensé un poco más en mi propia situación. En realidad, no tengo un problema con la configuración externa del nombre del proyecto y, de hecho, hago esto con la bandera -p <project_name> , que hace posible aislar instancias únicas de la pila en CI y ejecutar varias pilas al mismo tiempo si necesario. Solo esa cadena de CI necesita saber el nombre del proyecto para que se pueda generar automáticamente o al azar (pero conocido), no hay problema. Tampoco tengo problemas con el uso de una variable de entorno para anular el nombre predeterminado, sin embargo, encuentro que el truco .env no es obvio.

Sin embargo, hay otras situaciones en las que es útil tener el _nombre predeterminado_ del proyecto definido explícitamente en algún lugar. Entonces, ¿por qué toma el nombre del directorio principal como fuente de este nombre? Ese, para mí, es el punto débil aquí. Se puede tomar desde cualquier lugar: la elección de un directorio principal parece arbitraria y sin mucha razón (por ejemplo, en casi todos mis proyectos, el archivo docker-compose.yml encuentra en un subdirectorio llamado docker ). Entonces, si va a ser arbitrario, guárdelo en un lugar que sea más explícito, como el archivo yml, en lugar de crear efectos secundarios externos al influir en los nombres del directorio principal, que en muchos casos deberían ser completamente independientes del contenido del directorio (basado en años de experiencia trabajando con recursos reutilizables).

Se puede tomar desde cualquier lugar: la elección de un directorio principal parece arbitraria y sin mucha razón (por ejemplo, en casi todos mis proyectos, el archivo docker-compose.yml se encuentra en un subdirectorio llamado docker).

Si necesita algo más que una identificación aleatoria, no veo una alternativa real al directorio principal. Al menos tienes la oportunidad de saber de dónde "vino" tu pila.
Pero también estoy de acuerdo con usted, ya que en nuestros proyectos hemos probado pilas en carpetas tests que, sin un archivo .env , también chocarían gravemente entre sí. Es por eso que propuse preferir un archivo llamado docker-compose.env que sería mucho más claro en mi humilde opinión.

¿Podrían cerrar este error admitiendo que no les importa o implementar lo increíblemente simple que la gran mayoría de nosotros queremos? Son 2,86 años después. Sal de la olla. Sea dueño de sus decisiones o corrija sus errores. Sin embargo usted quiere mirarlo. Haz más que nada.

@matsaman y todas las personas que dan su comentario con el pulgar hacia arriba:

¿Podrían cerrar este error admitiendo que no les importa o implementar lo increíblemente simple que la gran mayoría de nosotros queremos? Son 2,86 años después. Sal de la olla. Sea dueño de sus decisiones o corrija sus errores. Sin embargo usted quiere mirarlo. Haz más que nada.

Quienes son ustedes"? En código abierto, la comunidad es dueña de las decisiones y corrige los errores de los demás. Docker es de código abierto. Considere enviar una solicitud de extracción en lugar de quejarse.

A mí también me entristece que esto aún no se haya implementado. Pero, en el código abierto, contribuimos o esperamos con paciencia.

CLI arg:

$ cd foo
$ docker-compose up
$ docker-compose -p bar up
... some time later wanting to take down bar forgetting '-p'
$ docker-compose down
Stopping foo_nginx_1 ... done
Stopping foo_mysql_1 ... done
Removing foo_nginx_1 ... done
Removing foo_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

Fallar.

Archivo env:

$ cd foo
$ source foo.env
$ docker-compose up
$ source bar.env
$ docker-compose up
... some time later wanting to take down foo forgetting to `source .foo.env`
$ docker-compose down
Stopping bar_nginx_1 ... done
Stopping bar_mysql_1 ... done
Removing bar_nginx_1 ... done
Removing bar_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

Fallar.

Soluciones propuestas con el nombre del proyecto en el archivo yml:

$ cd foo
$ docker-compose -f foo.yml up
$ docker-compose -f bar.yml up
... some time later
$ docker-compose down
ERROR:
        Can't find a suitable configuration file in this directory or any
        parent. Are you in the right directory?

        Supported filenames: docker-compose.yml, docker-compose.yaml

¡Hurra!

$ COMPOSE_PROJECT_NAME=foo docker-compose up -d
$ COMPOSE_PROJECT_NAME=bar docker-compose up -d
... some time later
$ docker-compose down -v
Removing network project_default
WARNING: Network project_default not found.

O /

Quienes son ustedes"?

@benjaminwood Son los mantenedores de este proyecto. Su argumento tendría sentido si estuviéramos hablando de un cambio complejo y nadie encontraría el tiempo para hacerlo.

Este no es el caso bastante obvio aquí: la implementación probablemente sería muy fácil para aquellos familiarizados con el código base y mucho más difícil para alguien de fuera. Entonces, no es que nadie tenga tiempo para hacerlo, sino que los mantenedores no quieren hacerlo. Y esto es lo que los partidarios aquí encuentran extremadamente anhelante, dado el tiempo que este tema está abierto ahora y la masa de: +1: aquí.

Las soluciones que se publican una y otra vez aquí son bien conocidas, pero no se aplican a todos. Y todavía no pude encontrar una respuesta por qué, de todas las cosas, casi solo el nombre del proyecto se omitió en las características de docker-compose.yml . Si alguien piensa que no pertenece allí , ¡no lo use! Pero no oculte su opinión sobre los demás si la demanda es tan abrumadoramente obvia.

Veamos esto desde otro punto.

Si estoy en una carpeta con un archivo docker-compose.yml , ¿cómo puedo saber qué nombre de proyecto tiene mi pila?
Esa es una pregunta bastante básica, pero no hay una respuesta fácil.

Actualmente es (ordenado por prioridad):

• el valor de -p
• el valor de COMPOSE_PROJECT_NAME de su entorno
• el valor de COMPOSE_PROJECT_NAME de su archivo .env
• el nombre del directorio actual

Para ser el abogado del diablo, ¿por qué agregar un quinto a esta configuración ya confusa?

A pesar de la decisión de eso, debería haber una información de "ejecución en seco" sobre el nombre actual. Ni docker-compose config tiene eso, ni docker-compose ps si la pila no se está ejecutando.
Quizás docker-compose create es la mejor opción disponible actualmente, pero lejos de ser perfecta.

Debe haber al menos algo como docker-compose config --project-name . Actualmente necesito conocer las ubicaciones anteriores y verificarlas en el orden correcto.

Si estoy en una carpeta con un archivo docker-compose.yml, ¿cómo puedo saber qué nombre de proyecto tiene mi pila?

Una vez más: si no quieres usarlo, ¡no lo uses! Si está satisfecho con su solución, ¡ bien por usted! Nada cambiará para ti, ¡así que no te confundirás en absoluto!

¿Pero no puedes aceptar que los demás tienen requisitos diferentes? Todo lo que queremos es que finalmente se agregue esta pieza que, lógicamente, falta.

Para ser el abogado del diablo, ¿por qué agregar un quinto a esta configuración ya confusa?

La única razón por la que puede ser confuso es porque el nombre del proyecto se dejó fuera de docker-compose.yml en primer lugar. De lo contrario, todo estaría en ese archivo ahora. Podemos definir una lista de precedencia, no es un problema.

Actualmente necesito conocer las ubicaciones anteriores y verificarlas en el orden correcto.

¿Por qué no conoce el nombre de la ventana acoplable de su proyecto y por qué es incluso relevante para usted? ¿Y por qué no usas el mismo mecanismo en todos tus proyectos si te confunde tanto?

Una vez más: si no quieres usarlo, ¡no lo uses! Si está satisfecho con su solución, ¡bien por usted! Nada cambiará para ti, ¡así que no te confundirás en absoluto!

Mi pregunta no se refería al uso de una función nueva, sino a la falta de una existente. El nombre del proyecto es la única información relevante que docker-compose usa para iniciar y detener un determinado conjunto de contenedores.
Las personas en este hilo se quejan de eliminar los contenedores incorrectos, porque el nombre del proyecto no es parte de la pila.

¿Pero no puedes aceptar que los demás tienen requisitos diferentes? Todo lo que queremos es que finalmente se agregue esta pieza que, lógicamente, falta.

Si agrega esto, la gente se quejará de eliminar los contenedores incorrectos, porque es parte de la pila, ya que estaba usando el nombre del directorio de antemano.

La única razón por la que puede ser confuso es porque el nombre del proyecto se dejó fuera de docker-compose.yml en primer lugar. De lo contrario, todo estaría en ese archivo ahora. Podemos definir una lista de precedencia, no es un problema.

En realidad, no puede agregar esto de una manera BC, ya que tendría que tener una precedencia menor como nombre de directorio, lo que lo haría inútil. Por eso preguntaba "cómo obtener el nombre del proyecto".

¿Por qué no conoce el nombre de la ventana acoplable de su proyecto y por qué es incluso relevante para usted?

Porque normalmente uso el nombre del directorio, pero a veces un valor personalizado en .env , es relevante porque el nombre del proyecto define los contenedores en los que se ejecutan las acciones.

cd /some/path/test
docker-compose up -d
cd /a-completely-different-path
docker-compose -p test down -v --remove-orphans

Esto matará su primera pila, sería lo mismo con el nombre del proyecto en el archivo yml .

¿Y por qué no usas el mismo mecanismo en todos tus proyectos si te confunde tanto?

Sí, estoy usando las características predeterminadas docker-compose ; la mayoría de las veces, el nombre del directorio está bien, pero en caso de que necesite cambiarle el nombre, pero quiero seguir trabajando con el mismo conjunto de contenedores, agrego un archivo .env .

Si agrega esto, la gente se quejará de eliminar los contenedores incorrectos, porque es parte de la pila, ya que estaba usando el nombre del directorio de antemano.

Eso no tiene sentido. Si alguien no agrega el nombre del proyecto a docker-compose.yml nada cambiará. ¡Y si lo agregan es porque lo quieren allí! Nadie lo agregará a menos que lo necesite.

E incluso si lo hacen, todo está bien. No entiendo qué problema intentas construir aquí. Estás complicando demasiado las cosas.

Si combina todas las opciones en las que se puede configurar un nombre de proyecto, diría que este es su problema. No deberías hacer eso en absoluto.

3 de las 4 opciones en el árbol de prioridades no tienen valor una vez que tiene varios archivos de composición con nombre en un directorio. No me digas que cree subdirectorios, porque todavía comparto un archivo .env entre ellos.

No me digas que cree subdirectorios, porque todavía comparto un archivo .env entre ellos.

¿Comparte un archivo .env específico de la aplicación utilizado en env_file ?
¿O el que usa docker-compose ?
¿O los mezclas?

Eso no tiene sentido. Si alguien no agrega el nombre del proyecto a docker-compose.yml, nada cambiará.

Ese no es el problema, pero cuando se agregaría, el comportamiento cambia drásticamente.

Cuando copiamos una pila a un nuevo directorio para generar una instancia temporal (es decir, para probar una actualización), no tenemos que tocar docker-compose.yml en absoluto. Pero si esto es parte de la pila, tendríamos que decidir si lo anulamos con .env o si lo cambiamos en docker-compose.yml .

Sí, puede ser que no debería haber sido agregado en primer lugar, pero tener otra opción aquí tampoco hace las cosas más fáciles y concisas.

Tengo un archivo .env único común que usan 4 archivos de composición con nombre (en el mismo directorio). Sin variables de entorno. Sin scripts de shell. Yo uso solo componer.

Yo preferiria esto

docker-compose -f service1.yml up -d

En cambio, es más así

docker-compose -f service1.yml up -d
# F#&$, forgot the -p flag.   Curse the compose devs for 3 years of c#*$blocking
docker-compose -f service1.yml down
docker-compose -f service1.yml -p service1 up -d

@ schmunk42, ¿cree seriamente que es una solución escribir 'COMPOSE_PROJECT_NAME = ...' cada vez para cada comando de docker-compose, posiblemente además del nombre de archivo de composición? Eso también requiere que conozca y recuerde el nombre del proyecto. Ser capaz de especificar el nombre del proyecto en una variable de entorno tiene sus usos con seguridad, pero en algunos casos solo desea tener un directorio con un par de archivos yml y poder administrar proyectos fácilmente de una manera infalible sin tener que hacerlo. recuerde los nombres de los proyectos que eligió hace meses y sin tener que recordar exportar las variables de entorno.

¿No puede usar una carpeta por servicio y aún tener un archivo .env en la carpeta superior?

docker-compose -f service1/docker-compose.yml up -d
docker-compose -f service2/docker-compose.yml up -d

Simplemente escriba el nombre del proyecto en el archivo (-ruta) 😉

Me rindo. Es obvio que la base de clientes para esto ha cambiado.

Déjame saber qué hay de malo en la propuesta que te hice.

Tenía las mismas preocupaciones al principio, pero hemos ajustado nuestros flujos de trabajo a las funciones disponibles.

No recuerdo haber matado accidentalmente una pila en los últimos 2 años, por nadie de nuestro equipo. Estamos ejecutando> 200 pilas con alrededor de 1.000 contenedores y 1.000 de redistribuciones automáticas o manuales de esta manera.

Realmente no quiero involucrarme aquí ... pero no puedo resistirme.

Existe una diferencia muy importante entre una "solución" dada la forma en que están las cosas ahora, y la solución "correcta" dadas las posibilidades que existen. En lo que debería centrarse este problema es en encontrar la solución "correcta", que en lo que a mí respecta es bastante obvio, aunque algunos todavía podrían estar en desacuerdo.

@ schmunk42 y @mikehaertl

No recuerdo haber matado accidentalmente una pila en los últimos 2 años, por nadie de nuestro equipo .

Tengo que preguntar. Veo que ambos son parte de la organización codemix . ¿Sois compañeros de trabajo? Comenzando a preguntarme si detrás de escena ustedes dos están mal.

Actualmente es (ordenado por prioridad):

1. el valor de -p
2. el valor de COMPOSE_PROJECT_NAME de su entorno
3. el valor de COMPOSE_PROJECT_NAME de su archivo .env
4. el nombre del directorio actual

Para ser el abogado del diablo, ¿por qué agregar un quinto a esta configuración ya confusa?

El problema que veo es _cada valor único_ que está actualmente disponible para su uso es _específico del entorno_. No hay forma de proporcionar una opción específica para el proyecto.

1 + 2. Debe ser proporcionado manualmente por el usuario que invoca el comando.

1. _Podría_ compartirse, pero en la práctica .env debe ignorarse y no compartirse por una buena razón. (Soluciono esto compartiendo .env.example , pero esto aún requiere un paso manual adicional).
2. Es efectivamente aleatorio y específico del usuario / entorno. (También veo esto como una alternativa, porque redactar _needs_ un nombre de proyecto. Ni siquiera es una alternativa muy buena, porque podría haber proyectos en diferentes directorios con el mismo nombre que entrarían en conflicto)

En mi opinión, y en muchos de los que están en este hilo, debería haber una opción que viva entre 3 y 4, donde se puede proporcionar un nombre de proyecto predeterminado _can_ en cualquier archivo de docker-compose que se esté usando para este proyecto y se use como el primero retroceder. Este valor sería compartido por cualquiera que implemente este proyecto. Las opciones 1-3 anularían ese valor y la opción 4 solo se usaría si no se proporcionara.

@benjaminwood Puedo asegurarles que nadie se está riendo de este tema. Sí, nos conocemos desde hace bastante tiempo y no es la primera vez que estamos fundamentalmente en desacuerdo. Podría sonar molesto para varios usuarios aquí, pero no es mi intención. De hecho me gustaría compartir mis experiencias y proponer soluciones. Creo que tengo una vasta experiencia sobre este tema. Si la función se introdujera como se propone, introduciría una gran fuente de posibles errores en nuestra configuración.

@joshuajabbour

1. Podría compartirse, pero en la práctica .env debería ignorarse y no compartirse por una buena razón.

Eso depende de su configuración, tenemos esto ignorado en todos nuestros repositorios de proyectos.
Pero no lo ignoramos en nuestros repositorios de staging y producción solamente. Si comparte el nombre comprometido en docker-compose.yml , también puede confirmar .env (este archivo es solo para el comando docker-compose , nada más)

1. Es efectivamente aleatorio y específico del usuario / entorno.

No es más o menos aleatorio que un valor en docker-compose.yml , necesita ver la configuración de la pila como una carpeta, no como un solo archivo. Si lo hace, puede tener el nombre en .env o un nombre de subcarpeta.

Tengo una última alternativa para todos ustedes:

docker stack deploy -c docker-compose.yml the-project-name

(*) Solo disponible en modo enjambre

No veo cómo se podría colocar un nombre de proyecto en el archivo yml en el futuro, contradeciría totalmente la idea de una definición de pila.

Gracias @ schmunk42. Te creo y creo que has manejado las cosas bastante bien entre todas las fuertes opiniones que se muestran en este hilo.

introduciría una gran fuente de posibles errores en nuestra configuración.

Ahí está el problema. Cierra el problema.

Eso depende de su configuración, tenemos esto ignorado en todos nuestros repositorios de proyectos. Pero no lo ignoramos en nuestros repositorios de staging y producción solamente.

Entonces, ¿esta característica que todos los demás quieren no debería introducirse porque rompería su arquitectura de repositorio inusual?

Si comparte el nombre comprometido en docker-compose.yml , también puede confirmar .env (este archivo es solo para el comando docker-compose, nada más).

Bueno, si lo único en mi archivo .env era COMPOSE_PROJECT_NAME , entonces sí. Pero está lleno de muchas otras variables _secure_ que no quiero que se comprometan. Y los importo a docker-compose usando la propiedad environment . Para esto son generalmente los archivos .env ...

Realmente todavía no entiendo cómo esto rompería su configuración, ya que en mi propuesta solo anula el nombre del proyecto predeterminado tomado del directorio. Y si depende de eso (porque es un directorio comprometido _en_ ​​su repositorio en lugar del directorio en el que se clona su repositorio), entonces, ¿cómo podría ser anulado por la configuración de docker-compose.yml (porque eso también está comprometido a su repositorio; usted controla ambas cosas en su escenario)?

@ schmunk42 Lo que dices es "No quiero nuevas funciones, porque de lo contrario ya no entiendo la configuración de mi proyecto".

¿Seriamente? Este es su argumento de por qué quiere que todos los demás que necesitan esto se las arreglen sin él.

Solo para que conste: yo también estoy aquí. No dude en cerrar el problema. La discusión aquí se ha vuelto inútil.

Entonces, ¿esta característica que todos los demás quieren no debería introducirse porque rompería su arquitectura de repositorio inusual?

Expreso mi preocupación de que pueda introducir fuentes adicionales de errores.

Bueno, si lo único en mi archivo .env era COMPOSE_PROJECT_NAME, entonces sí. Pero está repleto de muchas otras variables seguras que no quiero comprometer. Y los importo a docker-compose usando la propiedad del entorno.

Use un secrets.env para esos e impórtelo a través de env_file .
¿Cómo afectaría eso a su flujo de trabajo?

Para esto son generalmente los archivos .env ...

Es cierto ... pero todavía creo que el problema es que docker-compose secuestra el archivo .env .

¿Cómo sería, si pudiera establecer estas variables más las que se usan en los niveles superiores de docker-compose.yml , como IMAGE_VERSION , en un archivo llamado docker-compose.env ?

Nunca me atreví a proponer COMPOSE_COMMAND_ENV_FILENAME=.env - hasta ahora :)

Realmente todavía no entiendo cómo esto rompería su configuración, ...

Es cierto que no se rompe de inmediato, pero se trata simplemente de mi primer punto, y de presentar aún más opciones.

Piense en usar varios archivos -f docker-compose.A.yml -f docker-compose.B.yml , digamos que A es su proyecto y depende del nombre del proyecto por directorio (¡lo hacemos, ya que lo controlamos!), Mientras que B es un conjunto de servicios adicionales con project_name: extra , introducidos accidentalmente durante la prueba en una carpeta que tenía un archivo .env que sobrescribía el nombre del proyecto con COMPOSE_PROJECT_NAME=testing .

Pero ahora cualquier proyecto, que se inicia sin un archivo .env , se llamaría extra . 💥

Estamos fusionando archivos en varios niveles, incluidos varios archivos *.env , es un caso de uso muy válido.

¿Seriamente? Este es su argumento de por qué quiere que todos los demás que necesitan esto se las arreglen sin él.

Advertencia: Ligeramente fuera de tema, pero aún relacionado con la ventana acoplable ...

• "No creo que realmente lo necesitemos"
• "tiene más capas de las necesarias. más complejidad"

@mikehaertl Realmente me pregunto que lo veas de esta manera;)

Hey gente,

Hemos retomado la apasionada discusión en este hilo (¡gracias a aquellos de ustedes que lo mantuvieron cortés y cordial!) Y aunque todavía creemos fundamentalmente que el nombre del proyecto no pertenece a un archivo de Redacción, se nos ocurrió creemos que es un término medio razonable con el siguiente PR: # 5378. Dicho esto, agradeceríamos sus comentarios sobre esto para asegurarnos de que responda a sus necesidades.

Aquí está la esencia:

• Puede agregar una entrada x-project-name dentro de su archivo de composición. Esta clave se ignora de forma predeterminada.
• Cuando se establece COMPOSE_X_PROJECT_NAME en su entorno (o archivo .env ), Compose intentará recuperar el nombre del proyecto de la entrada x-project-name dentro de su archivo Compose.
• Esta opción tiene una prioridad menor que COMPOSE_PROJECT_NAME y --project-name

Feliz de abordar cualquier pregunta o inquietud al respecto.

@ shin- ¿Entonces COMPOSE_X_PROJECT_NAME tendría que establecerse en 1 para activar la función?

Si es así, COMPOSE_ENABLE_X_PROJECT_NAME también podría ser un nombre en el que pensar, pero estos son solo mis 2 centavos, no lo usaré de todos modos 😄

@ schmunk42 Cualquier valor de "verdad" funcionará , pero sí, esa es la idea.

@matsaman Genial, gracias por los comentarios útiles y procesables.

En lugar de decirnos que tendremos que decirles a los usuarios finales que establezcan una variable o que llamen a un parámetro, nos está diciendo que tendremos que decirles a los usuarios finales que establezcan una variable o llamen a un parámetro.

Honestamente, y realmente no en vano, no puedo imaginar cómo has considerado esto como una solución de alguna manera.

@ shin- Explicaré cómo este cambio no hace ninguna diferencia útil:

Tener que establecer una variable de entorno para permitir buscar el nombre del proyecto en el archivo de redacción es aproximadamente el equivalente {cantidad de trabajo, riesgo de olvido y conveniencia}, como establecer una variable de entorno para el nombre del proyecto en sí.

El objetivo de establecer el nombre del proyecto en el archivo de redacción es evitar tener que usar variables de entorno. Puede utilizar la prioridad a la variable de entorno del nombre del proyecto para dar a los usuarios la opción de anular el nombre del proyecto en el archivo de redacción.

Creo que es una muy buena solución, ya que no romperá BC y evitará introducir errores durante la fusión como describí anteriormente.

Tener que establecer una variable de entorno para permitir buscar el nombre del proyecto en el archivo de redacción es aproximadamente el equivalente {cantidad de trabajo, riesgo de olvido y conveniencia}, como establecer una variable de entorno para el nombre del proyecto en sí.

No lo es, puede hacer esta configuración una vez, globalmente en su entorno; no es necesario que haga esto en todos los proyectos.

No lo es, puede hacer esta configuración una vez, globalmente en su entorno; no es necesario que haga esto en todos los proyectos.

Supongo que te refieres a globalmente en todos tus shells que generas en tu computadora. Si hace eso, podría tener un comportamiento no deseado en proyectos completamente ajenos. También causará confusión cuando un desarrollador extraiga un proyecto del control de versiones y se olvide de establecer la variable de entorno.

Uno de los objetivos más importantes de tener el nombre del proyecto en el archivo de redacción es garantizar que cada variable que tiene que ver con el proyecto de redacción se almacene en el control de versiones.

@nhooey @matsaman
Está destinado específicamente a ayudar a las personas que tienen varios archivos de redacción en el mismo directorio, para quienes la solución de archivos .env no es una opción. Si esto debe estar siempre activado para sus proyectos, es fácil configurarlo en su archivo .env , su .profile o en cualquier otro lugar que garantice que siempre se tomarán x-project-name en cuenta.

En lugar de decirnos que tendremos que decirles a los usuarios finales que establezcan una variable o que llamen a un parámetro, nos está diciendo que tendremos que decirles a los usuarios finales que establezcan una variable o llamen a un parámetro.

Nuestra principal preocupación con esto siempre ha sido que el "usuario final" tenga proyectos propios y quiera evitar conflictos de nombres a toda costa. En ese sentido, deben tener el control del nombre del proyecto, no del distribuidor. Si está enviando proyectos "llave en mano" a los clientes, es igualmente trivial establecer COMPOSE_X_PROJECT_NAME en el archivo .env asociado, así que estoy confundido sobre qué parte de esto es una preocupación para ser honesto.

Si hace eso, podría tener un comportamiento no deseado en proyectos completamente ajenos.

¿Podría darnos un ejemplo? No puedo pensar en ningún comportamiento no deseado simplemente configurando COMPOSE_X_PROJECT_NAME en mi shell.

Uno de los objetivos más importantes de tener el nombre del proyecto en el archivo de redacción es garantizar que cada variable que tiene que ver con el proyecto de redacción se almacene en el control de versiones.

¿Por qué no puedes usar .env para eso? Nadie prohíbe almacenar .env en el control de versiones (sí, no es común).

Teníamos .env al principio. Claramente te has perdido toda la conversación.

@matsaman Tienes que bajar el tono de tu actitud. Has sido desagradable desde que comenzaste a comentar en este hilo y, como resultado, no ha hecho más que empeorar la conversación. Si no puede ser cortés al compartir sus pensamientos, podemos prescindir de su opinión.

Para aclarar algo de la confusión

Ya podrías hacer eso

Anteriormente, podía establecer un nombre de proyecto mediante una variable de entorno. La nueva variable de entorno no es un nombre, es una palanca que habilitó una función que le permite establecer un nombre de proyecto en el archivo de redacción.

Supongo que te refieres a globalmente en todos tus shells que generas en tu computadora. Si hace eso, podría tener un comportamiento no deseado en proyectos completamente ajenos.

Si te refieres a "otros proyectos" como en "algo que no se componga podría leer esto y romper" creo que eso no es realista. Hay muchas variables de entorno establecidas en cada shell. La variable de entorno tiene el espacio de nombres adecuado como "COMPOSE_X_".

Si te refieres a "otros proyectos de composición", creo que en realidad estás argumentando por qué esta variable es necesaria. Si la función estuviera habilitada de forma predeterminada, cualquiera que confíe en el comportamiento predeterminado actual fallaría.

Si no es ninguno de esos, aclare.

También causará confusión cuando un desarrollador extraiga un proyecto del control de versiones y se olvide de establecer la variable de entorno.

Si un proyecto solo funciona con un nombre de proyecto específico, creo que hay otros problemas. Nunca debería haber un caso en el que un proyecto solo funcione con un solo nombre.

Veo esto como otro argumento para no poner el nombre del proyecto en el archivo Compose. Si el nombre del proyecto está en el archivo de redacción, cualquiera de los dos proyectos podría usar el mismo nombre, lo que provocaría un conflicto que rompería ambos proyectos. El nombre realmente debe ser establecido por el desarrollador que conoce qué otros nombres de proyectos ya están en uso.

Desafortunadamente, esto tampoco me ayudará por razones que ya mencioné hace más de un año.

Una solución que involucre variables ambientales requeriría que los usuarios sepan cómo hacerlas en primer lugar. Sé que puede parecer difícil de creer, pero no todo el mundo trabaja dentro de la terminal. Nuevamente, poner un .env en el repositorio no es una opción para mí.

La belleza de docker-compose es up . No hay instrucciones sobre cómo configurar esa llamada.

@fiveanddone

Nuevamente, poner un .env en el repositorio no es una opción para mí.

¿Se puede ampliar al respecto? Lo escucho totalmente sobre usuarios con conocimientos técnicos más bajos, pero si no están destinados a interactuar con el código o el entorno, ¿por qué es un problema incluir un archivo .env con el proyecto?

@ shin- Sí, no hay problema.

En algunos casos he incluido ese archivo en el repositorio, pero no funciona todo el tiempo. Mis casos de uso involucran principalmente desarrollo web donde el conocimiento técnico de los desarrolladores puede variar enormemente.

El .env contiene parámetros que se utilizan en otros marcos. Algunas de las variables dentro de mi .env son credenciales para servicios externos como SMTP. La mayoría de los desarrolladores de mi equipo apuntan esos servicios a sus propios puntos finales utilizando su propio archivo .env . Si el .env no está allí, tengo valores predeterminados.

Para los desarrolladores menos técnicos que quizás solo quieran cambiar algo de CSS, la aplicación funciona bien sin el archivo .env . Eso es asumiendo que no nombran todas las carpetas del proyecto de la misma manera. :)

Puede que no parezca mucho, pero cuando trabajas con varios desarrolladores y diseñadores en todo el país, cuanto más simple, mejor.

Docker me ha hecho la vida mucho más fácil y estoy muy agradecido por este proyecto, pero puedo identificarme con las frustraciones en torno a este hilo.

@fiveanddone ¡ Gracias por la información! Entonces, si el archivo .env se llamara docker-compose.env (o similar), ¿aliviaría eso sus preocupaciones?

@espinilla-

Sí, lo sería para mis casos de uso.

¿Docker Compose carga automáticamente el archivo env?

Si no es así, ¿se podría cargar docker-compose.env automáticamente?

@nhooey El archivo env se carga automáticamente si se llama .env . Y también puede especificar el archivo env para cada servicio individualmente. Ver documentos .

El archivo env se carga automáticamente si se llama .env. Y también puede especificar el archivo env para cada servicio individualmente. Ver documentos.

No quiero ser el quisquilloso aquí, pero eso no es realmente correcto. Y en mi humilde opinión, la mayor fuente de malentendidos de todo el tema.

Ninguna de las variables de .env se pasa a través de un contenedor / servicio, si no lo reenvía explícitamente , mediante el uso de

env_file: 
  - .env

o

environment:
  - VAR_FROM_DOTENV
  - FOO=${ANOTHER_VAR_FROM_DOTENV}

El archivo .env se carga automáticamente, sí, pero sin más configuración solo se aplica a estas variables de entorno Compose CLI .

Apoyaría firmemente el cambio de nombre de eso a docker-compose.env de forma predeterminada e incluso mejor, una variable para eso , por lo que esto podría usarse de una manera BC con solo establecer un ENV-var.

(¡gracias a aquellos de ustedes que lo mantuvieron cortés y cordial!)

Te escucho y seguramente soy culpable de no mantener siempre la compostura. Lo siento por eso. Algunos comentarios a veces realmente me ayudan a comenzar ... funcionarán en eso.

Si el nombre del proyecto está en el archivo de redacción, cualquiera de los dos proyectos podría usar el mismo nombre, lo que provocaría un conflicto que rompería ambos proyectos.

Nuestra principal preocupación con esto siempre ha sido que el "usuario final" tenga proyectos propios y quiera evitar conflictos de nombres a toda costa. En ese sentido, deben tener el control del nombre del proyecto, no del distribuidor.

@ shin- Esto suena como se acuerda comúnmente, que docker-compose.yml siempre es parte de un proyecto y vive en el repositorio del proyecto. Yo diría que eso no es necesariamente cierto. Algunos de nosotros no compartimos docker-compose.yml pero queremos mantener su versión local con personalizaciones locales (por ejemplo, configuraciones de desarrollo, pruebas, etc.).

Y con respecto a "evitar conflictos de nombre": en lugar de un conflicto de nombre con el nombre del proyecto, ahora tenemos un conflicto de nombre (IMO) mucho más crítico en el nivel del sistema de archivos: .env es un nombre común que los proyectos usan para definir su configuración específica de la aplicación. No debe contaminarse con la configuración de la ventana acoplable a menos que un desarrollador realmente quiera hacer eso. Pero esta decisión debe dejarse en manos del desarrollador.

Aquí hay una sugerencia: ¿Qué tal agregar otras dos opciones para el nombre del proyecto y desaprobar el uso de .env en V4 de docker-compose.yml ? Uno es project_name en docker-compose.yml , otro es un archivo .dockerproject que solo contiene el nombre y nunca debe enviarse a un repositorio. Debe ser un archivo local.

Aquí está mi sugerencia de precedencia (la más alta primero):

• -p argumento CLI
• .dockerproject archivo
• project_name en docker-compose.yml (debe evitarse, si docker-compose.yml se distribuye con el proyecto)
• COMPOSE_PROJECT_NAME del medio ambiente
• COMPOSE_PROJECT_NAME de .env (obsoleto)
• nombre del directorio

De esta manera, los usuarios finales siempre pueden anular el nombre de un proyecto en .dockerproject incluso si alguien lo codificó en un docker-compose.yml distribuido.

ACTUALIZACIÓN: También podría vivir con el uso de .dockerenv o docker.env lugar de .dockerproject . Pero debería tener mayor precedencia para resolver el problema, que algunos aquí necesitan anular los nombres de proyectos codificados en docker-compose.yml .

Hola a todos,

Primero que nada, gracias @dnephin y @ shin- por ver este caso. El cambio que @ shin- ha enviado parece un gran paso para resolver este problema.

He validado el PR 5378 en el proyecto de prueba para el siguiente caso de uso: A default project name defined by the project, that can be checked in (https://github.com/docker/compose/issues/745#issuecomment-282858900). Para eso hice un repositorio de git que ilustra diferentes posibilidades: https://github.com/estarter/compose_745

Encontré PR # 5378 cubriendo el caso de uso parcialmente. El problema es que la solución requiere la variable COMPOSE_X_PROJECT_NAME env. Soluciones posibles:

1. persiste la variable env en la carpeta del proyecto. Probé .env file pero no funciona cuando se llama a docker-compose desde otra ubicación (ver ejemplo de comandos , componer archivos )
2. definir COMPOSE_X_PROJECT_NAME globalmente (.profile o equivalente). Eso funcionaría pero no se puede especificar en el proyecto, es decir, no es una solución para nuestro caso de uso defined by the project, that can be checked in
3. hay otra opcion?

Con suerte, logré ilustrar el caso de uso que se aborda aquí.

Estimados mantenedores, consideren cómo el caso de uso se resuelve con PR # 5369, que introduce la propiedad opcional project_name en el archivo docker-compose. Esta propiedad tiene una prioridad baja pero no depende del entorno o del directorio de trabajo.

1. hay otra opcion?

Existe esta opción docker-compose --project-directory <PATH> (Especifique un directorio de trabajo alternativo). También debería funcionar con un archivo .env .

Para agregar otro caso de uso matizado a la mezcla:
En mi caso de uso, tengo dos repositorios, uno para el proyecto principal (usado para compilar / implementar) y otro para devops (que contiene Dockerfile's, docker-compose.yml, etc.)
En nuestra configuración actual, el repositorio principal del proyecto está en la raíz ./ y el repositorio devops está desprotegido en un subdirectorio ./devops/

En esta configuración, el uso de un archivo .env no funciona porque debe ser:

colocado en la carpeta donde se ejecuta el comando docker-compose (directorio de trabajo actual).
(ref. doc)

Lo cual no funciona, ya que se invoca como: docker-compose -f devops/docker-compose.yml
Por supuesto, podemos agregar el parámetro -p aquí, que es lo que estamos usando actualmente, pero es propenso a errores humanos como se mencionó anteriormente.

Si el archivo .env (o el archivo docker-compose.env propuesto) pudiera leerse desde el mismo directorio donde vive el docker-compose.yml, entonces definir el nombre del proyecto allí funcionaría para mí.

El uso de la directiva env_file dentro de docker-compose.yml no funciona, porque esas variables env solo se aplican dentro del contenedor, no a la creación de los contenedores.

En última instancia, mi objetivo es mantener mis archivos relacionados con devops autocontenidos de una manera que no contamine la base de código de mi proyecto real, pero aún se puede acceder / ejecutar en paralelo con ese repositorio.

Existe esta opción docker-compose --project-directory(Especifique un directorio de trabajo alternativo). También debería funcionar con un archivo .env.

@ schmunk42 podría ser una buena --project-directory no funciona para el archivo .env. Intenté lo siguiente, el archivo .env se ha ignorado ( archivos de proyecto ):

docker-compose -f PR_5378/docker-compose.yml -f PR_5378/docker-compose2.yml --project-directory PR_5378 down

En el futuro, eliminaré los comentarios que no contribuyan a la conversación de una manera constructiva. No tengo ningún interés en interactuar con los niños.

Sobre tener un .env nombre configurable
El problema de tener una variable de entorno que designe qué archivo .env usar es que se trata esencialmente de una dependencia circular. Tendríamos que introducir una excepción en la forma en que se interpretan las variables de entorno que, si bien es sensato, es inherentemente contrario a la intuición.

En el propio nombre .env
A estas alturas es obvio que el nombre .env es utilizado por una multitud de software y marcos, y por lo general no está destinado a ser comprometido en el control de versiones. Somos muy sensibles a hacer cambios importantes, pero podríamos introducir un nombre alternativo (por ejemplo, docker-compose.env ) con un respaldo al archivo .env si el primero no existe, con la intención de que se puede compartir con otros usuarios.

Al agregar project_name al archivo de composición
Ya hemos reiterado nuestra postura sobre esto varias veces; vea el último comentario de Daniel para conocer algunas de las razones por las que nos oponemos a hacer ese cambio. No es que sea difícil. No es que no lo hayamos pensado. Pasamos mucho tiempo evaluándolo y sentimos que la calidad del proyecto sufriría demasiado como resultado como para justificar agregarlo (de esta forma). Hablando de manera realista, # 5378 es probablemente la mejor concesión que podemos hacer para que esto funcione de una manera que sea opt-in y compatible con versiones anteriores (EDITAR: Por supuesto, estoy abierto a sugerencias que mejoren esa propuesta dentro de estos parámetros)

En --project-directory
Un poco tangente, pero soy consciente de que esta opción está un poco rota en este momento. En retrospectiva, hubiera preferido no agregarlo en absoluto, porque crea más problemas de los que resuelve. Intentaré pasar un tiempo para ver si se puede arreglar, pero tiene muchos casos extremos extraños que lo hacen realmente poco confiable.

Con todo lo dicho, ¿hay alguien para quien docker-compose.env + # 5378 no sería una solución satisfactoria? Entiendo que puede que no sea su solución favorita, pero le pregunto si está haciendo concesiones razonables a las que pueda hacer frente.

Bromas aparte ...

Sigo sin entender cómo se relaciona el último comentario de Daniel con la "calidad del proyecto". Además, es una regla general que agregar una clave a un diccionario nunca debe causar una falla en la compatibilidad con versiones anteriores. Siempre hay casos en los que los programadores han implementado cosas de una manera que este no es el caso, pero estoy divagando.

Creo que el campo que quiere el campo project-name (o lo que sea) está justificado, ya que el "nombre" del proyecto es fundamental para muchos aspectos de las herramientas. Las personas en este campo pueden querer simplemente escribir este nombre en algún lugar de piedra para evitar problemas con soluciones más temporales como variables de entorno o comandos como banderas.

Espero que esto haya sido constructivo.

@estarter Consideraría esto un error, tal vez valga la pena abrir un problema separado para él

En realidad, esperaría que esto funcione con el archivo .env en el directorio PR_5378 :

docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

Al agregar project_name al archivo Compose

@ shin- Parece que la decisión ya está tomada. Pero sigo intentando comprender el trasfondo. Pregunté esto antes y nunca obtuve una respuesta (que es una de las razones por las que la discusión me resultó tan molesta).

¿Podría ayudarme a entender por qué tenemos container_name e incluso network en docker-compose.yml ? El primero también podría ser fuente de posibles conflictos. Y este último es muy específico del anfitrión. Siguiendo su lógica, esos dos (y otros) tampoco deberían estar allí. No veo la diferencia con project_name .

Por favor, no vuelva a ignorar esta pregunta.

@ michael-k ¿Estás diciendo que project_name es lo mismo que container_name ? Si lo dice, me gustaría informarle que un proyecto puede constar de varios contenedores. ¿O te he entendido mal?

Mientras que por network , no es necesariamente específico del host. Hay muchos casos en los que un proyecto requiere una red central aislada en la que un contenedor interactúa con otra red. Y sus configuraciones se almacenan en docker-compose.yml .

@AyushyaChitransh No lo container_name , network y otros en docker-compose.yml mientras que project_name no deberían estar allí? Todos comparten el mismo potencial de conflicto o configuración específica de host que no debe compartirse.

@aanand conozco esta oportunidad. Además, se podría decir lo mismo sobre los nombres de los contenedores, pero tenemos la oportunidad de establecer el nombre del contenedor en el archivo de redacción, ¿verdad?

Sí, pero no creo que agregar eso sea una buena idea.

De la discusión relacionada Especifique el nombre de la red en el archivo docker-compose .

@estarter Consideraría esto un error, tal vez valga la pena abrir un problema separado para él

@ schmunk42 veo que los mantenedores son conscientes de esto - vea On --project-directory en el comentario de Joffrey más # 4709, # 4933 y # 4841

En realidad, espero que esto funcione con el archivo .env en el directorio PR_5378:
docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

Supuso que --project-directory afecta el parámetro -f .
De hecho no es el caso, este comando da IOError: [Errno 2] No such file or directory: u'./docker-compose.yml'

Es muy bueno que --project-directory no afecte a -f ; de lo contrario, imagina lo que sería una pesadilla al usar --project-directory y varios archivos de composición acoplable en diferentes directorios.

Estoy muy sorprendido de ver tanta deliberación sobre algo que veo como un problema resuelto.

Este es el orden de precedencia que estoy acostumbrado a ver:

1. codificado
2. opción cli
3. medio ambiente
4. project.rc
5. sano por defecto

Para project_name actualmente no tenemos la opción # 1 ni la opción # 4. Este es el problema fundamental que enfrentan las personas y parece fácil de resolver de una manera compatible con versiones anteriores.

Parece que tenemos argumentos filosóficos sobre la pureza que pueden no ser útiles. El uso de un esquema de configuración en cascada OSS muy común, por otro lado, es muy útil.

Parece que tenemos argumentos filosóficos sobre la pureza que pueden no ser útiles.

Sin embargo, tener este argumento no es realmente el objetivo. Desde el principio , hemos tenido muy claro cuál es nuestra posición con respecto a la definición del nombre del proyecto en el archivo Compose.

Pero déjame ser transparente en esto. Esto nunca sucederá en docker-compose . Si esa es la única ruta de resolución que está dispuesto a aceptar para este problema, tendrá que seguir el mismo proceso de OSS de bifurcar el proyecto y hacerlo usted mismo. El código está disponible y se comparte con una licencia muy permisiva.

¿Podría ayudarme a comprender por qué tenemos container_name e incluso network en docker-compose.yml? El primero también podría ser fuente de posibles conflictos. Y este último es muy específico del anfitrión. Siguiendo su lógica, esos dos (y otros) tampoco deberían estar allí. No veo la diferencia con project_name.

Por container_name , esa opción se introdujo muy temprano en la vida útil del proyecto. Como señaló @ schmunk42 , si lo hiciéramos todo de nuevo, esto definitivamente no estaría en la especificación. Se usa indebidamente constantemente y ha sido la fuente de innumerables problemas para los usuarios a lo largo de los años.
En cuanto a network , no estoy del todo seguro de cómo se compara en tu mente.

¿Qué pasa con la opción # 4 que mencioné? Vi hablar de introducir un .docker-compose para configuraciones específicas del directorio local. Esto sería preferible (en mi opinión) a introducir los indicadores de entorno _x_ (que aún requieren gestión del entorno).

Sería así:

# <my-project-dir>/.docker-compose
project_name: foobar

Lo anterior es distinto de la opción de variable de entorno y está más abajo en la lista de precedencia.

Esto resuelve muy bien mi caso de uso y marca otra ruta de configuración estándar de la lista.

@thedeeno En nuestra mente, COMPOSE_PROJECT_NAME dentro del archivo .env ya logra eso (con el mismo orden de prioridad que tendría en su esquema). Sin embargo, hemos escuchado que .env es una mala elección de nombre, por lo que estamos considerando docker-compose.env como alternativa. ¿Eso funcionaría para ti?

En nuestra mente, COMPOSE_PROJECT_NAME dentro del archivo .env ya logra eso

@ shin- aquí es donde no estamos de acuerdo. No creo que lo haga.

Personalmente, me encanta que obtenemos el archivo .env . Este es un lugar muy convencional para colocar secretos locales y otra configuración específica de hardware local.

Esto funciona muy bien para ayudar con la configuración basada en el entorno number 3 anterior.

No nos da una trampilla de escape ( number 4 ) para cuando no queremos que el entorno sea el propietario del nombre del proyecto.

En mi caso, nuestros desarrolladores tendrán cada uno su propio archivo .env (no VC). Contiene secretos para inyectar en docker-compose.yaml . Me gusta esto.

Sin embargo, no queremos que los desarrolladores tengan control sobre el nombre del proyecto, ya que está fuertemente acoplado a algunas herramientas. Dado que .env no está en el control de versiones, tenemos que hacer que nuestros desarrolladores establezcan manualmente COMPOSE_PROJECT_NAME con este enfoque; y es la _una cosa_ no como las demás, porque no es un secreto.

Lamentablemente, no, simplemente cambiar la ruta de origen predeterminada de .env no nos ayudaría aquí. De hecho, nos encanta que .env se obtenga automáticamente. Simplemente no queremos especificar el nombre del proyecto de esa manera.

mostraré un caso de uso de mi práctica:

Estoy usando el archivo .env para especificar la versión de la imagen, y para evitar el análisis extraño de sed / awk / perl / lo que sea, simplemente sobreescribo el valor en CI:

    echo APP_VERSION=$CI_COMMIT_REF_NAME > .env
    docker-compose pull
    docker-compose up -d

más adelante en docker-compose.yml , la imagen se especifica como:

    image: my.registry.example.net/app:${APP_VERSION}

ahora, si necesito más variables de ese tipo, necesito hacer un análisis, a menos que se admitan varios archivos .env .

entonces, quizás también agregue soporte de "directorio", como: docker-compose.env.d/* o .docker-compose.env.d/* o docker-compose.d/* .

pero como tal glob puede crear instantáneamente problemas de copias de seguridad del editor coincidentes ( *~ , *.bak ) es mejor usar alguna extensión en su lugar: docker-compose.env.d/*.sh

... pero, de nuevo, tal vez solo hacerlo configurable en docker-compose.yml ¿qué archivos de nivel raíz .env están cargados, o eso introduciría un problema de huevo de gallina? No sé cómo funciona el analizador de configuración :)

un poco fuera de tema, pero COMPOSE_PROJECT_NAME env no permite un prefijo de control total, aún se eliminaría para que coincida con A-Za-z0-9_ ... quería usar - en mi prefijo. (No puedo encontrar dónde informé esto en este momento, pero afaik no está abordado)

Sería lógico permitir los mismos caracteres a los que la propia ventana acoplable se limita.

@glensc Eso es mucha infraestructura para administrar el medio ambiente. Personalmente, no creo que esa sea la responsabilidad de docker-compose .

Lo único que he visto hacer en otros proyectos es generar automáticamente .env

@glensc @thedeeno Entonces, idealmente, tendríamos dos archivos *.env , uno destinado a ser compartido con otros usuarios y otro privado, con el último anulando al primero cuando ambos definen la misma var?

Abordé los nombres configurables .env en mi comentario la semana pasada.

¡Tener un docker-compose.env (sin dejar de obtener un .env privado) funcionaría muy bien para nosotros!

Lo trataríamos como un archivo rc y lo confirmaríamos como control de código fuente.

Creo que tener archivos env públicos / privados probablemente resuelve la mayoría de los casos de uso que se mencionan aquí. si - también se permitiera en el nombre del proyecto, sería genial.

@thedeeno @glensc ¿Podría dar un caso de uso en el que necesite un archivo ENV privado que anule los valores del público?

Los secretos no deben definirse en docker-compose.env , ya que no se reenviarán automáticamente a los contenedores. Todavía puede usar un archivo .env y hacer lo que quiera con él. Pero me parece confuso mezclar configuraciones para docker-compose y contenedores en la pila.

@ schmunk42 No tengo ese caso de uso, así que no seré de mucha ayuda allí. Solo necesito enviar project_name al control de versiones. docker-compose.env resuelve eso.

No estoy seguro de seguir tu segundo párrafo. Usamos .env para los secretos y los inyectamos manualmente en docker-compose.yaml .

@ schmunk42 https://github.com/docker/compose/issues/745#issuecomment -346491062

es solo porque el ÚNICO lugar para definir ${variables} para image valor parece ser .env archivo.

@glensc ¡De acuerdo!

Pero en cambio, propondría docker-compose.override.env para alinearlo con la función de anulación actual para yml archivos.

docker-compose.env
docker-compose.override.env
docker-compose.override.yml
docker-compose.yml

No estoy seguro de seguir tu segundo párrafo. Usamos .env para los secretos y los inyectamos manualmente en docker-compose.yaml.

@thedeeno supongo que estás haciendo esto:

environment:
  - ${SECRET_VAR_FROM_DOTENV}

que también debería ser posible con docker-compose.override.env . O podrías hacer:

env_file:
  - .env

¿Está sugiriendo eliminar .env a favor de una ventana acoplable más específica?
¿camino?

Si omitimos el origen automático de .env, afectará negativamente a mi
flujo de trabajo del equipo. Confiamos en este archivo para otras herramientas. Terminaríamos
poniendo nuestros secretos en dos (.env y este otro archivo que estás sugiriendo)
lugares si docker-compose deja de mirar .env.

El jueves 23 de noviembre de 2017 a la 1:15 a. M. Tobias Munk [email protected]
escribió:

@glensc https://github.com/glensc ¡De acuerdo!

Pero en cambio, propondría docker-compose.override.env para alinearlo con
la función de anulación actual para archivos yml.

docker-compose.env
docker-compose.override.env
docker-compose.override.yml
docker-compose.yml

No estoy seguro de seguir tu segundo párrafo. Usamos .env para secretos y
Inyectarlos manualmente en docker-compose.yaml.

@thedeeno https://github.com/thedeeno Supongo que estás haciendo esto:

medio ambiente:

• $ {SECRET_VAR_FROM_DOTENV}

que también debería ser posible con docker-compose.override.env. O tu
podría hacer:

env_file:

• .env

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/compose/issues/745#issuecomment-346538315 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAFIdxtbI7y3wW2TFa401Go6Msj0gC74ks5s5Q1vgaJpZM4DLBNs
.

¿Está sugiriendo eliminar .env a favor de una ventana acoplable más específica?
¿camino?

No necesariamente, para BC docker-compose aún podría mirar .env si no se encuentran los otros, igual que con fig.yml una vez. Aunque puede resultar complicado decidir los siguientes casos:

.env
docker-compose.env

.env
docker-compose.override.env

.env
docker-compose.env
docker-compose.override.env

.env no se usaría en el último caso, pero no estoy seguro de cómo manejar los dos primeros, ya que algunos usuarios usarían .env como anulación, otros como alternativa.

Para mí .env debería usarse en todos los casos. Es un archivo con un significado especial
en el ecosistema más amplio.

En sus terceros casos, es solo el archivo con la precedencia más baja.

Todo lo que necesito es una forma de enviar el nombre de mi proyecto al control de código fuente. Yo no
se preocupan especialmente por el entorno en cascada más sofisticado
administración. De hecho, preferiría que esta estrategia de nombre de proyecto no tuviera nada que
hacer con las variables de entorno.

Si un archivo de configuración está fuera de la mesa y hay una manera de confirmar mi
project_name con esta cascada env de la que estás hablando, la usaré con gusto
¡aunque!

El jueves 23 de noviembre de 2017 a la 1:31 a. M. Tobias Munk [email protected]
escribió:

¿Está sugiriendo eliminar .env a favor de una ventana acoplable más específica?
¿camino?

No necesariamente, para BC docker-compose aún podría mirar .env si el
otros no se encuentran, igual que con fig.yml una vez. Aunque podría ser
Es complicado decidir los siguientes casos:

.env
docker-compose.env

.env
docker-compose.override.env

.env
docker-compose.env
docker-compose.override.env

.env no se usaría en el último caso, pero no estoy seguro de cómo manejar
a los dos primeros, ya que algunos usuarios usarían .env como anulación, otros como
retroceder.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/compose/issues/745#issuecomment-346539891 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAFId95kZQIsiWp488JyPQOtGJju0OPbks5s5RFbgaJpZM4DLBNs
.

En cuanto a la red, no estoy del todo seguro de cómo se compara en tu mente.

@espinilla-

services:
    web:
        build: ./
        networks:
            - my_project_network_on_my_localhost
networks:
    my_project_network_on_my_localhost:
        external: true

Supongo que lo estoy haciendo mal, porque nunca comprometo mi docker-compose.yml en mi repositorio. Siempre contiene configuraciones muy específicas de host. Puede tener un contenido bastante diferente en el desarrollo y la producción.

Soy un fan de "4 project.rc" aunque probablemente usaría algo como docker-project.yaml lugar de un formato diferente. Esto es exactamente lo que describe el número original. En lo que a mí respecta, cualquier discusión sobre poner el nombre del proyecto en el archivo de redacción debería estar en un tema separado.

Todo lo que necesito es una forma de enviar el nombre de mi proyecto al control de código fuente.

Este es todavía un punto que no entiendo. No debería haber ninguna razón para requerir un solo nombre de proyecto codificado. Si hay herramientas externas que esperan un nombre coherente, ¿por qué esas herramientas no establecen un nombre de proyecto antes de llamar docker-compose ?

my_project_network_on_my_localhost parece mal. ¿Por qué necesita el nombre del proyecto en una red externa? No es necesario que coincida con el nombre del proyecto de redacción.

my_project_network_on_my_localhost me parece mal.

Este fue solo un ejemplo. Tengo una configuración de red diferente en mi máquina de desarrollo local que en un servidor de producción. Muchas otras configuraciones en mi docker-compose.yml también difieren regularmente de la producción, por ejemplo, tengo contenedores de utilidades definidos allí para construir cosas específicas del proyecto o mantener la base de datos o lo que sea.

Según lo entendí, inicialmente la idea principal detrás de docker-compose (o mejor fig ) era organizar bien todas esas largas opciones de línea de comando docker para una configuración de contenedor compleja en un archivo yaml simple. Por eso se siente tan extraño, que queda una sola opción . Pero parece que de alguna manera me perdí que esta ya no es la idea principal detrás de esto.

Muchas otras configuraciones en mi docker-compose.yml también difieren regularmente de la producción, por ejemplo, tengo contenedores de utilidades definidos allí para construir cosas específicas del proyecto o mantener la base de datos o lo que sea.

Tenemos el mismo flujo de trabajo aquí. En nuestro caso, la definición "común" de docker-compose se reduce a casi nada , pero estas son las únicas cosas que realmente se comparten entre el desarrollo, las pruebas, la puesta en escena y la producción.
Las partes principales de la configuración de desarrollo se definen en un archivo separado, la fusión automática se realiza mediante un archivo .env . Es lo mismo para la configuración de prueba .

Debido a que está en una carpeta en nuestro caso, podemos hacer algo como

(cd tests && docker-compose up -d)
(cd tests && docker-compose ps)
(cd tests && docker-compose run php codecept run)

para probar ... o esto

(cd production && docker-compose logs -f --tail 100)

para producción (Bono: puede definir DOCKER_HOST en producción para apuntar a otra máquina, pero solo con docker-compose ).

Pero sí, es una carpeta, no un archivo, y requiere cp .env-dist .env en dos lugares para funcionar; de lo contrario, falla con un archivo de redacción no válido. En realidad, solo quería compartir este flujo de trabajo ordenado en mi humilde opinión.

Este es todavía un punto que no entiendo. No debería haber ninguna razón para requerir un solo nombre de proyecto codificado. Si hay herramientas externas que esperan un nombre coherente, ¿por qué esas herramientas no establecen un nombre de proyecto antes de llamar a docker-compose?

@dnephin Hay razones.

Sí, hay soluciones alternativas. La pregunta es hacerlo más conveniente y predecible.

Aquí hay un ejemplo en el que ayuda un nombre de proyecto codificado: la configuración de la ventana acoplable traefik por defecto crea reglas de host para contenedores en el siguiente formato: <service>.<project>.<domain> . Este formato no es fácil de cambiar. Es muy beneficioso para nuestros desarrolladores usar los mismos fqdns para nuestros servicios de composición de Docker. Sería genial si pudiéramos usar la configuración de configuración cero, ya que la única forma de garantizar la coherencia es: a) obligarlos a usar un nombre de directorio específico para su clon b) especificar manualmente las reglas para traefik. Ambos apestan.

Aquí hay otro: imágenes de referencia creadas con docker-compose. Si no podemos garantizar el nombre del proyecto, no podemos garantizar estos nombres de imágenes y no podemos hacer referencia a ellos con confianza. Claro, podemos codificar el image_name para cada definición, pero francamente se siente redundante porque _ queremos usar la convención_ pero solo nos preocupa que los desarrolladores que eligen usar diferentes nombres de archivo tendrán fallas muy sorprendentes en nuestras herramientas.

Chicos, tantas discusiones ... ¿cuál es el estado de esto? ¿Puedo establecer un nombre de proyecto predeterminado en mi archivo .docker-compose ?
¿O aún necesitas más discusiones en este hilo?

Almacenar el nombre del proyecto en el archivo docker-compose.yml tiene mucho sentido cuando se usa con otras herramientas, por ejemplo, PyCharm.

Sería genial almacenarlo en el mismo archivo YAML pero posiblemente anularlo si es necesario.

Creo que el núcleo de este problema proviene del hecho de que el nombre del proyecto predeterminado es simplemente (¿debería decir _naively_?) Tomado como el nombre base del directorio actual. Esto está comprimiendo efectivamente el espacio de nombres del sistema de archivos (jerárquico) a uno plano, lo cual es problemático debido a conflictos de nombres. Por ejemplo, esto causa problemas a las personas que ejecutan servicios en ~/fooproject/master y ~/barproject/master .

Creo que los nombres de los proyectos no son importantes. Entonces, ¿quizás una forma de hacer que la composición de Docker sea robusta es generar bases de nombres de proyectos en la ruta completa (es decir, home_flaviovs_fooproject_master )?

Sin embargo, me gusta la idea persistente. Poder enviar el nombre del proyecto a Git es un caso de uso tan común. ¿Quizás leer un archivo .env.default antes de .env es una solución simple para esto (que por cierto se encargaría del antiguo # 210 también)?

Resolví esto envolviendo el binario docker-compose con mi propia función para poder llamar a la función desde cualquier lugar. Esto carga el archivo .env y usa el archivo docker-compose correcto en cualquier lugar.

Obviamente, podría extender esto para tener una función por proyecto o algo así. Creo que puede haber algunos inconvenientes, pero no los he descubierto.

DEFAULT_DOCKER_COMPOSE=~/my-project

function dcompose() {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    /usr/local/bin/docker-compose $@;
    popd &> /dev/null;
}
## maintain auto complete
function _dc {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    _docker_compose;
    popd &> /dev/null;
}

complete -F _dc dcompose

Tengo un problema con la colisión de imágenes, y parece realmente extraño que no pueda establecer project_name en el docker-compose.yml, ya que parece una solución muy lógica y directa. En realidad, tomar el nombre de la carpeta del proyecto en primer lugar fue una mala idea. En muchos casos, las carpetas de proyectos pueden ser como / home / project1 / repository, / home / project2 / repository y así sucesivamente, en este caso, la ventana acoplable generó los mismos nombres de imágenes como repository_app.

@vedmant Puede establecer el nombre de la imagen en docker-compose.yml , solo use image y build .

Entonces ... ¿Qué tal separados por proyectos en la carpeta del mismo nombre ahora?

docker-compose -f /foo/bar up -d
docker-compose -f /foo/foo/foo/bar down

Quizás esto ya fue propuesto. pero, ¿por qué no hacer un cambio importante en version: 4 y agregar una nueva palabra clave para permitir configurar el nombre del proyecto desde docker-compose.yml ?

mi .docker-compose / project-name no funcionó ...
--project-name funcionó

También me gustaría establecer el nombre del proyecto en el docker-compose.yml.

Mi caso de uso es que tengo un archivo docker-compose.yml que tiene una aplicación web y un servicio de base de datos de postgreso.
También quiero archivos docker-compose.yml separados para tareas ad hoc, básicamente describiendo tareas ad hoc que me gustaría orquestar con docker-compose. Estas tareas ad hoc deben aprovechar los mismos servicios / redes / volúmenes que se utilizan en el proyecto principal.

Un ejemplo de una tarea ad hoc que me gustaría orquestar con docker-compose podría ser. migrar datos a la base de datos postgress . Es útil orquestar esto con docker-compose porque la tarea puede implicar la activación de servicios y volúmenes adicionales, redes, etc., junto con los actuales, para cumplir con esa tarea.

Entonces, para lograr esto, puedo crear un archivo docker-compose.adhoctask.yml separado para representar la tarea, de modo que pueda ejecutar esa tarea a pedido solo cuando sea necesario. Debido a que está en el mismo directorio que el archivo docker-compose original, obtiene el mismo nombre de proyecto de forma predeterminada y, por lo tanto, tiene acceso a las mismas redes, volúmenes, etc. y todo funciona.

Sin embargo, el problema surge cuando no quiero que este archivo yml de tarea ad hoc viva en el mismo directorio de nivel superior (o incluso en el mismo repositorio) que el docker-compose.yml . Por ejemplo, quizás quiera poner la tarea ad hoc docker-compose.adhoc.yml en una subcarpeta, con los DOCKERFILE y los activos que la tarea necesita bien aislados / agrupados como si fuera su propia preocupación. Tan pronto como lo muevo a una subcarpeta, el nombre del proyecto ya no coincide. Esto significa que ya no tiene acceso a los mismos volúmenes / redes, etc. definidos en el proyecto principal.

Si pudiera especificar projectname en docker-compose.yml y docker-compose.adhoc.yml , entonces podría estructurarlos como quiera (incluso ponerlos en repositorios separados) y aún ejecutarlos sin tener que hacerlo especifique constantemente argumentos de línea de comando adicionales o cambie las variables de entorno.

Este es un problema real para mí, porque causa conflictos de nombres.

Tengo varios proyectos en la estructura

/company
    /ab   # project prefix
        /backend   # actual project
        /webapp
    /cd
        /backend
        /webapp

ahora, cuando comienzo un docker-compose en un proyecto, crea la red backend_default y antepone contenedores que no se nombran explícitamente con backend_ .. ahora Si quiero comenzar el otro proyecto, tengo para volver a la carpeta correcta y ejecutar primero docker-compose down para evitar conflictos; de lo contrario, iniciaría nuevos contenedores en la misma red y luego, al apagarlos, se quejaría de orhans, cuando no hay ninguno.

También es un problema para mí. Tengo varios proyectos y uso docker-compose para soportes de demostración dinámicos en una sola máquina, un soporte por rama.

/project-1
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside
    /feature
        /new-feature # docker-compose.yml inside
/project-2
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside

Entonces, "maestros" y "desarrolladores" están en conflicto entre proyectos. Un archivo .docker-compose podría resolver eso.

@simplesmiler A riesgo de repetirme, un .env ya lo resuelve.

@ shin- .env se usa a menudo para secretos que no están en el control de versiones.

Lo que @simplesmiler quiere es una forma de .env fuera del control de versiones_.

Por lo que puedo decir, todavía no hay forma de hacerlo fácilmente.

@thedeeno eso no es lo que dice su publicación. ¿Están trabajando juntos? Si no es así, no deberíamos suponer cuál es el caso de uso de otra persona más allá de lo que está escrito explícitamente.

No estamos trabajando juntos. Esa es mi interpretación de su problema. Punto totalmente justo, podría estar equivocado y podría presumir.

Ojalá NOSOTROS trabajáramos juntos para poder tomar un café. Espero que no piense que estoy siendo un idiota.

Tal vez solo estoy recordando este hilo incorrectamente: ¿hay alguna manera de enviar el nombre del proyecto al control de versiones mientras se ignora .env ?

¿Hay alguna manera de enviar el nombre del proyecto al control de versiones mientras se ignora .env? ¿O es todavía una capacidad que falta?

No actualmente. Como mencioné hace unos meses ^ 1, el plan es tener docker-compose.env como un archivo env secundario que se puede incluir en el control de versiones. Se ha deslizado un poco hacia abajo en la lista de prioridades, pero espero llegar a ella pronto.

1 / https://github.com/docker/compose/issues/745#issuecomment -345054893

¡Esas son buenas noticias! ¿Aceptar relaciones públicas?

Perdí la esperanza hace mucho tiempo, pero intentémoslo de nuevo:

Creo que muchos aquí todavía no entienden por qué nos vemos obligados a mantener un segundo archivo para esta configuración.

Según tengo entendido, para algunos aquí rompe la configuración de su proyecto. Pero para la mayoría en este hilo no sería un problema. Entonces, ¿cómo puede ser que esos pocos impongan esta restricción a todos los demás a los que les falta esta característica? ¿Por qué no podemos tener varias opciones sobre cómo configurar el nombre y luego dejarnos la decisión a nosotros?

Ni siquiera lógicamente tiene ningún sentido: la falta de esta configuración en docker-compose.yml es tan obvia que ni siquiera podía creer que faltara esta opción cuando la busqué en el manual. Casi todos y cada uno de los demás aspectos de su configuración se pueden configurar allí. Para mí, esa es una ruptura tan clara en la lógica de configuración.

Creo que se podría decir, (casi) todas las configuraciones en docker-compose.yml tienen "alcance" por el nombre del proyecto .

Como se sugiere en # 4841, una opción para especificar qué archivo .env usar (es decir, --env-file ) debería ser muy útil.

@roipoussiere ver https://github.com/docker/compose/issues/4841#issuecomment -414543951

Gracias @ schmunk42.
Pero eso significa que debo crear una jerarquía como:

.
├── project_a
│   ├── .env
├── project_b
│   ├── .env

en lugar de algo más fácil como:

.
├── a.env
├── b.env

Sí, consulte también https://github.com/docker/compose/issues/745#issuecomment -345054893; es posible que deba abrirlo en una nueva ventana, ya que a veces está oculto aquí : nerd_face:

Secundo la propuesta --env-file . Hice un boleto solo para eso. Ve y dale me gusta si quieres esta opción.

Entonces, solo leí algunos comentarios sobre este error / característica, y el hecho de que la discusión continúe y esté abierta me lleva a la conclusión de que han pasado 4 años desde que se abrió originalmente y todavía no hay solución. ¿Podemos tomar una decisión parcial y luego seguir adelante ...?

Lo admito, no he leído todo este número y todos los temas relacionados, pero hay problemas interesantes en torno a este tema que lo hacen más complicado de lo que parece a primera vista. Por ejemplo, como todos sabemos, .env se usa comúnmente para valores secretos, por lo que generalmente lo ignora del control de versiones.

Pero digamos que está trabajando con Stripe, lo que le permite tener claves de prueba y claves activas, AKA. 2 juegos de llaves para trabajar. En desarrollo, sería muy común que usaras las claves de prueba, y en producción terminarías usando las claves activas.

Eso significa automáticamente que no puede usar .env por sí mismo para tratar con valores secretos porque tendrá diferentes claves en cada entorno y no querrá tener que cambiar los valores en su archivo entre ejecutar su aplicación en dev o prod (eso sería una locura y muy propenso a errores).

Lo que probablemente terminará haciendo es crear un archivo .env y .env.prod e ignorar ambos desde el control de versiones. De esta manera, puede tener sus claves de prueba / desarrollo en desarrollo y luego hacer referencia a eso con env_file en su archivo de composición de desarrollo.

Pero luego, en producción, hace referencia a .env y .env.prod en su archivo de composición de producción.

¿Pero ves a dónde va esto? En este momento, Docker Compose no le permite tener archivos env_file opcionales. Si el archivo no existe, Docker Compose explotará tan pronto como intente ejecutar Docker Compose.

Por lo tanto, automáticamente necesita que exista .env archivo env_file y esto tampoco se limita a Stripe. Muchos frameworks web tienen ciertas configuraciones que son específicas del entorno pero que cambiarían tanto en el desarrollo como en la producción (es decir, SERVER_NAME con Flask).

Eso significa que estamos limitados a tener algo como un archivo .env_example que compromete al control de versiones y se espera que el usuario final cambie el nombre de ese archivo a .env , y luego dentro de este archivo contendría nuestro viejo amigo COMPOSE_PROJECT_NAME .

Lo que ahora trae a colación la pregunta. ¿Realmente necesitamos una forma alternativa de establecer el nombre del proyecto? No estoy convencido de que lo hagamos, pero estoy convencido de que establecer un nombre de proyecto personalizado es una buena idea en cualquier proyecto, o al menos en algo diferente al nombre de la carpeta, ya que puede encontrarse fácilmente con conflictos de nombres.

¿Está este tema en alguna hoja de ruta, por favor?

El caso de uso para esto sería modificar el COMPOSE_PROJECT_NAME en el caso de que su proyecto tenga varios archivos de composición acoplable (por ejemplo, uno para desarrollo, prueba, tal vez una base, tal vez una prueba local, etc.). Es posible que tenga que girar hasta 2 entornos muy diferentes y separados entre sí.

En nuestro caso, podemos sortear esta limitación de composición de la ventana acoplable creando COMPOSE_PROJECT_NAME en nuestro archivo MAKE.

Me gustaría ver esto configurable desde el propio yaml de composición.

¿Sigue abierto esto? Oh Dios mío...

Suscrito. También quiero poder establecer el nombre del proyecto en el archivo yaml de composición.

Esto está tardando una eternidad 🤦‍♂

sería muy útil tener esta función

esta característica sería muy bienvenida en el proyecto en el que estoy trabajando

De acuerdo, a partir de este hilo largo podemos concluir que el nombre del proyecto no estará en el archivo docker-compose.yml, porque los desarrolladores principales están en contra de esto y no fusionarán ninguna solicitud de extracción.

Entonces, ¿podemos volver a la propuesta original y luego al principio de este problema: hacer que el nombre del proyecto sea persistente? Usar un archivo .docker-compose o un directorio .docker-compose me suena bien. Pero sería bueno si finalmente pudiéramos progresar en la implementación de eso.

Agregaría una variable ENV a esa lista de alternativas.

Una raíz sustancial de todo el desacuerdo es que este hilo / problema es que para muchas personas no funciona si está en una variable ENV. Quieren poder enviarlo a un repositorio (opcional, por supuesto, la recomendación estándar puede ser no comprometerlo).

Tenerlo ENV en lugar del contenido de yaml contradice la filosofía de compartir archivos yaml entre diferentes proyectos. De hecho, está oficialmente documentado: https://docs.docker.com/compose/extends/ (Ver "Ejemplos de casos de uso", por ejemplo). Si usa un archivo yaml de base única y luego anula los archivos para dev, test y prod, y Dios sabe qué más, no tiene sentido ejecutarlo con el mismo nombre de proyecto o establecer el nombre del proyecto por ENV / cli. Simplemente creará combinaciones N * N mientras que N sean válidas.

He atravesado varias de estas discusiones y veo una TONELADA de comentarios de personas que desean que el nombre del proyecto sea configurable en el archivo YML. Pero ni un solo comentario que explique por qué no debería hacerse. Estas discusiones se remontan a mucho tiempo atrás.

Como alguien que busca una solución fácil de usar y descubre que no hay una manera fácil de establecer el nombre del proyecto que no requiera la atención cuidadosa del usuario en la línea de comandos ejecutada (que compite con la idea central de una herramienta a la que pasar up y comenzar mágicamente un grupo completo de servidores) - Me sorprende que esta sea una pregunta abierta. Si hubiera alguna explicación clara de por qué es problemático o preocupante implementarlo, me interesaría.

una solución elegante podría ser usar un marcador de posición en la propiedad container_name (y otros nombres dinámicos como volumen, red, ...)

services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value

con tal configuración, uno podría usar

services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}

editar: esta no es una solución perfecta, ya que entrará en conflicto para las personas que usan 2 proyectos distinguidos dentro del mismo nombre de carpeta

@jderusse

una solución elegante podría ser usar un marcador de posición en la propiedad container_name (y otros nombres dinámicos como volumen, red, ...)

services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value

con tal configuración, uno podría usar

services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}

editar: esta no es una solución perfecta, ya que entrará en conflicto para las personas que usan 2 proyectos distinguidos dentro del mismo nombre de carpeta

También estoy haciendo esto y pensé que esto solucionaría el problema del conflicto, aunque todavía necesitamos establecer la variable COMPOSE_PROJECT_NAME en un valor único en el archivo .env .

En este punto, solo quiero entender la razón por la que los mantenedores rechazan las soluciones. Ya existe una solicitud de extracción para una solución.

Una vez que sepamos qué está mal, podemos trabajar para solucionarlo. En este punto, no veo más comentarios que "rechazados".

Tenemos estos 2 comentarios:

https://github.com/docker/compose/issues/745#issuecomment -345054893
https://github.com/docker/compose/issues/745#issuecomment -346487757

Pero debo admitir que incluso leyendo esos comentarios, no entiendo completamente por qué no simplemente agregar el nombre del proyecto al archivo yaml. Para aquellos que piensan que hace que sus archivos docker-compose.yaml sean menos generales, simplemente no deberían poner el nombre en el archivo yaml, pero deje que el resto de nosotros tenga una opción para hacerlo.

Bien, estoy haciendo todo lo posible para leer las referencias a otros comentarios; Realmente agradecería al menos una breve propaganda que haga referencia al contenido de la referencia, además de la referencia para ayudar a asegurarme de que estoy leyendo lo correcto y obteniendo el contenido correcto.

Permítanme intentar resumir lo que estoy viendo son las preocupaciones. Se agradecería cualquier ayuda para aclarar esto.

(1) Agregar el nombre del proyecto al archivo YML puede hacer que el proyecto sea menos reutilizable ya que evitaría, o al menos complicaría, la ejecución de un archivo YML con más de un nombre de proyecto.
(2) "la calidad del proyecto sufriría demasiado como resultado para justificar su adición (en esta forma)"
(3) "Si el nombre del proyecto está en el archivo de redacción, entonces cualquiera de los dos proyectos podría usar el mismo nombre, provocando un conflicto que rompería ambos proyectos".

Tengo pensamientos sobre esto, pero esperaré con comentarios hasta que podamos acordarnos sobre las preocupaciones que deben abordarse. ¿Es eso razonable?

(4) Implementación de forma compatible con versiones anteriores (precedencia / orden de valores)

(1) Agregar el nombre del proyecto al archivo YML puede hacer que el proyecto sea menos reutilizable ya que evitaría, o al menos complicaría, la ejecución de un archivo YML con más de un nombre de proyecto.

Una vez más, existe una forma oficial de dividir la configuración en base y archivo y heredada: https://docs.docker.com/compose/extends/. No se pudo configurar el nombre del proyecto en la configuración base.

Para mí, el caso de uso principal que estoy buscando es la capacidad de ejecutar varias instancias del proyecto localmente (desarrollo, entornos de prueba, etc.).

Tal vez la solución sea permitirle establecer el nombre del proyecto explícitamente o un recorrido de ruta.

Si configuro el nombre del proyecto en el archivo yaml explícitamente como my-project entonces puedo simplificar las cosas para una sola instancia de un proyecto o cuando hago algo como agregar todos mis archivos de la ventana acoplable en una carpeta docker en múltiples proyectos.

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name: my-project)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name: some-other-project)

Pero esto no ayuda con varias instancias del mismo proyecto, entonces, ¿qué tal si hacemos algo con el recorrido de la ruta?

project_name: ../(*) así que con el mismo ejemplo

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_a)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b)
├── project_b_copy
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b_copy)

igualmente project_name: ../(../*)

.
├── dev
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=dev_project_a)
├── test
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=test_project_a)

La forma de especificar el recorrido probablemente debería pensarse con un poco más de profundidad que mi pulgar, pero al menos al hacer esto, creo que tenemos flexibilidad para cubrir todos los casos de uso.

Solo medio en broma: eso significa configurar un nombre fijo en mi docker-compose.yml. Crearía un archivo con el nombre que quiero y luego estableceré project_name: name-of-the-file-named-like-the-name-i-want ?

Actualmente tengo una carga de archivos docker-compose en el mismo directorio. Como dc-work.yml , dc-server.yml , etc., que cargan servicios diferentes y no relacionados.

Cuando ejecuto docker-compose up dc-A.yml , y luego ejecuto docker-compose up dc-B.yml , Docker me regaña que hay servicios huérfanos en ejecución (por supuesto que no los hay, es por el maldito nombre del proyecto).

¿Realmente no hay forma de resolver esto? Mover cada archivo dc-A|B|C|etc.yml a su propio directorio y luego atravesar cada uno para cargar todos mis servicios parece una verdadera pérdida de tiempo, ¿o me estoy perdiendo algo?

¿Por qué no se ha abordado este problema? La solución clara y directa fue presentada por @ cr7pt0gr4ph7 aquí: https://github.com/docker/compose/issues/745#issuecomment -182296139. Recibió muchos votos positivos. Cada una de las preocupaciones se ha abordado en la discusión. Y, lo más importante, resuelve muchos problemas para muchas personas. ¿Lo que da?

También nos encontramos con este problema porque estamos usando una estructura de directorio de proyecto fijo con una carpeta .docker que contiene todas las cosas relacionadas con la ventana acoplable, por lo que estoy terminando con muchos nombres de proyectos .docker: estoy trabajando en una arquitectura de microservicios así que es normal tener múltiples arriba ... pero esta pequeña cosa, sigue interfiriendo -> también, PHPStorm, etc.no tiene la opción de pasar el argumento -p / - project-dir y no puedo realmente use un .env para esto porque, créanme, se olvidará establecer el valor correcto ...

Desarrolladores, háganos saber cómo quieren que se resuelva.

¿Quizás agregar una propiedad al archivo docker-compose para establecer el nombre del proyecto?

@AyushyaChitransh

Desarrolladores, háganos saber cómo quieren que se resuelva.

Este es el mejor resumen:
https://github.com/docker/compose/issues/745#issuecomment -182296139

Ha habido mucha discusión. No es necesario seguir discutiendo. Los mantenedores del proyecto solo necesitan leer los hilos (plural) y hacer lo necesario.

Para mí sigue siendo esto: https://github.com/docker/compose/issues/745#issuecomment -248644429

Para mí sigue siendo esto: # 745 (comentario)

Sí, existe una solución, pero deficiente. Estos comentarios han sido rechazados y muchos han manifestado claramente los problemas. Los comentarios vinculados simplemente no abordan la mayoría de las preocupaciones legítimas planteadas en estos hilos.

Tbh, es un punto discutible. Muchos de nosotros nos hemos mudado a Kubernetes por la funcionalidad de tipo docker-compose . Es un poco detallado. Pero está funcionando y cuenta con el respaldo de los proveedores de la nube.

@AyushyaChitransh
Queremos utilizar el mecanismo para establecer el nombre del proyecto como se describe aquí: https://github.com/docker/compose/issues/745#issuecomment -182296139

1. Línea de comando arg.
2. Variable de entorno (archivo .env)
3. En Redactar archivo directamente
4. Ruta de la carpeta

No crea que hay ninguna objeción a esto.

Hay, se trata de portabilidad, como se mencionó anteriormente, de alguna manera similar cuando se usa container_name , que tampoco debería ser parte de docker-compose.yml . No puede reutilizar la misma configuración con la configuración existente.

Si su flujo de trabajo se basa en la ruta de la carpeta y de alguna manera project-name se inyecta en su configuración, por ejemplo. mediante la combinación, varios archivos de redacción, plantillas, ... - terminará con el mismo problema - sobrescribiendo las pilas existentes.

Lamento decir esto, pero esto debería cerrarse como no se corrige .. (editar) o lanzar una nueva versión MAJOR (!)

@ schmunk42

Si su flujo de trabajo se basa en la ruta de la carpeta y de alguna manera el nombre del proyecto se inyecta en su configuración, por ejemplo. mediante la combinación, varios archivos de redacción, plantillas, ... - terminará con el mismo problema - sobrescribiendo las pilas existentes.

En primer lugar, el nombre del proyecto solo lo establecerían aquellos que lo requieran en los archivos de composición y es precisamente porque quieren que los archivos de composición funcionen con las pilas existentes. Puede agregar su advertencia a los documentos sobre esta configuración.
En segundo lugar, para aquellos que dependen de un nombre de proyecto específico, considere esto:

1. ¿Qué pasa si el archivo de redacción se descarga de un repositorio de git, luego, en la siguiente confirmación, el propietario del repositorio lo mueve a una subcarpeta diferente? ¿O cambió el nombre de la carpeta en la que se encuentra? El impacto en el flujo de trabajo ya está presente, ya que los archivos se pueden mover y eso afecta el nombre del proyecto.
2. Si confía en un nombre de proyecto específico, hemos propuesto el mecanismo para garantizarlo, ya sea usando la variable de entorno (archivo .env) o usando la línea de comando arg al ejecutar Docker compose, los cuales anularían cualquier valor que estuviera en el archivo de redacción (si se agregó uno por alguna razón).

Cerrar esto como wontfix no es muy útil sin explicar por qué lo anterior no es lo suficientemente bueno ... u ofrecer un camino hacia una solución.

No quiero que mi flujo de trabajo (o más bien el flujo de trabajo de todo mi equipo) dependa del nombre de la carpeta en la que verifican el código.

Mi principal problema con la solución del archivo .env es que este archivo debe estar en el directorio de trabajo del comando run, mientras que docker-compose resuelve el archivo de composición en un directorio principal. Por lo tanto, es esencial que todos los desarrolladores (A) revisen el código en la carpeta del mismo nombre (asumiendo un archivo docker-compose.yml en la raíz de un repositorio de código) o (B) solo ejecuten comandos docker-compose en la carpeta raíz del repositorio de lo contrario crea pilas en conflicto o (C) tienen diferentes nombres de pila y toda la documentación y los scripts deben decir replace stack name here .

Si (C) es lo que Docker sugiere como la solución 'portátil' recomendada, entonces la CLI de docker-compose debe estar completa con los comandos de la CLI de docker e, incluso entonces, todavía veo un caso de uso para esta función.

Si su flujo de trabajo se basa en la ruta de la carpeta y de alguna manera el nombre del proyecto se inyecta en su configuración, por ejemplo. mediante la combinación, varios archivos de redacción, plantillas, ... - terminará con el mismo problema - sobrescribiendo las pilas existentes.

Si se agrega un nombre de proyecto al archivo docker-compose, ciertamente está ahí por una razón (como cualquier otra línea en un archivo docker-compose). Lamentablemente, en este momento, incluso simplemente cambiando el nombre de mi carpeta desprotegida (sin realizar ningún cambio de seguimiento en git), también obtengo un sistema roto.

No puedo creer que sea 2020 y todavía no hemos solucionado este gran caso de uso. Este no es un cambio importante, es una característica totalmente opcional y tiene mucho sentido. Dado que Kubernetes es ahora la herramienta de implementación de facto para docker, me imagino que docker-compose se usa principalmente en implementaciones de desarrollo / locales y tener un archivo de docker-compose en la raíz de un repositorio para ejecutar el código en el repositorio localmente es muy popular caso de uso.

@ dc-pm escribió: "Dado que Kubernetes es ahora la herramienta de implementación de facto para Docker"

Ahora ya no escribo archivos docker-compose. No hay suficientes beneficios para algo que no verá producción. Kubernetes también tiene sus peculiaridades. Pero cuenta con un amplio respaldo de los proveedores de la nube.

A decir verdad, incluso tratar con contenedores en mi entorno de desarrollo es demasiado complicado en el día a día. Solo ejecuto los programas ...

@ dc-pm escribió:

No puedo creer que sea 2020 y todavía no hemos solucionado este gran caso de uso.

No es solo que no se haya solucionado, sino que los desarrolladores se niegan activamente a solucionarlo.

El problema, sospecho, es que los adolescentes que desarrollan este software no tienen la experiencia suficiente para comprender las implicaciones de este caso de uso, o escuchar a la gran cantidad de usuarios más experimentados que solicitan que se aborde. En este punto, dudo que hayan trabajado en un entorno con más de una pila, o tal vez incluso en equipos. De lo contrario, francamente, ¡esta sería una mejora perfectamente obvia!

Algunos recordatorios amistosos ...
Los desarrolladores de código abierto no son sus "empleados / universidades", en la mayoría de los casos trabajan principalmente de forma gratuita.
Si es claramente un problema para usted, tómese un tiempo para investigar soluciones (y presione un PR).

Culpar no es la solución.

https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md

Es bastante difícil impulsar un cambio cuando los desarrolladores están en contra ...

El sábado 14 de marzo de 2020 a las 03:19, Antoine Gravelot [email protected]
escribió:

Algunos recordatorios amistosos ...
Los desarrolladores de código abierto no son sus "empleados / universidades", en la mayoría de los casos
trabajan principalmente de forma gratuita.
Si es claramente un problema para usted, tómese un tiempo para investigar soluciones.
y empuja un PR.

Culpar no es la solución.

https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/compose/issues/745#issuecomment-598991880 , o
darse de baja
https://github.com/notifications/unsubscribe-auth/ABAXP2DRD7H4YI7KQ7B2URLRHLLQ5ANCNFSM4AZMCNWA
.

@agravelot Creo que ha habido algunas relaciones públicas, puede que no sea lo ideal. Pero a lo largo de toda la discusión, los propietarios han establecido muy claramente sus expectativas de que no quieren esta función. No se trata de codificar.

@agravelot perdón por el retraso. Y realmente no quise faltarle el respeto a las muchas personas maravillosas y talentosas que contribuyen aquí. Pero culpar a la falta de esfuerzo tampoco ayuda.

Simplemente destaco el apoyo de una idea que no se ha escuchado en innumerables ocasiones a pesar de un apoyo claro durante un período de tiempo muy largo. El objetivo de esto (y OSS en general) como se define en nuestro código de conducta es permitir que las personas contribuyan con el código y respeten todas las ideas.

Ya se han creado varias solicitudes de extracción, pero si ayuda a mejorar la situación, estoy muy feliz de crear otra.

¿Cuál sería una forma más constructiva de avanzar?

Ya se han creado varias solicitudes de extracción, pero si ayuda a mejorar la situación, estoy muy feliz de crear otra.

Sí, los desarrolladores deberían continuar revisándolos, o cerrar esto como "No se arreglará" (posiblemente discutiendo) ... Mantener esto abierto durante años, sin comentarios oficiales, es perder el tiempo de los colaboradores (en el sentido más amplio ). Esto también es una falta de respeto, en mi opinión.

Hola, chicos, como usuario, solo quería compartir mi caso de uso. Así que tengo 2 archivos docker-compose.yml, uno para el entorno de desarrollo y otro para la producción. Están ubicados en la misma carpeta. Ambos tienen un servicio con el mismo nombre, llamado "base de datos". Me gustaría implementar ambos servicios al mismo tiempo, solo porque puedo, estamos hablando de la contenedorización, puedo escalar tanto como quiera. Sin embargo, tienen diferentes valores de "container_name".

Entonces corro:

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-server_autocat-dev" with the default driver
Creating database-dev ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-server_autocat-prod" with the default driver
Recreating database-dev ... done

Tenga en cuenta cómo dice "Recreating database-dev" mientras me refiero claramente al servicio ubicado en el proyecto "prod". Realmente sobrescribe el contenedor existente. La base de datos se termina y el contenedor se reemplaza por este último.

Estoy haciendo esto asumiendo que los archivos "docker-compose.yml" separados significan proyectos separados, pero aparentemente esto no es algo en la vida real. El proyecto en el que se implementa el servicio está determinado por la ubicación de "docker-compose.yml". Para que sean parte de proyectos separados, necesito especificar por separado el nombre del proyecto en una variable de entorno. Finalmente funciona con esto:

macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-prod docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-prod_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-dev docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-dev_autocat-dev" with the default driver
Creating database-dev ... done

Demasiado para el despliegue de un solo comando, qué broma absoluta. En mi opinión, .yml es un gran lugar para especificar el nombre del proyecto en este contexto.

Alternativamente, pude colocar los servicios en un solo proyecto, dándoles diferentes nombres: "database-dev" y "database-prod". El único problema con este enfoque es que hay una advertencia acerca de que el servicio anteriormente instanciado se convierte en huérfano porque no se menciona en el otro docker-compose.yml.

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database-prod                
Creating network "autocat-server_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database    
WARNING: Found orphan containers (database-prod) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Creating database-dev ... done

Esto no tiene sentido tbh, ¿por qué tiene que ser así? ¿Por qué, de hecho, tiene que ser así?

EDIT1: @ dc-pm @CharlieReitzel ¿
EDIT2: he puesto ambos archivos de redacción en directorios separados y listo

tan?

mantenedores, alguien aquí?
¡Los desarrolladores esperan durante 6 años!

¡Hola! Creé un problema en la especificación de composición para agregar el nombre del proyecto al esquema de composición, ya que eso rige lo que podemos agregar al archivo de composición.
Una vez que se agrega la propiedad project-name a la especificación de composición, podemos comenzar la implementación en docker-compose.