Compose: Definir servicios que no se inician de forma predeterminada

+1 para la opción 1

Creo que agregar servicios que en realidad no son parte de una composición, pero que simplemente necesitan vincularlos / adjuntarlos, es una mala elección de diseño. Hay algunos otros casos de uso que se resolverían permitiendo alguna forma de sintaxis de inclusión. Siempre es bueno resolver varios problemas con una sola función.

Algunos de estos problemas (los que tratan con contenedores de solo datos, # 942, el último comentario de @ cpuguy83) ya están solucionados por # 1754, no creo que debamos considerarlos un problema más (después de 1.5 ).

Desarrollamos extensiones de Magento. Para hacer eso, necesitamos una forma sencilla de ejecutar una tienda web en una pila LAMP. Compose lo hace fácil. Pero también queremos ejecutar phpunit, varias herramientas de análisis estático, constructores de documentación, etc. De hecho, la gran mayoría de nuestros "servicios" son solo comandos, como docker-compose run --rm phplint . Idealmente, un comando no calificado como

docker-compose up -d

solo iniciaría el servicio de larga duración (_services_ reales por así decirlo), y no desencadenaría otros efectos como phpunit, innecesariamente. (También es importante que no active cosas fuera de orden, como ejecutar pruebas de Selenium antes de que el servicio web esté activo).

Todo lo que realmente estamos tratando de hacer es quitarles a los desarrolladores el dolor de la administración del entorno, no ejecutar servicios de producción. No sé si el comentario de @dnephin es representativo de la dirección en la que se dirige Compose o no, pero me parece ambiguo si Compose todavía está planeando servir al nicho en el que comenzó Fig. (Porque, para ser claros, yo Creo que la opción 1 no es compatible con la facilidad de uso que los desarrolladores necesitan para usar esto como Fig aparentemente pretendía). Entiendo totalmente si Compose no quiere tener múltiples responsabilidades, pero espero que alguien pueda informarnos, claramente, si aquellos de nosotros que utilizamos este producto para entornos de desarrollo aislados y rápidos debemos ir en otra dirección.

@kojiromike , ¿de qué se trata (1) que no es adecuado para su caso de uso? ¿Se trata solo de la semántica de los comandos ( docker-compose run --rm phplint frente a docker-compose --file phplint.yml up )?

Es que docker-compose up -d intenta 'iniciar' phplint y docker-compose ps informa que el 'servicio' de phplint no funciona. En realidad, eso no es un contenedor de servicios, es un contenedor de herramientas, no debería tener el concepto de arriba / abajo. Tenía entendido que los contenedores de herramientas son adoptados por docker (es cómo ejecutaría algo como redis-cli, claramente no un 'servicio') y aunque los uso más en el desarrollo, creo que también tienen un lugar para la producción; como por qué tener, por ejemplo, awk instalado en máquinas de producción o en contenedores, ¿por qué no ejecutarlo a través de un contenedor con enlaces para obtener un comportamiento predecible?

: +1: Rutinariamente me encuentro queriendo crear un contenedor tests junto con mis otros servicios para encapsular las pruebas unitarias en ejecución. Mi "solución" es establecer el comando en "/ bin / true" y ejecutar el contenedor con el comando de prueba de unidad especificado en la CLI. Sería genial poder especificar qué contenedores deben comenzar en up time.

(por cierto, buen trabajo, amigos)

cc @jameydeorio

@ryneeverett La semántica es una parte de esto. Es un problema de auto-documentación y capacidad de búsqueda. Actualmente, les decimos a los desarrolladores docker-compose run --rm foo bar . Los invitamos a crear una función de shell o alias, pero no mantenemos un alias / rcfile estándar para los proyectos. (No queremos estandarizar cosas fuera de los contenedores; queremos usar Docker _to_ estandarizar). Agregar un nuevo archivo para algunos comandos crea una jerarquía de importancia: el archivo docker-compose.yml se convierte en el archivo "predeterminado" para importantes cosas, y el archivo "otro" se vuelve menos importante.

La otra cosa es que mantener relaciones entre servicios se vuelve más oneroso. El hecho de que queramos que algo no se ejecute de forma predeterminada no significa que no utilice un link o volume de un servicio de larga duración. extends realidad no proporciona todas las facilidades que necesitaríamos para vincular servicios a "comandos" (servicios de una sola ejecución). Incluso si lo hiciera, si tenemos que usar varios archivos yaml, nos veremos obligados a usar extends donde de otra manera no necesitaríamos hacerlo.

En realidad, extensions no proporciona todas las facilidades que necesitaríamos para vincular servicios a "comandos" (servicios de una sola ejecución). Incluso si lo hiciera, si tenemos que usar varios archivos yaml, nos veremos obligados a usar extensiones donde de otro modo no lo necesitaríamos.

@kojiromike Eso es lo que sospechaba. Me pregunto si estaría satisfecho con el soporte mejorado de extends + alguna forma de hacer subcomandos (que serían funcionalmente idénticos a extends ) dentro de un solo docker-compose.yml . Pero quizás este último sea el mismo que (4).

2) Agregue una opción a los servicios para que no se inicien de forma predeterminada

Voto por la Opción 2. Por ejemplo, algo así como una directiva start: false . Las ventajas son que evitamos la necesidad de varios archivos compose.yml o archivos de configuración adicionales, solo puede leer un compose.yml para tener una idea de toda la pila de aplicaciones.

Creo que nuestra solución propuesta para https://github.com/docker/compose/issues/1987#issuecomment -139632238 manejará esto. Los servicios "admin" pueden definirse en una configuración separada y agregarse con -f cuando un comando de administrador debe ejecutarse en una composición.

@dnephin La solución en # 1987 (comentario) _siste_ maneja "servicios de administración", pero _no_ maneja "contenedores de datos solamente", ¿verdad? Aún tendría que usar la solución alternativa command: /bin/true .

No debería necesitar contenedores de solo datos con compose, ya que compose manejará el intercambio de volúmenes para volver a crear contenedores por usted.

@ cpuguy83 En el siguiente ejemplo, el contenedor de datos no es realmente necesario, pero si quiero cambiar el volumen, solo necesito mirar un lugar designado.

nginx:
  image: nginx:1.9
  volumes_from:
  - data

php:
  image: php:5.6-fpm
  volumes_from:
  - data

data:
  image: debian:jessie
  volumes:
  - ./:/app

Sin embargo, estoy de acuerdo en que este es un caso de esquina y que agregar sintaxis adicional probablemente no valga la pena. Solo digo que la solución propuesta no maneja este caso.

Es cierto que todavía se requiere algún comando para los volúmenes de datos, por lo que tendría que usar una imagen mínima para admitir ese comando.

No estoy completamente actualizado con la nueva API de volúmenes que está saliendo, pero espero que podamos agregar una sección volumes: para componer que manejará el volumen de datos de una mejor manera (en lugar de requerir un contenedor para ellos).

Esto no necesariamente la convierte en la elección correcta, pero creo que se debe considerar la curva de aprendizaje / facilidad de comprensión.

Siento que (2) es el más fácil de comprender. Realmente no tengo una manera de confirmar esto, pero mi instinto dice que la mayoría de las personas que no están íntimamente familiarizadas con todas las opciones de docker-compose que se encuentran con el problema que estamos tratando de resolver aquí dicen: "Ojalá hubiera alguna manera de hacer que ese contenedor _no se inicie_ cuando ejecuto docker-compose up ", y ven start: false y bam, hemos terminado y estamos felices.

No dicen: "Si tan solo hubiera una manera de poder crear un segundo archivo con una historia de vinculación incómoda para resolver esto ..." (aunque me doy cuenta de que https://github.com/docker/compose/issues/ 1987 # issuecomment-139632238 ayuda con la "historia de vinculación incómoda", ¿no?).

(4) era un poco vago, pero una vía dedicada al camino para los guiones y los únicos como este se ajusta a este proyecto de ley "tiene sentido".

Hoy estaba buscando exactamente (2) pero terminé con mi solución menos favorita, un segundo archivo YML. Mi caso de uso:

Tengo un par de contenedores y todos se vinculan al mismo contenedor mongo . Me gustaría ofrecerme a mí y al equipo la capacidad de cargar accesorios en la base de datos de mongo y pensé que la forma más fácil de hacerlo es cargar el contenedor mongo con un nombre diferente fixtures que se enlaza a mongo y luego ejecuta mongorestore --host mongo --port 27017 --drop /dump . Como no queremos cargar los accesorios en todo momento, nos pareció natural tenerlo con un start: false pero terminó teniendo un archivo YML separado para ambos contenedores fixtures y mongo .

Funciona bien, pero start: false es mucho más limpio en mi opinión. Si tuviera 10 o más permutaciones de este llamado contenedor de accesorios, entonces sí start: false sería una mala idea y optaría por (1) .

Solo tenía que hacer un archivo de redacción donde algunos servicios no deberían ejecutarse con el comando docker-compose up -d . Para mí, la opción (2) sería la mejor solución a mi problema.

También me he encontrado con esto. No estoy seguro de cuál creo que sea la mejor solución, pero lo que se reduce a mí es que necesito la capacidad de crear imágenes que se utilicen como parte de una composición. Son para contenedores efímeros, pero necesito que la imagen esté lista para usarse para poder ejecutar el contenedor a pedido.

¡Hola! mismo problema aquí, me alegro de que haya un buen problema de agrupación, ¡excelente trabajo!

En mi caso, tengo una pila de Python que funciona con un par de contenedores con servicios. Todo funciona bien, pero acabo de encontrar un caso fuera de la pila. Estoy administrando dependencias estáticas con bower y quiero ejecutar el comando bower dentro de un contenedor, es solo un script que ejecutamos de vez en cuando.

Sería genial ejecutar este script dentro de la estructura de composición que tenemos. Me imagino algo como:
docker-compose ejecutar node bower install

Así que me gusta la opción 2 de 4. Solo necesita que el servicio no se inicie, no es necesario: P

Si hay algún consenso, podría intentar enviar un pull-req para algo como "reiniciar"
comienzo: siempre
tal vez ... no sé.

Otro voto para la opción 2.

Yo también preferiría la opción 2. Los nuevos contenedores de datos de Docker se pueden especificar en un archivo de composición de Docker, pero no es necesario que estén en ejecución para usarse.

Opcion 2 para mi tambien

La opción 2 sería genial.

+1 para la opción 2

+1 para la opción 2. Mantener varios archivos y escribir sus nombres es una pérdida de tiempo. Una sola bandera booleana los gobernaría a todos. : cervezas:

+1 para optar 4,
Si debo elegir un segundo favorito, es la opción 2.

Es cierto que la mejor opción es 2,4 si puedo hacer +1 en ambos, entonces eso es lo que hago, si no, voy con la mayoría y voto por 2.

Votar por 2

es bueno tener tanto 2 como 4.
+1 por 2

No creo que sea necesario introducir un nuevo concepto de tareas. Estos se leen muy bien en mi opinión y son posibles sin muchas modificaciones:

// 'task' being a service that manages all my tasks, probably with some custom entrypoint script
docker-compose run task tests

// 'tests' being a service specifically for testing with the default command set to run my tests
docker-compose run tests

La "solución" actual con el archivo de redacción separado no es realmente una solución en mi opinión. Como dijo @xaka , nadie quiere escribir todo esto:

docker-compose -f default-file.yml -f additional-tasks-file.yml  run task myTask

Lo que terminará con es un script ./run-task que agrega todo el texto estándar antes de myTask para usted. Pero ahora ha agregado otro punto de entrada e interfaz a su aplicación de contenedores múltiples. Los desarrolladores ven docker-compose.yml y piensan: _ "¡Oh, genial, una aplicación de redacción. Sé cómo manejar esto!" _ Y ahora tienes que decirles: _ "Bien, puedes administrarlo con docker-compose como cualquier otra aplicación de redacción ... oh, pero espera ... también hay este script adicional que necesitas saber ...

start: false / up: false / some-additional-flag-to-a-service: false es probablemente la cosa más simple de implementar, pero probablemente también la más clara y fácil de entender. Y mejoraría mucho la usabilidad.

lo que dijo @sherter . :flecha arriba:

: +1: por eso. dockerfile separado es un gran problema, especialmente cuando las redes están involucradas

El enfoque start: true|false es demasiado limitado. ¿Qué sucede si algunos servicios se utilizan para pruebas, otros para administración y el resto para funcionamiento normal?

Preferiría agregar la noción de agrupación a los servicios.

    myservice:
       group: `admin`

Si el atributo group no está definido, se asume default .
De esa manera, podríamos iniciar los servicios predeterminados y de administración usando docker-compose up -g admin -d .

Mejor aún, haga groups una matriz.

La creación de clases grupales de servicios parece ser una característica poderosa, pero también parece tangencial a este problema.

En la versión 2 de docker-compose, cada contenedor se declara dentro del elemento de nivel superior services: .
Declarar un servicio, con start: never para ejecutar un script suena mal.
Entonces, considerando el nuevo formato, ¿no deberíamos declarar un elemento de nivel superior adicional aparte de _services_, _volumes_ y _networks_?

Mi propuesta:

• agregue un nuevo elemento de nivel superior scripts: , transients: (o piense en un nombre mejor) a v2.
• dentro de los transitorios puede definir un contenedor como lo haría con cualquier servicio
• la única diferencia es que no se van a _iniciar de forma predeterminada_, ya que están destinados a un uso transitorio únicamente.

Ejemplo:

version: "2"

services:
  web:
    image: myapp
    networks:
      - front
      - back
    volumes:
      - /usr/src/app/
  redis:
    image: redis
    volumes:
      - redis-data:/var/lib/redis
    networks:
      - back

scripts:
  bower:
    image: my_image_with_bower
    volumes_from: web
    working_dir: /usr/src/app/static
    command: "bower"
// maybe would be great to place something like "bower $@"
// to define where you want the cli arguments to be placed, by default at the end.

volumes:
  redis-data:
    driver: flocker

networks:
  front:
    driver: overlay
  back:
    driver: overlay

Y luego podrías ejecutar:

docker-compose script bower <EXTRA_CMD_ARGUMENTS |  default nothing>

docker-compose script bower install

Preocupaciones:

• Parece OverPowered crear otro elemento de nivel superior solo con el propósito de administrar el inicio, pero se deriva del hecho de que el nuevo formato declara el comportamiento en el nivel superior.
• Estoy tratando de imaginar una flexibilidad adicional (y problemas) que esto puede agregar.

Por último, en la función _groups_, suena bien, pero si tiene tantas agrupaciones, no veo el problema de crear archivos de composición acoplable para cada uno de ellos. Probablemente la característica que desea es la herencia de archivos de composición de docker , ¡eso sería increíble!

PD: @bfirsh tal vez si te gusta la idea puedes agregarla a las "Posibles sugerencias"

En segundo lugar, se trata de una renovación de la 4ª sugerencia debido al inminente nuevo formato de declaración de servicios.

Votar por la opción 2: más claro, más fácil de leer y no es necesario aprender nuevos conceptos
Solo quiero un servicio que no se inicie de forma predeterminada

¿Qué tal algo como disabled: true

@ cpuguy83 Eso parecería implicar que todo el servicio está deshabilitado, incluso por run . Lo encontraría confuso.

@qcho hmm, ahora que me he vuelto a familiarizar con Docker desde la 1.6, puedo ver de qué están hablando tú y @gittycat . En ese sentido, me gusta mucho el enfoque de

groups: # if no groups, all services are in the "default" group by…default
    - foo
    - bar
services:
  foo:
    image: imagine
    groups: foo
  bar:
    image: energy
    groups: bar
  baz:
    image: money
    # no groups, so "default"
   quux:
    image: word
    groups:
      - bar
      - default

Mientras tanto, en el caparazón ...

docker-compose up -d # Up all services in default group, so 'baz' and quux
docker-compose up -d --groups foo # Up all services in the foo group
docker-compose up -d --groups foo,default # You get the idea
docker-compose run --rm bar somecommand # We never started 'bar', so it can be a one-off command

Un enfoque como este sería increíble y evitaría la necesidad de este ticket, pero va más allá de su alcance.

@kojiromike No lo creo. Así es como los sistemas de inicio se refieren a los servicios que no deberían iniciarse automáticamente.

También es simple y cualquier "confusión" se puede resolver con documentación.
También lo encuentro mucho menos confuso que esta agrupación, que no tiene ninguna relación con el concepto de inicio de un servicio.

@ cpuguy83 Creo que la semántica de "servicios" es exactamente lo que confunde en primer lugar. Estoy de acuerdo en que la cuestión de la agrupación es una pérdida de alcance. En ese sentido prefiero el enfoque de la opción 4 / @qcho , donde claramente diferencian "servicios" de "cosas que no son servicios".

Ese es el punto, ¿por qué debería poner un contenedor que nunca ejecutará un servicio en una categoría de "servicio ... deshabilitado"? Suena como un parche feo que alguien hizo y no es intuitivo.

Quizás la "versión 2" del formato debería haber tenido en cuenta este problema. Por ejemplo, otra especificación podría ser

version: 3?
containers:
  webserver:
    ...
  database:
    ...
  cache:
    ...
  some_script_container:

services: (they are groups):
  production:
    webserver:
      ...
    database:
      ...
    cache:
      ...
  development:
    webserver:
      ... DEFINE SOME CUSTOM DEV STUFF ABOVE basic container definition
    database:
      ...
    cache:
      ...     

Ok ahora tenemos los servicios adecuados, con definición de grupos. Puedo iniciar un grupo de servicios de producción o desarrollo. O simplemente ejecute un script en some_script_container. como no está definido en ningún servicio, nadie se iniciará

@qcho Depende de la definición de un servicio, pero en cualquier caso, cuestionaría algo que solo debe ejecutarse en ocasiones, y el único humano puede determinar si debe ejecutarse o no.

Entonces, digamos que componer adopta algo como un objeto job .

1. los trabajos solo se ejecutan una vez
2. los trabajos se inician después de los servicios
3. se espera que los trabajos salgan
4. ???

Ahora redactar también necesita mantener algo de estado local sobre el trabajo, lo que actualmente no hace en absoluto.

Es por eso que agregar un auto-up: false o autorun: false simple es la forma más fácil y menos espeluznante (con alcance) de manejar esto.

@ cpuguy83 Creo que estás ampliando lo que digo con algo más complejo. No pretendo que docker-compose sepa sobre ningún trabajo o flujo de trabajo. Se pueden hacer scripts externos para eso. Lo que pretendo es que docker-compose defina la pila completa para que se ejecute una aplicación.

Puedo imaginarme a mí mismo creando un guión y manteniendo el estado que dices. Incluso llamando al script antes del inicio del servicio, no solo después. Lo que no me imagino es analizar el archivo del compositor porque necesito verificar qué volúmenes necesito importar, o qué configuración necesito extraer de él en un contenedor desconocido para ejecutar algún script que se aplique a él. Entonces creo que docker-compose debería darme ese contenedor; ejecutar el script y mantener el estado es mi problema.

No veo por qué la gente sigue diciendo eso

services:
  my-script-container:
    auto-up:false

Es más simple que:

scripts/containers/transients/you_name_it:
  my-script-container:

Es el mismo nivel de complejidad. Pero menos hacky semánticamente.

Para obtener las ideas en un hilo, referencia # 2803

Caso de uso: tiene un proyecto con muchos componentes y usuarios qué elegir y cuál instalar, pero el archivo de composición los instala todos.

Propuesta: Agregamos una opción para poner int he docker-cmpose.overrider.yml para excluir una imagen definida en el docker.compose

es decir

alguna-imagen:
excluir: sí

El comportamiento sería ignorar esa entrada en el docker-compose.yml

¿Puedes decirme lo que piensa el equipo? Me interesaría hacer el cambio.

Votar por el # 2 también ... simplemente se topó con esta necesidad hoy.

La propuesta de @jimzucker también funcionaría, aunque me gusta la idea de ver "start: false" en el archivo .yaml principal para darte una pista inmediata de que este "servicio" no se ejecutará a menos que lo llames explícitamente. De lo contrario, usted (o en mi caso, el usuario final / desarrollador al que le entregó los archivos de la ventana acoplable) debe recordar buscar un archivo de anulación.

+1 por 2. Tengo una situación en la que necesito crear una imagen de la ventana acoplable como parte de redactar, pero no se ejecuta como un servicio. Los otros servicios (que tienen un calcetín acoplable montado en su interior) ejecutan contenedores desde la imagen de vez en cuando.

+1 para 2. Y +1 para "auto-up" o "auto-run" como redacción.

¿Y no se pueden manejar los casos de grupos de servicios (como lo explica @gittycat) a través de variables de entorno como "auto-up: $ {ADMIN}"?

También veo casos de uso reales para marcar servicios en el docker-compose.yml para que no se inicien automáticamente con un docker-compose up simple, sino que se inicien solo explícitamente.

La solución 1) es una forma posible ahora, pero en mi opinión demasiado engorrosa, ya que uno tiene que especificar uno o más archivos yml en lugar de simplemente llamar a docker-compose up y tener que dividir o incluso duplicar los archivos.

Como realmente me gustaría ver algo como la solución 2) (como muchos otros también), implementé una prueba de concepto de esto en el # 3047 para que pueda jugar un poco con ella para ver si podría ser una solución viable. solución.

+1 para la opción 2

+1 para la opción 2

+1 para la opción 2

+1 para ambas opciones 2 y 4

+1 para las opciones 2 y 4

+1 para la opción 4. No se debe permitir alguna configuración para los scripts (por ejemplo: reiniciar: siempre)

con la opción 2, podría tener este extraño caso:

service:
  run_tests:
    build: ./tests/
    restart: always
    auto-start: "false"

que significa eso

@mathroc : Significa: "No inicie automáticamente este contenedor cuando se ejecute la

@niko oh cierto, debería pensar un poco más en eso antes de publicar ...

cambiando mi "voto" a +1 para la opción 2

+1 para la opción 2, lo necesitaba en varios proyectos.

haciendo ping a @dnephin :
¿Podría darnos una actualización sobre este tema? Dado que la mayoría de los comentarios aquí están a favor de la opción 2, ¿existen actualmente planes para implementar algo así (o la opción 3/4)?
Podría pulir mi solicitud de extracción (# 3047) y completarla con pruebas y documentación si considera fusionarla en ese momento.

Gracias.

+1 para la opción 2

+1 para la opción 2

+1 para la opción 2

Creo que la opción 1 podría funcionar, pero necesitamos una mejor manera de reducir la verbosidad de:

docker-compose -f docker-compose.yml -f docker-compose.tests.yml up

¿Quizás podría agregar una bandera simplificada / aumentada? docker-compose --augment tests up y se resuelve automáticamente si es una variación de docker-compose.yml ; de lo contrario, el usuario debería ser explícito.

Sin embargo, me gusta mucho la idea de una nueva palabra clave de nivel superior, tal vez suites y commands ?

La siguiente configuración permitiría:

docker-compose run -s application
docker-compose run -c cache-clear

suites:
    application:
        services:
            - database
            - memcached
            - application
    tests:
        extends: application
        services:
            - application

commands:
    cache-clear:
        service: application
        workdir: /var/www
        command/entrypoint: php app/console ca:cl

Puedo ver en el código que ya existe la noción de servicios "únicos" (en mi humilde opinión solo se usa cuando se llama docker-compose run .
¿Podría reutilizarse?
Si etiqueto un contenedor con com.docker.compose.oneoff=True , ¿intentaría iniciarlo?

De lo contrario, voto por la opción 2.

Me encontré con esto, así que aquí están mis dos casos de uso:

1. Variables de entorno "globales": el enfoque sugerido aquí es usar extends , con lo que estoy bien ... pero ahora necesito definir un image para esa cosa que estoy extendiendo , y ni siquiera puede usar scratch (así que terminó con https://hub.docker.com/r/tianon/true/).
2. Servicios de "escalado": por defecto tengo una instancia de MongoDB, pero para algunas pruebas me gustaría definir una segunda inactiva, que puedo abrir para esas pruebas. Aquí, usar extends en un archivo diferente parece una idea viable (aún aprendiendo sobre docker / docker-compose y las mejores prácticas involucradas).

+1 para la opción 2

+1 para la opción 2

+1 para la opción 2
Parece un simple cambio ...

+1 opción 2,

en el caso de uso de varios contenedores que comparten un conjunto común de envs y configuraciones, tiene sentido construir un contenedor base desde el que extenderse, pero no para iniciar el contenedor.

auto-start:true|false

Teniendo una buena solución desde septiembre pasado llamada rocker-compose , recomendaría ejecutar: _always_ | _once_ | _Nunca_. También me gusta el estado: _running_ | _ran_ | _creado_ también.

no soy un fanático de usar un proyecto separado solo para esta función, terminé robando el comando de código True ASM de tianon / true project hasta que esto se implemente

También pensé inicialmente que la opción 2 sería la mejor, pero ahora estoy empezando a pensar que sería demasiado restrictiva y poco después de agregarla, aparecería la necesidad de realizar tareas de una sola ejecución. De hecho, ahora estoy trabajando en un proyecto en el que necesito los siguientes casos de uso:

• dentro de la pila, quiero poder definir contenedores que se ejecutan una vez en la implementación inicial y cualquier ejecución futura solo se activa externamente (por ejemplo, programación / evento, a través de una llamada a la API, etc.) para que puedan inicializar / actualizar el estado del contenedor del servicio principal dentro de la misma pila (por ejemplo, datos / esquema de base de datos, volúmenes de datos de relleno, etc.)
• dentro de la pila quiero poder definir contenedores que solo se activan externamente para que se puedan usar para encapsular tareas de administración / utilidad (por ejemplo, inspección de estado / datos, etc.) y procesos que se activan según lo programado (por ejemplo, copia de seguridad) o por eventos externos (por ejemplo, desencadenar un proceso sobre cambios en un depósito S3)

En mi caso, la distinción entre state: created (se ejecutó 0 veces) y state: ran (se ejecutó> = 1 veces) es importante ya que algunas de las tareas de utilidad / administración pueden ser destructivas y solo deben usarse en determinadas circunstancias, como la migración de servicios.

Dado que ahora me estoy inclinando más hacia state: running | ran | created como en rocker-compose u opción 4 con el objeto _task_ o _job_ de nivel superior + capacidad para expresar una dependencia para que un servicio pueda activar una tarea para que se ejecute antes / después de sí mismo .

Me gustaría mencionar que esto es importante para mi caso de uso. Utilizo docker-compose para crear un entorno de prueba y ejecutar un conjunto de pruebas. El problema de iniciar todos los contenedores a la vez es que no puedo permitir que los contenedores de servicio (como la base de datos o los trabajadores de apio) se inicialicen antes de ejecutar el conjunto de pruebas.

Sería preferible poder lograr algo como:

$ docker-compose --file="docker-compose-testing.yml" up -d --exclude=tests
$ sleep 5
$ docker-compose --file="docker-compose-testing.yml" run --rm tests

Puede imaginarse que se podría escribir algo más elaborado que sleep 5 para verificar que se haya producido la inicialización, pero no es necesario para el fragmento de ejemplo.

No leí una opción sobre una bandera cli. Por lo tanto, propondría que se agregue una bandera --exclude a la lista de opciones. La bandera --exclude le indicaría al comando up no inicie el contenedor especificado. La bandera --exclude se analizaría de modo que se puedan excluir varios contenedores del inicio según sea necesario.

: +1:

Teniendo en cuenta otro caso de uso en el que la opción 2 sería una solución adecuada: iterar en un nuevo subservicio dentro de una aplicación existente. La mayoría de los desarrolladores del proyecto no van a necesitar el nuevo servicio todavía, y definitivamente no querrás que los problemas obstaculicen su trabajo, pero también querrás evitar mantener una rama fuera del árbol durante un período prolongado de tiempo. hora.

Un archivo "docker-compose-experimental.yml" separado _podría_ funcionar, pero significa que toda la documentación para trabajar en ese componente debe escribirse de una manera mientras el componente aún es experimental, y luego revisarse una vez que se convierte en parte del conjunto estándar de servicios.

+1 a la opción 2

+1 para la opción 2

+1 para la opción 2

+1 para la opción 2

+1 para la opción 2

@acran Me gustaría ver que envíe su solicitud de extracción para ver si podemos obtener algo de tracción para avanzar, tal vez si reajusta para eliminar el conflicto en # 3047, se detectará, no estoy seguro de cómo llamar la atención sobre esto.

@jimzucker bueno # 3047 ya es una solicitud de extracción y todavía estoy esperando algunos comentarios de los desarrolladores: decepcionado:

Vea mi comentario anterior : hacer que el PR sea digno de fusionarse aún requiere algo de pulido, es decir, actualizar documentos relacionados y casos de prueba. Pero prefiero no hacer ese trabajo sin saber que se considerará que este enfoque está integrado por upstream. De lo contrario, mis esfuerzos en esto podrían ser inútiles ...

+1 opción 2

@acran , me gustaría ayudarlo a actualizar documentos relacionados y casos de prueba. Está bien ?

+1 opción 2

¿O quizás definir un tipo de trabajo, como en Kubernetes?

+1 para la opción 2

Tenemos un docker-compose con múltiples servicios y uno de ellos (la base de datos) debe ser lanzado en el entorno de desarrollo pero no en el entorno de producción. Por lo tanto, tenemos que mantener dos archivos de composición acoplable. ¡La opción 2 es exactamente lo que estamos buscando!

: +1: para la opción 2

+1 opción 2

@acran Me estoy comunicando con algunas conexiones aquí en SF para averiguar el proceso / canal correcto para obtener comentarios para que esto pueda avanzar, estad atentos;)

👍 para la opción 2

+1 para la opción 2

+1 opción 2

+1 opción 2

También voto por la opción 2

Otra idea: ahora tenemos networks y volumes nivel superior, también podríamos agregar una opción images . Esto sería un indicio para Compose de que estas imágenes deben extraerse o compilarse para que la aplicación funcione, pero no se ejecutarían cuando haga docker-compose up .

Esto funcionaría para dos casos de uso, fuera de mi cabeza:

1) El problema común aquí, donde desea que se ejecute algún tipo de comando de administración. docker-compose run podría volver a ejecutar imágenes si el servicio no existe.
2) Aplicaciones como esta que ejecutan imágenes de Docker pero no se ejecutan todo el tiempo.

/ cc @dnephin @aanand @ shin-

Excepto que sería bueno poder configurar todas las opciones que necesitaría un contenedor a corto plazo (es decir, los volúmenes / puntos de montaje, redes, enlaces, nombre, etc.) en el archivo docker-compose para que no tienes que seguir agregándolos cada vez que necesites ejecutar ese contenedor ...

El 13 de septiembre de 2016 a las 3:58:41 AM CDT, Ben Firshman [email protected] escribió:

Otra idea: ahora tenemos networks y volumes nivel superior, podríamos
agregue una opción images también. Esto sería una pista para componer que estos
las imágenes deben extraerse o compilarse para que la aplicación funcione, pero
no se ejecutará cuando lo haga docker-compose up .

Esto funcionaría para dos casos de uso, fuera de mi cabeza:

1) El problema común aquí, donde desea algún tipo de gestión
comando para ejecutar. docker-compose run podría volver a ejecutar imágenes
si el servicio no existe.
2) Aplicaciones comoesto que corre
Imágenes de Docker, pero no se están ejecutando todo el tiempo.

/ cc @dnephin @aanand @ shin-

Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/docker/compose/issues/1896#issuecomment -246618909

Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpe mi brevedad.

Estoy de acuerdo con @mgriego en esto. Piense en un contenedor generador de compilación: sería mejor tener el comando y las opciones configurados y solo docker-compose up foo y hacer que compile y salga.

Tratando de comprender mejor aquí: ¿Es la opción 2) solo un caso especializado del más general "queremos un initial_scale en docker-compose.yml "? (ver # 1661, # 2496 et. al.)

@ankon para nada.

agregar una images [sección]

@bfirsh, esto comienza a moverse en la dirección que tomé con https://github.com/dnephin/dobi. Me alejé de tener "secciones" (y en su lugar usé solo elementos de nivel superior para cada recurso). Creo que sería difícil hacerlo funcionar con el modelo Compose.

1. networks y volumes nunca se operan realmente directamente, simplemente se crean según las necesidades de un contenedor. Dividir imágenes en su propia sección no va a cambiar el comportamiento que tenemos ahora, solo complicaría la configuración de Redactar. Si solo desea crear una imagen, ejecute docker-compose build .
2. No creo que realmente solucione los problemas identificados en este problema. La gente quiere contenedores, no solo la imagen

Releyendo el hilo y la discusión en # 2496 sobre la declaración de restricciones de escala en el archivo de redacción, estoy prefiriendo la Opción 4 (es decir, una nueva sección de nivel superior) sobre la Opción 2.

Específicamente, un nombre de sección como utilities sería una buena opción: componentes que normalmente no se necesitan, pero cuando los necesita, desea tener preconfigurados a qué otros componentes están vinculados en lugar de tener que hacerlo. hacer que la gente construya ellos mismos un encantamiento docker run adecuado.

Ese enfoque cubriría no solo los comandos de administración únicos, sino también los servicios auxiliares de depuración e introspección como pgweb y Celery Flower (que son muy útiles para ejecutar en desarrollo, pero que normalmente no querría en producción debido a la seguridad adicional superficie de amenaza que crean).

Definir la semántica de estos nuevos "no servicios" también se vuelve mucho más fácil: son _exactamente_ lo mismo que services (incluidos todos los cambios futuros a ese formato), con la única excepción de que los comandos no calificados como docker-compose build , docker-compose pull y docker-compose up ignórelos por completo; si desea que se procese cualquier componente de la lista "utilidades" en lugar de "servicios", debe nombrarlo específicamente (aunque hay tal vez podría ser una opción --all , similar a la actual para docker-compose rm ). Sin embargo, la CLI para interactuar con estas utilidades por nombre sería idéntica a la de interactuar con los servicios normales (a diferencia del status quo, donde debe especificar el archivo de configuración de la utilidad adicional), y docker-compose se encargaría de evitar conflictos de nombres entre las definiciones de servicio y utilidad.

Si bien la propuesta de escala en el n. ° 2496 podría usarse (ab) para obtener este comportamiento, todavía se siente como una solución alternativa en lugar de una característica diseñada correctamente.

Me gusta ese diseño, @ncoghlan.

En lugar de utilities ¿qué tal simplemente nombrarlo .services ? Esto naturalmente transmite que services y .services usan exactamente la misma semántica, la única diferencia es que .services no se ejecutan de forma predeterminada. Es un análogo bastante parecido a los nombres de archivo que no se muestran de forma predeterminada. Supongo que la desventaja es que la distinción entre los dos es un poco sutil.

Me gusta la idea básica de la que habla

1. No esté de acuerdo en que _todos_ los comandos no calificados deberían ignorar estas utilidades por defecto. En mi opinión, todos los comandos deberían ejecutarse normalmente, excepto aquellos que darían como resultado un contenedor en ejecución. (Básicamente, up y start .)
2. Con respecto al comentario de

@bfirsh @ncoghlan Estoy totalmente de acuerdo con @dnephin :

No creo que realmente solucione los problemas identificados en este problema. La gente quiere contenedores, no solo la imagen

Lo que yo, y creo que la mayoría de las personas aquí, necesitamos para mi flujo de trabajo deseado son servicios simples; se definen como cualquier servicio normal, se inician / detienen como servicios normales, etc.
La _única_ diferencia es que no se inician automáticamente con un docker-compose up simple de forma predeterminada, sino solo cuando se especifican explícitamente (o se incluyen como una dependencia).

Por lo tanto, no veo ninguna necesidad de una nueva sección de nivel superior o un concepto completamente nuevo para estos contenedores únicos, sino solo un parámetro de configuración opcional por servicio.
Implementé esto en mi solicitud de extracción # 3047 como prueba de concepto. Es un cambio bastante pequeño, pero satisfaría completamente mis casos de uso. Entonces, si hay algo más que pueda hacer, para fusionar esto, hágamelo saber (=

Para cualquiera que quiera probar esto, aquí los comandos para construir y ejecutar docker-compose en un contenedor:

# download and build
git clone [email protected]:acran/compose.git -b auto_up
cd compose
docker build -t docker-compose .

# create an example docker-compose.yml
cat > docker-compose.yml <<EOF
version: "2"
services:
  foo:
    image: busybox
    auto_up: false
    command: echo foo
  bar:
    image: busybox
    auto_up: false
    command: echo bar
    depends_on:
      - foo
  baz:
    image: busybox
    command: echo baz
EOF

# start all default services only, i.e. baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up

# start service foo only
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up foo

# start service bar, foo is pulled in as a dependeny
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up bar

# clean up all services, i.e. foo, bar and baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose down

@acran , me gustaría ayudarlo a actualizar documentos relacionados y casos de prueba. Está bien ?

@ dattran-vn01 por supuesto, estaría feliz: smiley:

@acran en su ejemplo, el único comando que tiene un comportamiento diferente al Componer actual es el primero, y ese comportamiento se puede lograr usando up baz .
También puede lograr lo mismo utilizando varios archivos de composición.

Hacer que algunos comandos operen en una lista diferente de servicios predeterminados parece muy confuso y ha sido una de las razones por las que no me gusta esta función.

@acran en su ejemplo, el único comando que tiene un comportamiento diferente del actual Compose es el primero, y ese comportamiento se puede lograr usando up baz.
También puede lograr lo mismo utilizando varios archivos de composición.

@dnephin sí, exactamente, lo sé, y en este ejemplo sería la forma más fácil.
Pero imagina esto con 10 servicios y solo un servicio único (como "init" o "backup" / "dump"): en ese caso, tendrías que listar todos los servicios en la línea de comando, excepto uno solo- fuera de servicio como docker-compose up service1 service2 ... service10 (ver más abajo). Especialmente tendrías que recordar todos los servicios y realizar un seguimiento manual de cualquier cambio en el docker-compose.yml .

También conozco la posibilidad de usar múltiples archivos YAML, vea mi primer comentario arriba , y esto, además de brindar explícitamente todos los servicios en la línea de comando, cubre la mayoría de los casos de uso indicados aquí; pero se siente más como una solución alternativa.

Aquí otro ejemplo docker-compose.yml para visualizar el problema:

version: "2"
services:
  init:
    image: busybox
    auto_up: false
    command: echo "I do one-time initializing"
  service1:
    image: busybox
    command: echo "I'm service #1"
  service2:
    image: busybox
    command: echo "I'm service #2"
  service3:
    image: busybox
    command: echo "I'm service #3"
  service4:
    image: busybox
    command: echo "I'm service #4"
  service5:
    image: busybox
    command: echo "I'm service #5"
  service6:
    image: busybox
    command: echo "I'm service #6"
  service7:
    image: busybox
    command: echo "I'm service #7"
  service8:
    image: busybox
    command: echo "I'm service #8"
  service9:
    image: busybox
    command: echo "I'm service #9"
  service10:
    image: busybox
    command: echo "I'm service #10"

Un simple docker-compose up _con_ el atributo auto_up comienza aquí todos los servicios excepto el servicio init . Para lograr lo mismo sin él, sería necesario escribir un comando mucho más largo con 10 servicios o dividir el archivo YAML y tener que especificar varios archivos.

Por lo tanto, la función solicitada aquí tiene más que ver con la conveniencia y escribir menos en el cli y no con una función completamente nueva.

Con respecto a la opción "usar varios archivos de configuración" (que de hecho es la mejor opción disponible actualmente), el problema de usabilidad con eso es que se ve así en la práctica:

$ docker-compose up one-shot-command
ERROR: No such service: one-shot-command
$ docker-compose up -f docker-compose.yml -f docker-compose-utils.yml one-shot-command
# Actually goes & does the requested thing

La discrepancia luego infecta _toda_ la documentación y la automatización de su proyecto: debe asegurarse de que _dos_ archivos de redacción estén disponibles para cualquiera que desee ejecutar comandos de utilidad, debe asegurarse de que se proporcione la invocación completa para los comandos en el archivo de utilidad, y si hay algún comando o el servicio se degrada de "siempre en ejecución" a "solo se ejecuta cuando se solicita explícitamente", debe buscar cualquier invocación que no proporcione los nombres del archivo de configuración y agregarlos.

Eso es todo _haz posible_, es simplemente molesto en comparación con poder decir en el archivo de redacción "Ejecutar esto solo cuando se lo pida explícitamente, nunca ejecutarlo de forma predeterminada".

Alguien me dijo una vez: _ "Si varias personas inteligentes no pueden decidir cuál es el mejor enfoque, por lo general ninguno es bastante malo. Lo peor es no hacer nada". _

Esta tarjeta parece un excelente ejemplo de esto :)

Dado que Docker ahora admite el concepto de servicio de forma nativa para comandos de larga ejecución, creo que el mejor enfoque sería agregar una nueva sección llamada comandos que permita la misma funcionalidad que los servicios, excepto las políticas de reinicio, que no deberían estar permitidas.

En mi configuración, tengo servicios en el docker-compose que son necesarios para ejecutar mi infraestructura (nginx, base de datos, servidor web, colas de mensajes ...). También he definido servicios adicionales que solo necesito por motivos de depuración (por ejemplo, una interfaz web de base de datos).

Me gustaría que los servicios de "depuración" NO se inicien automáticamente, pero si quiero agregarlos, puedo hacerlo con un simple docker-compose up -d database-gui y simplemente se agrega.

Además: A veces cambio de opinión y quiero que uno de estos servicios comience siempre ... => Con la opción 2) Puedo cambiar esa bandera

=> Vote por la opción dos, porque es simple y parece satisfacer los requisitos de todos aquí. Todas las demás soluciones me parecen una ingeniería excesiva ... Agregar complejidad a la configuración basada en casos de uso raros o imaginarios, no en una necesidad práctica.

Solo aquí para agregar mi +1. Estoy ejecutando aplicaciones de Django y cuando las ejecuto en la ventana acoplable sería bueno tener un contenedor que ejecute shell o pruebas o, para el caso, migre comandos. Pero no quiero ejecutar ninguno de estos cada vez que inicio la aplicación. Si bien el uso de múltiples archivos de configuración funcionaría, requeriría escribir, escribir secuencias de comandos o alias de líneas de comando de millas de largo. Si quisiera hacer eso, no usaría componer en absoluto, solo usaría un script de shell para mis contenedores (o un script de Python para ellos ... tal vez agregar un archivo YAML unificador para almacenar configuraciones de contenedores ... espere ...) No quiero hacer nada como docker-compose -f common.yml -f dev.yml -f local.yml -f commands.yml up migrate solo para ejecutar migraciones de base de datos en mi contenedor. La alternativa es usar /bin/true como comando y hacer algo como docker-compose -f common.yml -f dev.yml -f local.yml up commands 'python3 manage.py migrate' que tampoco es muy elegante. Entonces, tener comandos únicos almacenados en algún lugar de la configuración sería muy útil para mí. Cualquiera de las opciones 2, 3 y 4 funcionaría para mí.

Me gustaría sugerirle que eche un vistazo a dobi , que es una herramienta en la que he estado trabajando basado parcialmente en los comentarios de este hilo.

compose está diseñado para iniciar servicios de larga duración que forman un "entorno".
dobi se centra en tareas de creación de proyectos secuenciales.

Las cosas que está buscando (ejecutar un shell, ejecutar pruebas unitarias, ejecutar la migración) son todas tareas del proyecto, por lo que encajan mucho mejor en el modelo dobi.

dobi y compose funcionan bastante bien juntos, puede iniciar compose desde dobi usando un recurso de redacción.

compose=dev-environment:
  files: [docker-compose.yml, local.yml]
  project: 'theprojectname'

que puedes ejecutar usando:

dobi dev-environment

Hay un ejemplo de la integración de redacción y la ejecución de migraciones de db aquí: https://github.com/dnephin/dobi/tree/master/examples/init-db-with-rails

Hay ejemplos de muchos de los flujos de trabajo (incluida la ejecución de pruebas, el inicio de un shell interactivo, la liberación y la creación de imágenes mínimas) aquí: http://dnephin.github.io/dobi/examples.html

+1 por 2). En nuestro punto de vista, no es necesario pensar y discutir casos de uso poco comunes como comandos únicos, pero solo queremos tener servicios reales que estén creados y listos para usar, pero que se puedan iniciar a pedido cuando sea necesario (y por defecto no consumen recursos).

"casos de uso poco comunes"? ¿Ejecutas migraciones de bases de datos? ejecutas pruebas unitarias? corres pelusa? paquete web?

Sí corro pero eso se puede lograr y controlar dentro de contenedores, en mi opinión. Pero no quiero restarle mérito a su punto de vista o demandas, no hagamos que esta discusión se encienda. Nuestros requisitos sobre la composición de Docker no están necesariamente en conflicto.

Me encontré con este hilo tratando de encontrar una manera de crear un contenedor de composición acoplable para un script que borra la base de datos en mi contenedor mysql y vuelve a cargar el esquema desde un volcado descargado. Es un proceso muy largo y destructivo, por lo que no quiero que se ejecute cada vez que abro los servicios, pero también debe ejecutarse dentro del conjunto compuesto de contenedores usando su propio archivo docker.

Llámalos tareas, comandos, lo que sea, pero soy un poco SOL sin eso.

Me encontré con esto buscando algo más, solo quería agregar un caso de uso ... Descubrimos que nuestros desarrolladores eran los más capaces de definir qué datos deberían respaldarse desde sus servicios. Como el archivo docker-compose.yml está en sus manos y se usan volúmenes con nombre, decidimos usarlo para definir las estrategias de respaldo ... Aquí hay un ejemplo resumido de nuestro antiguo docker-compose.yml que estábamos usando.

version: '2'
services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    restart: always
    ports:
      - "5555:5555"
    volumes:
      - gitlab_config:/etc/gitlab
      - gitlab_logs:/var/log/gitlab
      - gitlab_data:/var/opt/gitlab
      - certificates:/etc/gitlab/ssl
      - registry_data:/var/opt/gitlab/gitlab-rails/shared/registry
  gitlab-runner:
    image: gitlab/gitlab-runner:latest
    restart: always
    volumes:
      - certificates:/etc/gitlab-runner/certs
      - /var/run/docker.sock:/var/run/docker.sock
volumes:
    gitlab_config:
      driver: local
    gitlab_logs:
      driver: local
    gitlab_data:
      driver: local
    certificates:
      driver: local
    registry_data:
      driver: local

Para poder hacer una copia de seguridad de los datos de los volúmenes, decidimos usar un contenedor busybox para almacenar los datos necesarios, pero tiene que ser flexible y hacer solo los volúmenes que los desarrolladores quieren respaldar. Finalmente, deberíamos poder hacer una copia de seguridad de cada volumen por separado. Para lograr esto, agregamos 3 servicios a todos nuestros docker-compose.yml

  boot:
    image: busybox
    depends_on:
      - gitlab
      - gitlab-runner

  backup:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type d -maxdepth 1 -mindepth 1 -exec tar cvf /backup/{}.tar {}  \;
    working_dir: /backup

  restore:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type f -iname "*.tar" -maxdepth 1 -mindepth 1 -exec tar xvf {} \;
    working_dir: /backup

Los servicios de copia de seguridad y restauración solo requieren ser configurados usando los volúmenes, los comandos harán el resto. Estamos planeando agregar un poco de configuración para poder elegir qué volúmenes respaldar o restaurar, pero por ahora, los hacemos todos ... Ya que no queremos que esos 2 servicios se inicien en cada docker-compose up, necesitábamos especificar todos los servicios que queríamos, lo cual puede ser tedioso ... Así que agregamos un servicio ficticio llamado boot, todo lo que hace es depender de todos los servicios que deben ejecutarse y simplemente lo llamamos cuando docker-componer.

Esto aquí está lleno de pequeños trucos, pero nos permite ejecutar fácilmente docker-compose up backup para tener nuestra copia de seguridad almacenada en / backups / latest del host y desde allí ejecutamos nuestra lógica de control de versiones / poda.

Espero que ayude a alguien que está tratando de lograr algo similar ... Pero al final, al poder decirle a docker-compose que no arranque esos 2 servicios, no necesitaríamos un tercero y complicar nuestro docker-compose comandos.

En desarrollo, actualmente tenemos 4 archivos docker-compose:

• docker-compose.yml : Define los servicios centrales necesarios para operar completamente nuestra aplicación, por ejemplo, redis, MySQL, php-fpm, procesador de cola Laravel, nginx, Solr
• docker-compose-utils.yml : define los servicios de utilidad necesarios para ejecutar tareas de desarrollo, por ejemplo, gulp, npm, artisan (Laravel), composer, redis-cli, que generalmente se ejecutan con los servicios anteriores
• 2 archivos de composición acoplable más para definir el entorno y los volúmenes de los servicios anteriores

Esta configuración funciona bien ya que, fuera de Docker, tenemos dependencias mínimas para nuestro entorno de desarrollo. El inconveniente son las líneas de comando difíciles de manejar necesarias para especificar todos los archivos .yml necesarios para ejecutar utilidades simples.

Desarrollamos en macOS, Windows y Linux. Además, muchas de nuestras tareas de desarrollo requieren algún tipo de parametrización (por ejemplo, crear una migración de base de datos, ejecutar un comando composer / artisan / npm con sus propios argumentos), así que creé schmich/runx como una instalación cruzada de cero plataforma de ejecución de tareas para agrupar nuestras tareas de desarrollo comunes.

Por ejemplo, esto nos permite decir runx migrate : make create_some_table para ejecutar efectivamente docker-compose -f docker-compose.yml -f docker-compose-utils.yml -f docker-compose-dev.yml -f docker-compose-utils-dev.yml run --rm artisan migrate:make create_some_table , o runx npm outdated para ver nuestras dependencias JS obsoletas.

No he usado dobi mencionado anteriormente, pero runx siente similar en espíritu, aunque menos adaptado a un entorno Docker. En última instancia, quiero evitar las dependencias en todas partes, excepto donde sea absolutamente necesario: para los servicios en sí y para los scripts de utilidad necesarios en el desarrollo.

¿Hay noticias? ¡Creo que sería muy bueno tener esta función! Voto por la solución de una configuración de nivel superior como default donde podemos especificar qué servicio se debe ejecutar.
El servicio ficticio boot es bueno, sin embargo, prefiero dejar el proceso en primer plano, por lo tanto, cuando termine con este trabajo, simplemente puedo cerrar la terminal para bajar todo. También es bueno tener la salida adjunta por defecto y esto no sucede con el servicio ficticio.

Dado que nadie comentó casos de uso utilizando archivos .env, aquí está el mío:

Tengo 4 archivos de composición: docker-compose.yml, docker-compose.local.yml, docker-compose.prod.yml y docker-compose.ci.yml. Para cada entorno tengo un .env diferente:

CI .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.ci.yml
WEB_PORT=8081
...

Test/dev/etc .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.local.yml
WEB_PORT=80
...

Y así...

Los usuarios y / o scripts no tienen que preocuparse por qué archivos de composición usar, ya que los entornos ya están configurados individualmente.

Pero tengo una instancia de mantenimiento para ejecutar eventualmente, no se puede configurar dentro de main docker-compose.yml y una solución sería crear un docker-compose.worker.yml y ejecutar una línea de comando con 3 opciones "-f" que cambian con cada ambiente. Eso es demasiado propenso a errores para ser una opción utilizable.

La solución que encontré fue crear un directorio "trabajador", poner el archivo yml allí, vincular el archivo .env superior a este directorio y crear archivos docker-compose. [Ci | local | prod] .yml vacíos (de lo contrario, habría para cambiar el valor de la variable COMPOSE_FILE).

Esto funciona bien, pero está lejos de ser óptimo. Cualquier otra solución del OP resolvería esto sin ningún problema.

Creo que la discusión aquí, los muchos ejemplos de casos de uso, así como el hecho de que con frecuencia hay problemas duplicados en esta apertura, deja bastante claro que _ existe_ una demanda real por parte de muchos usuarios de la posibilidad de "Definir servicios que no se inician de forma predeterminada ".

Por lo tanto, realmente me gustaría mover la discusión aquí de _si_ esto debería implementarse más a _ cómo_ debería implementarse. ¿Podríamos todos estar de acuerdo en esto ?

Con respecto a _cómo_ esto podría lograrse, @bfirsh enumeró algunas opciones en el comentario de apertura:

1) Recomiende a los usuarios que utilicen un archivo de redacción independiente

Esta es la única solución disponible actualmente para este caso de uso. Pero como se dijo anteriormente, en este caso es más una solución, ya que requiere escribir manualmente líneas de comando largas y recordar qué archivos de Redacción incluir para qué comando ejecutar.
Por supuesto, en una configuración de CI o implementación automatizada en producción, esto no es un problema, ya que la línea de comandos solo debe definirse una vez y nunca debe escribirse manualmente. Por lo tanto, se trata únicamente de la conveniencia en entornos no automatizados, es decir, el desarrollo, que de acuerdo con el manual de docker-compose es uno de los principales casos de uso de Compose en sí:

Juntas, estas características brindan una manera conveniente para que los desarrolladores comiencen a trabajar en un proyecto. Compose puede reducir una “guía de introducción para desarrolladores” de varias páginas a un solo archivo de Compose legible por máquina y algunos comandos.

Tener que escribir algo como docker-compose -f docker-compose.yml -f docker-compose-utils.yml run init solo para inicializar una configuración local no me suena _conveniente_ pero más como algo que se puede encontrar en _una “guía de inicio para desarrolladores” de varias páginas _.

Y para considerar la opción 1b) aquí:

Recomendar a los usuarios que utilicen un script / herramienta de envoltura para utilizar archivos de redacción separados

Si tengo que incorporar herramientas y dependencias adicionales solo para esto, ¿por qué usar docker-compose en primer lugar? Dado que todo lo que hace docker-compose podría, en teoría, también hacerse con solo un script de shell personalizado y el cliente nativo docker directamente.
Veo la principal ventaja de docker-compose en su interfaz de usuario estandarizada (clono un proyecto, veo un docker-compose.yml allí y sé que solo tengo que ejecutar docker-compose up para comenzar) . Tener que saber siempre qué archivo de redacción usar para lo que debilita drásticamente esta ventaja.

2) Agregue una opción a los servicios para que no se inicien de forma predeterminada
3) Agregue una opción de configuración de nivel superior para definir los servicios predeterminados

Estas dos opciones hacen básicamente lo mismo: definir qué servicios deben (no) iniciarse de forma predeterminada en un archivo de redacción , opción 2) mediante la inclusión de servicios individuales en la lista negra, opción 3) mediante la inclusión global de un conjunto de servicios en la lista blanca.
Teniendo en cuenta que la mayoría de las veces hay más servicios predeterminados que "servicios únicos" en un solo archivo de redacción, probablemente sea más fácil incluir un servicio en la lista negra que tener que incluir todos los demás en la lista blanca y tener que actualizar la lista blanca cada vez que se obtiene un servicio predeterminado. agregado o eliminado. También con la opción 2) probablemente sea más fácil fusionar varios archivos de redacción.

4) Agregue un concepto de algo como un servicio, pero es solo para comandos únicos ("scripts", "tareas", etc.)

Creo que la opción 4) es solo una especialización de la opción 2) o 3) ya que en la mayoría de los ejemplos anteriores, los contenedores únicos deseados se definen básicamente como cualquier otro servicio y no hacen nada más o menos como los servicios normales, excepto que no se inician de forma predeterminada. (O me perdí alguna diferencia significativa en un "servicio").

Entonces, en mi opinión, la opción 2) es la mejor opción aquí, ya que requiere el menor cambio pero al mismo tiempo es lo suficientemente flexible como para satisfacer la mayoría (¿o todos?) De los casos de uso mencionados aquí y ser muy conveniente de usar al mismo tiempo.
Sin embargo, estaría igualmente feliz de ver algo así como la opción 3) o 4) fusionada en la fase inicial. Entonces, después de más de un año de discusión aquí, ¿hay algún cronograma de cuándo o si esto sucederá?

Estoy de acuerdo en que la opción 2 es probablemente la menos invasiva. La única característica que veo que la opción 4 podría proporcionar es la capacidad de ejecutar comandos en contenedores existentes (usando el mecanismo de ejecución de docker). Por ejemplo, si todo lo que quiero es ejecutar una migración de base de datos o pruebas unitarias, es posible que no haya razón para crear un contenedor completamente separado si ya tengo un contenedor que ejecuta mi aplicación. Dicho esto, los contenedores son livianos y estaría perfectamente satisfecho con la opción 2.

@MadWombat Tengo la misma sensación sobre la opción 4, por eso propuse otra característica para este caso de uso: # 4096. hay una superposición con la función descrita aquí, pero creo que podría ser útil por sí sola o adicionalmente a esta

@mathroc Mencioné la opción 4 usando docker exec, ya que @acran preguntó si había alguna diferencia significativa entre las opciones 2 y 4. Sin embargo, no puedo

La única característica que veo que la opción 4 podría proporcionar es la capacidad de ejecutar comandos en contenedores existentes (usando el mecanismo de ejecución de docker).

De hecho, ese es un nuevo caso de uso que justificaría (y requeriría) la introducción de un nuevo concepto de nivel superior diferente de los servicios. Pero siempre que los comandos no necesiten ejecutarse a través de docker exec dentro del contenedor de servicios ya existente, el concepto de servicio existente debería ser suficiente.

Sin embargo, no puedo proponer un caso de uso de la vida real en el que desee específicamente ejecutar un comando en un contenedor existente en lugar de abrir otro contenedor similar para ese propósito.

El caso más cercano en el que puedo pensar es algo así como cambiar un archivo de configuración dentro del contenedor y activar una recarga por parte de la aplicación; usando el ejemplo de @mathroc de # 4096:

version: "2"
services:
  my_service:
    image: my/service
shortcuts:
  start-debugging:
    service: my_service
    command: echo "debug=true" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config
  stop-debugging:
    service: my_service
    command: echo "debug=false" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config

Aunque está relacionado con este problema, el # 4096 tiene sus propios casos de uso y tal vez la opción 4) ¿podría trasladarse mejor allí?

Ha pasado más de un año de discusión y parece que no estamos más adelante tomando una decisión. @bfirsh debería elegir un estilo y

+1

+1, sería una característica muy útil.

Y otro +1 para la opción 2, con algo como auto-start: false o enabled: false .

Mi caso de uso es la ampliación de servicios. No es posible extender servicios que tienen depends_on establecidos, así que lo que me gustaría hacer es definir una plantilla de servicio y luego extender varios servicios a partir de ella. Obviamente, la plantilla debe construirse, pero no ejecutarse automáticamente.

Creé mi propia solución, uso gratuito.
Todavía está en Beta :)

https://github.com/jonathanborges/picles-docker

Muchas opciones geniales aquí. La necesidad de la función es real.

La opción 2 es claramente la más popular:

1 -> 4
2 -> 52
3 -> 3
4 -> 10

Otro 👍 para la opción 2

Podemos manejar esto con bastante facilidad en un servicio de "herramientas" con un punto de entrada o comando inicial que simplemente regresa. Luego ejecutamos este servicio con un comando alternativo para hacer lo que queremos (por ejemplo, probar o sembrar los datos). P.ej

docker-compuse up -d
docker-compose run tools tests

Sí, el servicio de herramientas se mostrará como "detenido" en docker-compose ps . Si esto es inaceptable, entonces la opción de múltiples archivos de https://github.com/docker/compose/pull/2051 funciona. p.ej

docker-compose -f docker-compose.yml -f docker-compose-tools.yml up -d
docker-compose -f docker-compose-tools.yml logs -f tools

Aunque parece que se están escribiendo muchos ayudantes de orquestación para esta necesidad y yo también soy culpable de trabajar en uno :).

Personalmente, creo que hay suficientes soluciones (como las dos anteriores; ser creativo con sus puntos de entrada / contenedores y / o usar el enfoque de múltiples archivos con un alias / ayudante de shell), y la composición se puede mantener simple.

@briceburg vea la discusión anterior : el problema aquí no se trata de una funcionalidad faltante que no se podría hacer de otra manera. Existen _son_ soluciones alternativas para casi todo lo que la gente aquí quiere lograr. Pero son soluciones alternativas y trucos sucios en lugar de un caso de uso normal de docker-compose.

Se trata de la conveniencia, de no tener que escribir docker-compose -f docker-compose.yml -f docker-compose-tools.yml up a mano en el cli, se trata de no tener que recordar si fue docker-compose run tools tests o docker-compose run utils tests o incluso tener que confiar en una _ "guía de introducción para desarrolladores" de varias páginas _ pero, en cambio, tiene una interfaz unificada y sencilla para el desarrollador.

Una vez más, CCing @bfirsh, @dnephin: ¿podría proporcionar retroalimentación _cualquier_ a este problema? ¿Hay alguna esperanza de que podamos ver algo como esto en la próxima hoja de ruta por docker-compose ?

@briceburg para un entorno simple, tal vez una solución alternativa sea aceptable, pero a veces no lo es. Mira mi configuración:

rancher<strong i="7">@rancher</strong>:~/servers/sgi/docker$ ls -l 
total 64
-rwxrwxr-x 1 rancher rancher  303 Dec  8 20:05 cleanup.sh
drwxrwxr-x 3 rancher rancher 4096 Dec 16 15:26 conf
drwxrwxrwx 4 rancher rancher 4096 Dec 15 20:03 data
-rw-rw-r-- 1 rancher rancher   94 Dec 14 19:40 docker-compose.amt.yml
-rw-rw-r-- 1 rancher rancher  295 Dec  8 20:05 docker-compose.auth.yml
-rw-rw-r-- 1 rancher rancher  332 Dec  8 20:05 docker-compose.ci.yml
-rw-rw-r-- 1 rancher rancher  112 Dec  8 20:05 docker-compose.dbext.yml
-rw-rw-r-- 1 rancher rancher  347 Dec 14 19:40 docker-compose.dbint.yml
-rw-rw-r-- 1 rancher rancher  688 Dec 15 16:31 docker-compose.full.yml
-rw-rw-r-- 1 rancher rancher   81 Dec  8 20:05 docker-compose.local.yml
-rw-rw-r-- 1 rancher rancher  288 Dec 15 16:31 docker-compose.yml
-rwxrwxr-x 1 rancher rancher  721 Dec 14 19:40 redeploy.sh
-rwxrwxr-x 1 rancher rancher  861 Dec  8 20:05 setup.sh
-rwxrwxr-x 1 rancher rancher   66 Dec  8 20:05 shutdown.sh
-rwxrwxr-x 1 rancher rancher  269 Dec 14 19:40 startup.sh
drwxrwxr-x 2 rancher rancher 4096 Dec 14 19:40 worker

Tengo 8 archivos de composición (que uso en múltiples combinaciones) además de los que están en el directorio worker , donde configuro los contenedores 'no iniciar por defecto'. El directorio worker (con un archivo .env vinculado al padre y algunos archivos de composición vacíos para el cumplimiento de la variable .env COMPOSE_FILE del padre) es mi solución, pero mi vida será mucho más fácil cuando tengamos una solución para este problema.

@vipseixas es difícil evaluar la cordura de esta solución a partir de una lista de archivos, aunque sí, estoy de acuerdo en tener la capacidad de no iniciar automáticamente un servicio. Solo estoy sugiriendo que use un punto de entrada / comando predeterminado que no hace nada para los servicios que prefiere _no_ que se inicien automáticamente. Por ejemplo, el contenedor simplemente sale por defecto ... y para ejecutar esos servicios con un comando alternativo a través de la ejecución posterior de docker-compose.

En la mayoría de los casos, querrá asegurarse de que las verificaciones de estado pasen en los servicios / contenedores dependientes antes de ejecutar las pruebas; por ejemplo, jenkins está activo y ejecutándose (aceptando conexiones en: 8080 o lo que sea) antes de que se ejecuten estas pruebas. En el pasado usé dockerize para esto.

Si tuviera que proponer una solución milagrosa, sería permitir la configuración de un perfil de redacción a través de variables ambientales (por ejemplo, DOCKER_COMPOSE_PROFILE = "pruebas"), y permitir que los servicios dependan de un perfil, donde todos los servicios están predeterminados por defecto "perfil o lo que sea. También me aseguraría de que los servicios que dependen de otro servicio también sean _dependientes_ del HEALTHCHECK de esos servicios. Entonces algo como

app:
  image: myapp:v1

tests:
  image: myapp:tests
  dependencies:
    - profile: "tests"
    - service: "app"
      healthcheck: true

# run the things
docker-compose up -d

# test the things
DOCKER_COMPOSE_PROFILE="tests" docker-compose up -d
DOCKER_COMPOSE_PROFILE="tests" docker-compose logs -f

+1 para la opción 2.

Muchos aquí han propuesto nuevas características interesantes, pero ¿cuál es el núcleo del problema aquí? Voto por mantenerlo lo más simple posible.

Tal como está hoy, asumimos que todos los servicios en nuestro docker-compose.yml aparecerán en docker-compose up . Todos estamos trabajando con nuestros propios scripts de arranque personalizados, archivos MAKE, herramientas de compilación, etc., y afortunadamente tanto docker-compose como docker exponen una API extensa para la gestión de contenedores individuales una vez que el fregadero de la cocina está "activo".

Mi única necesidad, la necesidad central que me trajo a esta discusión, es especificar que uno de esos servicios que he definido no es algo que quiero 'activo' de forma predeterminada, por la razón que sea.

¿Cuál es la característica más simple posible que "lo hace" para todos nosotros? Es una pequeña actualización de la especificación docker-compose.yml ( @bfirsh idea original no. 2) en la que un servicio puede especificar autostart: false

Voto por: "SOLO HAZ ALGO POR NOSOTROS, GRACIAS". Votamos, ahora necesitamos al menos una respuesta. 4 ¡DIOS!

¿Cuál es la característica más simple posible que "lo hace" para todos nosotros? Es una pequeña actualización de la especificación docker-compose.yml ( @bfirsh idea original no. 2) en la que un servicio puede especificar autostart: false

Eso es mucho mejor que cualquier otra alternativa :)

Es tan simple.
scale: 0
https://github.com/docker/compose/issues/1661

@ drew-r ¿qué?

@ jonathanborges1542 Es docker-compose scale servname=2 . No hay equivalente en el archivo docker-compose.yml .

@ drew-r scale: 0 actualmente le dice al demonio docker que envíe SIGTERM / SIGKILL a todos los contenedores para el servicio. Esto acabaría con cualquier trabajo de mantenimiento incluso si aún no ha completado su trabajo. Ese es el comportamiento esperado. Cambiar esto sería un mal caso de sobrecarga de lo que es un comportamiento claro en este momento.

@gittycat Entiendo, pero lo que queremos aquí es escribir "docker-compose up" y todo estará listo. Entonces, en ese caso, no funcionaría.

He estado siguiendo este tema durante más de un año (la mayoría de las publicaciones están en el lado de la ventana acoplable).
Creo que la mejor opción es un nuevo "trabajo" de alto nivel que conviva con "servicios", "volúmenes" y "redes". Esa es la opción 4 en la lista OP anterior.
También es una propuesta en el repositorio de Docker.
https://github.com/docker/docker/issues/23880

@briceburg

es difícil medir la cordura de esta solución a partir de una lista de archivos

La intención era simplemente mostrar que tengo muchas combinaciones de archivos y que el uso de múltiples opciones "-f" es demasiado propenso a errores como para hacerlo manualmente.

Solo estoy sugiriendo que use un punto de entrada / comando predeterminado que no hace nada para los servicios que prefiere que no se inicien automáticamente.

A veces no hay escapatoria de la perdición. Pero prefiero mi solución: uso un directorio diferente que nunca será "compuesto" para que no haya contenedores inútiles detenidos que contaminen mi entorno. Es por eso que tengo un directorio de trabajo con un ".env" vinculado al padre ".env".

Si tuviera que proponer una fórmula mágica, sería permitir establecer un perfil de redacción a través de variables ambientales (por ejemplo, DOCKER_COMPOSE_PROFILE = "tests")

ESA sería la mejor solución. Pero no creo que los desarrolladores estén inclinados a aumentar la complejidad ...

Quiero construir una imagen base, "extender" esto en el mismo docker-compose.yml e iniciar solo la segunda imagen, que no es factible en un solo paso por el momento. Con la opción 2 lo será, pero quizás la forma mejor y más limpia es tener una "etapa de construcción" y una "etapa de ejecución", donde se realiza la creación de imágenes base. Por el momento tengo que ejecutar 2 comandos y no solo uno.

+1 @ drew-r # 1661

¿Se va a implementar este problema en algún momento o es algo que los desarrolladores de redacción no quieren hacer? Sería bueno saberlo para que la comunidad pueda comenzar a buscar otra solución.

Por cierto, voto por la opción 2.

Gracias

+1 para la opción 2.
¿Respetaría las dependencias explícitas aunque ... links etc.?

Si estoy especificando qué servicio mostrar con docker-compose up [service] , es raro que quiera iniciar otros servicios que no sean el servicio en cuestión y sus dependencias.

Otro voto para la opción 2. Incluso hay un PR (https://github.com/docker/compose/pull/3047) que @acran tuvo la amabilidad de crear, por lo que el esfuerzo de los desarrolladores de redacción debería ser bastante pequeño, ya que solo necesitan revisarlo (y es bastante corto y simple) y no escribir ningún código.

Si los desarrolladores de redacción no quieren hacer esto, deberían indicarlo de una vez por todas y luego cerrar el ticket y bloquearlo para evitar comentarios.

@msabramo compose está básicamente limitado por lo que se decide en el nivel del motor de la ventana acoplable.

La solicitud se rastrea en el repositorio del motor de Docker https://github.com/docker/docker/issues/23880
De ahí vendrá la decisión / el trabajo.

Sugiero que se cierre este tema.

@gittycat compose todavía puede tener la opción de decirle al motor que inicie un servicio o no. Esta es una solicitud muy válida todavía.

Renuncio a Docker en producción, hay muchos problemas. Luego migro a vagabundo.

Otro voto por 2)

Otro voto por 2 y 4.

Solo para señalar un caso de uso, algunos servicios tienen dependencias circulares, la necesidad de generar archivos de configuración, ejecutar suites de prueba, entre muchas otras posibilidades. Podemos desacoplarlo de Docker o usar otras herramientas, pero agrega una complejidad innecesaria a la configuración del proyecto.

Tener un comando simple para la configuración y / o las pruebas haría las cosas mucho más limpias.

¡Otro voto por 2!

Había leído este hilo pero decidí crear una nueva publicación (https://github.com/docker/compose/issues/4650), que se cerró y me remitieron aquí. el punto que quería señalar es que, si bien la mayor parte de la discusión en este hilo se refiere a las banderas para deshabilitar la ejecución de contenedores, mi caso de uso es de un tercer estado: crear contenedores.

Me gustaría no solo evitar que se ejecute un contenedor, sino también poder nunca crear el contenedor en primer lugar (en mi caso de uso, tengo un proceso impulsado por el usuario que logra esto)

@ekkis Tengo curiosidad por saber cómo llegó a ser eso. Mi caso de uso implica hacer referencia a la imagen del contenedor principal y configurar "acciones" alternativas, se podría hacer usando algo como bash pero tiene más sentido usar Docker.

¿Sería tan amable de darnos más detalles sobre su problema?

@frnco , no estoy seguro de entender sobre qué le gustaría obtener más detalles. hay casos en los que desea construir una imagen sin necesidad de crear contenedores. el mío es uno de esos casos. Quiero una imagen dada construida junto con un montón de otras imágenes, pero esta en particular será utilizada por un proceso que he escrito. No quiero tener dos procesos separados para construir y tener una bandera para build-only podría resolver ese problema

@ekkis Te sugiero que

+1 para la opción 2

+1 para la opción 2

+1 para la opción 2

+1 para la opción 2

+1 para la opción 2

+1 para la opción 2

: +1: para la opción n. ° 2 con una pregunta sobre cualquier estimación de esta función? ¿Cuál es la mejor solución? Por lo que puedo imaginar, necesito enumerar todos mis servicios como:

docker-compose up service1 service2 service3

... y omito los que no quiero empezar por defecto

¿Hay alguna forma en que nosotros, en la comunidad de código abierto, podamos ayudar a contribuir con esta función que parece muy solicitada?

+1 para la opción 2.
Una forma de especificar 'etapa' sería genial. Digamos que el servicio se ejecutará solo en producción.

+1 para la opción 2.

Vote por la opción 2

up filtrado de comandos será perfecto - docker-compose up service1 service3

: +1: para las opciones 2 y 4

En este punto, parece evidente que la opción 2 es lo que quieren los usuarios. ¿Cuáles son los próximos pasos para que esto suceda?

Aquí para hacer +1 para la opción 2, encontré este problema con la esperanza de que esta funcionalidad ya existiera.

+1 en la opción 2

... y uno más +1 para la opción 2

+1 para la opción 2

+1 para la opción 2 :-)

+1 para las opciones 2 y 4

Hola a todos,
+1 opción 2

En mi humilde opinión, la opción será muy útil en entornos locales, cuando tenga una aplicación basada en microservicios o con arquitectura hexagonal; como desarrollador puedo ejecutar solo los elementos necesarios para mi trabajo más cercano;

La opción 2 es la que desean la mayoría de los usuarios. ¿Aún no se ha tomado una decisión con respecto a esto o el desarrollo de esto ha comenzado y se está rastreando en otro lugar?

Creo que cuando termine la universidad en un par de meses y tenga más tiempo, será mucho más rápido implementar esta función por mí mismo (aunque no he aprendido Python, en el que creo que redactar está escrito), pero vi que gran cantidad de votos y solicitudes, durante dos años, sin ningún paso adelante, y la autoimplementación parece ser la solución para los próximos 5 años (hasta que esa característica se implemente oficialmente).

por supuesto +1000 para la opción 2

+1 opción 2

¿Haría alguna diferencia si yo votara por la opción 2? 'parece poco probable que lo haga.

Los comentarios aquí se han vuelto mordaces últimamente, y no han aparecido realmente nuevos comentarios, lo que me hace considerar bloquear este hilo. Sea cortés cuando interactúe aquí.

Esta es la posición oficial actual del equipo de mantenedores en este asunto. Si bien aún se está considerando si queremos agregar esta función, o una similar, como una opción de conveniencia, no es una prioridad por las razones resaltadas y porque existen otras herramientas que son más adecuadas para ella.

@ shin- Antes de bloquear esto, ¿puedo aclarar si la comunidad está dispuesta al desarrollo? ¿El equipo central lo fusionará si cumple con los estándares del equipo? En los hilos hay una implementación y un miembro de la comunidad dispuesto a completarlo, solo buscaban alguna confirmación de que no sería un desperdicio de su inversión. Si podemos obtener algunos comentarios, rastrearé esos hilos para moverlos y ver si podemos mover esto al cierre.

@jimzucker No, porque el problema aquí no es la implementación; una implementación básica de esto tomaría medio día para un desarrollador promedio. Lo que nos preocupa aquí es un problema de diseño fundamental.

1. ¿Qué es un servicio? Por diseño, un servicio es un proceso de larga duración claramente definido que interactúa con otros servicios para formar una aplicación. Esa es la suposición básica bajo la que opera Compose y guía nuestro diseño para la mayoría, si no todas, las características que implementamos.
2. Según esa definición, un "servicio que no se inicia de forma predeterminada" no es realmente un servicio [1]; es más una tarea predefinida, que se ejecuta en un contenedor y actúa sobre la aplicación, en lugar de ser parte de ella.
3. Por tanto, es incorrecto (fundamentalmente por diseño) llamarlo servicio. En ese momento, debemos considerar la posibilidad de crear un nuevo tipo de definición en su archivo Compose (lo llamaré "tarea" para abreviar, la terminología exacta no importa aquí).
4. Dado que las tareas son procesos de ejecución inherentemente cortos, utilizan un conjunto de opciones diferente en comparación con los servicios. Por ejemplo, podemos intuir que las tareas no necesitan exponer puertos [2]. Por otro lado, una opción como el archivo CID, que en su mayoría no tiene sentido para los servicios, podría ser realmente útil para las tareas.
5. Ahora, en la mayoría de los proyectos, las tareas tienden a tener cadenas de dependencia (es por eso que en el mundo tradicional, sin contenedores, tenemos Makefiles), por lo que necesitamos tener al menos una implementación básica de cadenas de dependencia, con paralelismo, y poder decir si esa tarea de compilación JAR que siempre toma 10 minutos realmente necesita ejecutarse nuevamente.
6. Luego, algunos servicios realmente dependen de que las tareas se hayan ejecutado antes de poder comenzar, lo que agrega otro nivel de complejidad a la forma en que calculamos y manejamos las dependencias.
7. Y algunas tareas necesitan que algunos servicios estén activos para ejecutarse (por ejemplo, migración de la base de datos).

En este punto, esto se ha convertido en una pieza de código completamente nueva que probablemente iguale o supere cmake en términos de alcance y complejidad. Es por eso que nos hemos resistido a implementar esto durante tanto tiempo, en parte porque no es en absoluto para lo que está diseñado Compose, sino también porque [3] simplemente no tenemos el tiempo o los recursos para implementar o mantener lo que esta función tendría que volverse realmente útil para las personas.

Ojalá esto aclare un poco más las cosas. Sé que la gente ha estado molesta y decepcionada con la respuesta (o la falta de ella) en este hilo, y no estoy seguro de que esto lo alivie de alguna manera, pero ahí está.

[1] Algunas personas mencionan querer tener "servicios opcionales", pero ese no es el caso de uso más común mencionado en este hilo. La mayoría de la gente quiere la función de "tarea", hasta donde yo sé.
[2] Estoy seguro de que alguien me contradirá con un ejemplo de una tarea que necesita exponer puertos, que solo servirá para demostrar que el ejercicio de decidir qué opciones son aplicables a cada conjunto no es trivial.
[3] Y en este punto me refiero a "yo", ya que soy el único mantenedor que trabaja activamente en docker-compose en este momento.

@ shin- Veo el punto. Lo que estoy persiguiendo son "servicios opcionales" en sus notas al pie y los casos de uso para eso, no la idea de tareas, ¿podemos de alguna manera estar de acuerdo en cómo podemos progresar en ese punto, ya que esa era la parte del hilo que estoy tratando de defender y Mis boletos claramente en ese camino se cerraron a favor de este hilo. Si podemos separar eso de los puntos que ha definido claramente como "tareas", podemos avanzar un poco. Cuando la gente hace un +1 para la opción 2 en mi lectura, es para el servicio opcional. Feliz de desconectar esto para discutir y luego podemos volver al foro, estoy en [email protected]

@ shin- tu punto # 2 está mal. un servicio es un servicio independientemente de si se está ejecutando. Hay innumerables casos de uso en los que los servicios dependientes modificarán el comportamiento cuando la dependencia no está disponible, por lo que su capa de aplicación no puede, no debe, requerir que todos los "servicios" estén disponibles en todo momento.

si lo piensa en los términos más tradicionales, considere que un servidor web es un "servicio" pero puede cerrarse o configurarse para que no se inicie de forma predeterminada en un host determinado, pero nadie lo consideraría otra cosa que un servicio

Creo que muchas personas que solicitan esta función no quieren ejecutar tareas sino servicios opcionales. Por ejemplo, si tiene un conjunto de microservicios ejecutándose como contenedores Docker y los implementa todos como un servicio completo, tal vez algún día sus requisitos cambien y no necesite ejecutar todos los contenedores en todos sus servidores porque para ese caso usted no necesita una funcionalidad específica que se incluye en un contenedor no obligatorio.

Además, creo que esta es una buena característica para el entorno de desarrollo; Si está solucionando un error en un contenedor específico, no es necesario que inicie todos los contenedores.

Exactamente, con un campo booleano simple podríamos habilitar / deshabilitar fácilmente los servicios del archivo .env y evitar editar el archivo yaml.

@ekkis Creo que estás confundiendo un poco la tolerancia a fallas y la dispensabilidad. Además, vea mi nota al pie sobre el tema, donde reconozco que existen algunos casos de uso.

Todos: tenga en cuenta que si algunos servicios son opcionales para su aplicación, ya es posible manejar esto con las funciones actuales. La forma recomendada de hacerlo es tener un archivo Redactar separado que se pueda incluir o excluir usando la marca -f . No son un argumento muy convincente para agregar esta opción.

@ shin- Agradezco que se haya tomado el tiempo de tener este diálogo con nosotros. Estoy de acuerdo en que hay varias formas de hacerlo, ya que sugiere varios archivos yml, también puede pasar una lista de servicios, pero estos no son convenientes y conducen a errores de usuario que crean riesgo operativo. Especialmente en el caso de un producto comercial, queremos distribuir un archivo de redacción y, de forma predeterminada, obtener el comportamiento común deseado y dar instrucciones para las opciones avanzadas, un archivo hace que todo esto sea mucho más ordenado tanto para el desarrollo, como para CI / CD y la distribución. La adición de variables ENV con valores predeterminados fue de gran ayuda para nosotros y ha eliminado la necesidad de tener muchos archivos yml, este será un paso más hacia la administración de un solo archivo que describe la implementación.

¿Existe alguna forma en que el equipo central estaría dispuesto a aceptar una contribución en este LMK?

@shin , no hice ninguna referencia ni a la tolerancia a fallas ni a la dispensabilidad. Simplemente hice un comentario sobre la definición de "servicio", es decir, que si el servicio se ejecuta o no no es inherente a la definición

@ shin- Estoy totalmente de acuerdo con @ekkis : no iniciarse

Por ejemplo: cuando desarrollo una aplicación usando una base de datos mysql, normalmente defino un _service_ adicional phpmyadmin . Este es un verdadero servicio: puertos expuestos de larga ejecución, dependientes de otros servicios.
Pero no quiero iniciar este servicio _por defecto_ sino solo _a pedido_ / en desarrollo.
Actualmente me doy cuenta de esto al poner este servicio en docker-compose.yml adicionales e iniciarlo proporcionando ambos archivos a docker-compose , tal como sugirió anteriormente.

Entonces, sí, ya hay formas posibles de lograrlo; ya sea dividiendo los servicios en varios archivos o simplemente usando una herramienta que no sea docker-compose . Pero como ya escribí anteriormente : este problema no se trata de una característica / funcionalidad completamente nueva o un nuevo concepto (es decir, _tareas_) sino de conveniencia , especialmente en entornos de desarrollo .
Tener que escribir docker-compose -f docker-compose.yml -f docker-compose-tools.yml up es cualquier cosa menos conveniente y, por lo tanto, docker-compose no cumple sus propias promesas :

Juntas, estas características brindan una manera conveniente para que los desarrolladores comiencen a trabajar en un proyecto. Compose puede reducir una “guía de introducción para desarrolladores” de varias páginas a un solo archivo Compose legible por máquina y unos pocos comandos.

Qué servicios iniciar o qué archivos yml usar en qué entorno es algo que normalmente se encuentra en _multi-page "Developer Getting Start Guide [s]" _ - si es que se encuentra ...

Entonces, en mi opinión y como escribió @jimzucker, la mayoría de los +1 aquí son realmente para "servicios opcionales" en lugar de un nuevo concepto de tareas. Al menos todos ellos están mejor con un booleano simple para marcar un _servicio_ para que se inicie por defecto o no.

Como muestra mi PoC , el cambio de código requerido - para "servicios opcionales" - es bastante manejable y proporciona a la mayoría de las personas aquí un gran beneficio en cuanto a comodidad. La opción 2, que se lee como "_posibilidad de marcar un servicio como opcional_", es un compromiso razonable para resolver este problema.

@ shin- ¿no estaría de acuerdo en que brindarles a los usuarios la posibilidad de marcar servicios como opcionales, pero que siguen siendo servicios, les ayudaría mucho?
Cuando se reduce a "marcar _servicios_ como opcional / no iniciado de forma predeterminada", ¿este problema / una solicitud de extracción para esto se aceptará y combinará?

@shin , para agregar al punto anterior de @acran , es posible que desee que docker-compose solo compile ciertos servicios porque esos servicios serán ejecutados por otros servicios usando nombres . considere que cada vez que hago "up" obtengo un montón de "servicios" llamados project_app_1 , project_otherapp_1 , etc. estos no tienen sentido ya que necesitan ser ejecutados usando información en una base de datos (tengo un servicio maestro que los inicia) . así que siempre tengo que ir a matarlos. así que para mí una bandera NO_RUN o BUILD_ONLY tiene mucho sentido. esto seria conveniente

@acran

¿No estaría de acuerdo en que brindarles a los usuarios la posibilidad de marcar servicios como opcionales, pero que siguen siendo servicios, los ayudaría mucho?

No estoy de acuerdo en cuánto ayudaría; creo que "mucho" está exagerado. En su ejemplo, simplemente tener un docker-compose.phpmyadmin.yml que se puede incluir opcionalmente no es más oneroso o complejo (en términos de instrucciones "guías para desarrolladores") que establecer una variable de entorno / modificar una definición de servicio dentro del archivo principal.
También estoy considerando la compensación de darles a los desarrolladores "pistolas" cuando no es estrictamente necesario hacerlo.

Cuando se reduzca a "marcar servicios como opcionales / no iniciados de forma predeterminada", ¿se aceptará y combinará este problema / una solicitud de extracción para esto?

Consulte más arriba: tan pronto como esta función esté disponible, las personas comenzarán a usarla para otros fines distintos a los previstos y esperan que implementemos un nuevo conjunto de funciones para admitirla. También cc @jimzucker ; Actualmente no puedo pensar en una implementación que evite que se desarrolle este escenario. Si pudiera, este problema se habría resuelto hace mucho tiempo.

@ekkis Si nunca desea iniciar esos servicios usted mismo, ¿por qué exactamente es un problema tenerlos aislados en un archivo separado? Estoy realmente confundido en cuanto a por qué esto es tan complicado aquí.

@shin si se puede usar un docker-compose.yml para construir un servicio, es una herramienta muy útil para centralizar mi proceso de construcción. De hecho, tiene mucho sentido que quiera construir (condicionalmente) un servicio antes de ejecutarlo, y aplaudo esa funcionalidad.

por lo que el archivo docker-compose también es mi archivo MAKE . pero el hecho de que construya algo no significa que quiera ejecutarlo. No tiene sentido que docker-compose suponga que quiero ejecutar un servicio, inventar un nombre para él y ejecutarlo sin los parámetros adecuados / variables de entorno / etc.

francamente, no estoy seguro de entender cuál es la objeción a este sencillo parche. me seria de gran utilidad

En mi publicación anterior señalé claramente por qué la posición oficial del equipo era que no debería usar su archivo Compose como un Makefile. Si cree que estamos equivocados en esto y aún desea hacerlo, es su prerrogativa, pero es un poco absurdo insistir en que agreguemos funciones para respaldarlo.

@espinilla-

En su ejemplo, solo tener un docker-compose.phpmyadmin.yml que se puede incluir opcionalmente no es más oneroso o complejo (en términos de instrucciones "guías para desarrolladores") que establecer una variable de entorno / modificar una definición de servicio dentro del archivo principal.

En realidad, todavía no pensé en involucrar variables de entorno aquí. Mi flujo de trabajo deseado "servicios opcionales" finalmente permitiría es el siguiente:

• Copio / clono un nuevo proyecto
• Veo que hay un (único) archivo docker-compose.yml en él, por lo tanto, lo sé, todo lo que tengo que hacer es ejecutar docker-compose up y la aplicación está construida y ejecutada
• Ahora quiero iniciar uno de los servicios opcionales con fines de desarrollo (por ejemplo, depuración adicional, phpMyAdmin). Todo lo que tengo que hacer es docker-compose up phpmyadmin .

Para mí, esto es _mucho_ más conveniente que usar varios archivos docker-compose.yml y, como tengo entendido, para la mayoría de las personas de aquí también. El beneficio de tener "servicios opcionales" aquí es

• para que el desarrollador no tenga que duplicar nada entre varios archivos o tenga que considerar cuidadosamente qué definiciones poner en qué archivo, pero solo tener que establecer una bandera booleana ( auto_up: false ) en un servicio
• para que el usuario no tenga que saber / recordar qué archivos incluir para qué servicios: ¿necesito ejecutar
  
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml up
  
  
  • docker-compose -f docker-compose.yml -f docker-compose.phpmyadmin.yml up o incluso
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml -f docker-compose.yml up ?
  
  
• en cambio, lo único que el usuario necesita _saber_ es que existe un servicio llamado phpmyadmin y el usuario sabe inmediatamente cómo iniciarlo.

Consulte más arriba: tan pronto como esta función esté disponible, las personas comenzarán a usarla para otros fines distintos a los previstos y esperarán que implementemos un nuevo conjunto de funciones para respaldarla.

No me malinterpreten, no solo entiendo su preocupación aquí, sino que estoy de acuerdo con ella: siempre habrá usuarios que modifiquen esta, o cualquier otra (!), Característica para adaptarse a sus flujos de trabajo deseados, aunque las características nunca fueron diseñadas para ser usado así.
PERO para cualquier solicitud sobre "servicios opcionales" que falten características de una "tarea", puede _entonces_ fácilmente argumentar que los servicios no son tareas y que las tareas deben presentarse primero como un nuevo concepto y, por lo tanto, no son compatibles (todavía). Es decir, cualquier cosa más que marcar un servicio como opcional es un paso hacia el concepto de tareas (por ejemplo, la opción 4) y hay un claro corte entre ellos.

Con la característica de marcar un _servicio_ como opcional, todavía estamos en el lado derecho de ese corte. "La función en sí no es demasiado compleja de implementar, pero _podría_ tentar a los usuarios a usarla incorrectamente" siendo actualmente el único argumento real (¡aunque válido!) Que se opone a esta función es bastante insatisfactorio como razón para no implementarla, al menos para los usuarios que podrían obtener mucha comodidad mientras lo usaban de la manera correcta ™.

Estoy a la altura de reajustar mi solicitud de extracción # 3047 al maestro actual y hacer cualquier pulido necesario para que esto sea aceptado, por favor hágamelo saber;)

Mi caso de uso es que no enviamos todas nuestras imágenes al puerto o al muelle de la ventana acoplable, ni tenemos nuestro propio registro, y poder marcar un servicio como no ejecutado por defecto significa que podemos tener una imagen base definida en docker-compose.yml que no se inicia, y luego otros contenedores usándola o basándose en ella.

Me inclinaría a usar una bifurcación docker-compose que implemente esta característica solo para esta característica singular.

@ shin- Aunque creo que todos entendemos su punto y simpatizamos con él, no creo que "podría ser mal utilizado" sea un buen argumento para algo con, claramente, muchos casos de uso viables. Por supuesto, será mal utilizado. Así es exactamente como crecen el software y las nuevas ideas; de utilizar la tecnología no del todo como debería ser. La web no sería lo que es hoy si no hubiéramos estado haciendo un mal uso de toda la tecnología proporcionada durante los últimos 25 años.

De todas formas.
Según usted, simplificado, la diferencia entre un servicio y una tarea es el tiempo de vida. Tiene sentido, y entiendo que los ve como dos conceptos diferentes y siente que es una lata potencial de gusanos. Pero esta distinción no se aclara ni se explica en ninguna parte de la documentación. Tampoco se señala en ninguna parte que la ventana acoplable no esté destinada a ser utilizada para activar procesos temporales.
Lo que quiero decir es que si el equipo de Docker tiene una postura firme sobre esto, debería quedar claro desde el principio.
También. Tarea o servicio, claramente hay una superposición. Y marcar un servicio como opcional definitivamente no es algo que pertenezca exclusivamente al lado de la tarea.
Desde un punto de vista práctico, definitivamente estoy de acuerdo con @acran : tener un solo archivo docker-compose es mucho mejor DX, simplifica mucho y es menos propenso a errores que tener varios archivos docker-compose.

Jeje, recuerdo las discusiones feroces que teníamos cuando presionamos para conseguir lo que permite "navegadores" a las imágenes de exhibición, con el argumento principal de los oponentes que son que se llama protocolo de transferencia de hipertexto.
Perdón por los recuerdos OT de un viejo pedo.

@ shin- si el docker-compose no debe usarse como un archivo MAKE, entonces no debe proporcionar la funcionalidad de archivo MAKE. si me permite construir mis proyectos (¡bravo!) Entonces tomar la posición de que no es un archivo MAKE es ridículo

@ shin- mira, ustedes no tienen que implementar ninguna característica que no quieran, no importa cuán irracionales sean sus razones o cuán útil sea la característica. es solo que hace que la herramienta sea menos útil para aquellos de nosotros que la usamos. somos los usuarios, conocemos los casos de uso, y las herramientas son tan útiles y valiosas como se adaptan a los casos de uso

esto para mí es solo una pequeña irritación, tengo que matar manualmente un montón de cosas que se generan sin una buena razón _ cada vez que subo mis servicios_. para otros puede ser un impedimento, la irritación variará en severidad

Entiendo que la posición oficial es que deberíamos usar dobi, incluso si es excesivo para lo que necesitamos. pero esa posición oficial no explica la base de su renuencia a aceptar un RP útil. todavía podemos usar dobi cuando la demanda de docker-compose es demasiado grande o la superposición es suficiente para migrar, pero este es un cambio muy pequeño que haría que todas nuestras vidas fueran mucho mejores

y dicho sea de paso, no estoy siendo "mordaz", pero cerrar el hilo para evitar más discusiones sería simplemente antidemocrático y autoritario. El código abierto se basa en el principio de apertura y me entristecería ver que este proyecto se gestiona con censura y tácticas dictatoriales.

@rysiekpl Este es un problema que estamos buscando resolver de una manera diferente, consulte https://github.com/docker/cli/pull/452 (una vez que se delibera la sintaxis, se abrirá camino en Compose y v2 como bien)

@creynders Creo que es una caracterización un poco errónea: nadie está diciendo que los servicios opcionales no deberían existir (y de hecho, como señalé, hay formas de declararlos usando archivos separados). Esto es más parecido a debatir si no cerrar explícitamente una etiqueta <img> es válido y si nuestro navegador específico debería admitirlo o no.

Además, a tu punto:

Pero esta distinción no se aclara ni se explica en ninguna parte de la documentación. Tampoco se señala en ninguna parte que la ventana acoplable no esté destinada a ser utilizada para activar procesos temporales.

Este es en realidad el primer párrafo de la página https://docs.docker.com/compose/overview/ (el énfasis es mío):

Compose es una herramienta para definir y ejecutar aplicaciones Docker de varios contenedores. Con Compose, usa un archivo Compose para configurar los servicios de su aplicación. Luego, con un solo comando, crea e inicia todos los servicios desde su configuración.

@ekkis ¡Estoy muy contento de que Compose sea útil para sus proyectos! Espero no parecer poco sincero en todo esto, está absolutamente bien si esa es la forma en que desea utilizar el software. Lo que estoy diciendo, sin embargo, es que llevarlo más lejos en esa dirección probablemente lo empeoraría a largo plazo. Todos sabemos lo que les sucede a las aplicaciones que intentan hacer demasiadas cosas (aunque supongo que Emacs lo logró: stick_out_tongue :)

No creo que estuviera siendo "autoritario", pero tal vez no me expresé correctamente. Mi intención era animar a la gente a que se mantuviera civilizada y positiva en sus interacciones. El hilo todavía está desbloqueado y seguirá estando mientras la gente se abstenga de ser mala o descortés.

creas e inicias todos los servicios desde tu configuración.

y supongo que nuestro argumento es que debería haber leído "crear y / o comenzar", aunque para ser justos con el lenguaje uno no necesita indicar el OR porque está implícito en el AND. en otras palabras, es cierto que puede crear e iniciar un servicio, pero no implica que deba hacer ambas cosas

Todos sabemos lo que sucede con las aplicaciones que intentan hacer demasiadas cosas.

sí, puedo apreciar que está administrando las fronteras del dominio

No creo que estuviera siendo "autoritario"

Amo el movimiento de código abierto. podemos tener nuestros desacuerdos, pero todavía estamos juntos en esto. las guerras dentro de la comunidad bitcoin fueron espantosas y creo que todavía me estoy recuperando de eso, así que gracias por permanecer del lado de la civilidad

Como pensamiento de despedida, le pediría que vuelva a revisar https://github.com/docker/compose/issues/4650 que no es lo mismo que la solicitud en este hilo (como indicó al cerrarlo) pero se adapta a mi uso caso, es decir, que la bandera que se discute aquí no es binaria sino trinaria

Me gusta mucho la idea de definir varios archivos. Sin embargo, incluir todos los archivos con varios -f incluido el original, parece ser una exageración total.

En realidad, hay una forma más práctica, que funciona para mí (ver PS a continuación): ponga todo el servicio que no desea ejecutar en docker-compose.override.yml . Y use docker compose -f docker-compose.yml up para el inicio normal (tenga en cuenta que este es un comando de una sola vez). En todas las llamadas consecutivas se procederá a la anulación ...

En general, todo esto es muy poco intuitivo y un poco insatisfactorio. Añadiendo un adicional:

• una opción para deshabilitar servicios tiene sentido especialmente para anulaciones más complejas

• La opción -f es mínima pero no muy intuitiva, otra opción -F <name> que solo agrega anulaciones adicionales sería muy acogedora (es decir, docker-compose..yml. Una alternativa sería usarcomo un directorio en el que se obtienen todos los archivos .yml : junto con los enlaces simbólicos, esto sería igualmente poderoso como /etc/apache/sites.available -> /etc/apache/sites.enabled

Por otro lado: cualquiera podría proporcionar un script de envoltura simpe (función) para que su shell emule este comportamiento ...

PD: mi caso de uso es que defino un depurador como un servicio. Obviamente, este servicio no es necesario todo el tiempo, pero necesita que los enlaces (también por razones de seguridad) funcionen correctamente.

Otro caso de uso para el que la Opción 2 es excelente:

Digamos que tienes un equipo de personas trabajando en el mismo proyecto. Algunos de ellos tienen acceso a los servicios administrados de AWS, pero algunos de ellos necesitan ejecutar los recursos correspondientes como contenedores locales. Entonces, dependiendo de mi flujo de trabajo, _siempre_ o _nunca_ necesitaré contenedores Redis y MySQL en mi constelación de composición.

Voy a decir rotundamente que administrar varios archivos de redacción es una estupidez para este caso de uso. La cantidad de superposición es cómica. Mantener varios archivos es un arma de fuego: ellos _no_ se desincronizarán y causarán confusión. Francamente, estoy un poco sorprendido de que alguien se haya tomado esa opción en serio para cualquier caso de uso.

Ser capaz de habilitar y deshabilitar servicios rápidamente, sin comentar grandes bloques de configuración (incómodo en YAML, muy complicado si se confirma accidentalmente), es genial por sí solo. Pero si componer algún día tiene la capacidad de interpolar variables en la configuración, esta característica automáticamente se vuelve exponencialmente más poderosa. Hasta entonces, es muy útil.

Totalmente de acuerdo con @campadrenalin.

Toda esta discusión, según tengo entendido, es básicamente una gran cantidad de personas que brindan una gran cantidad de muy buenas razones para implementar la Opción 2, y los desarrolladores se niegan porque, hipotéticamente, alguien podría malinterpretar la existencia de esta característica y solicitar algunas otras características no relacionadas .

ANTIGUO TESTAMENTO:

Pero si componer algún día tiene la capacidad de interpolar variables en la configuración, esta característica automáticamente se vuelve exponencialmente más poderosa.

¿No ha estado disponible esta función durante mucho tiempo? Consulte https://docs.docker.com/compose/compose-file/#variable -substitution. Lo estoy usando para permitir la personalización de nuestro entorno de desarrollo de Compose usando el archivo .env , por ejemplo, ubicación del código fuente, mapeo de puertos, etc. Desde la versión 2.1 del archivo de composición, incluso la variable de estilo shell predeterminada ( ${VARIABLE:-default} / ${VARIABLE-default ) es compatible.

Toda esta discusión, según tengo entendido, es básicamente una gran cantidad de personas que brindan una gran cantidad de muy buenas razones para implementar la Opción 2, y los desarrolladores se niegan porque, hipotéticamente, alguien podría malinterpretar la existencia de esta característica y solicitar algunas otras características no relacionadas .

Encuentro que esto es, tal vez un poco duro en tono, pero válido en esencia, un muy buen resumen de @rysiekpl.
Entonces, @ shin-, ¿nos acercamos más a una decisión con respecto a este tema? ¿Ya sea para cerrarlo o para implementar / aceptar un RP para la opción 2?

Veo y entiendo totalmente sus preocupaciones, pero también veo que las ventajas superan el riesgo de que alguien pueda abusar de esto, ya que es un cambio bastante pequeño pero ofrece a mucha gente muchas más posibilidades para flujos de trabajo mucho más _convenientes_.

Como docker-compose parece caer a largo plazo a favor de la pila de docker de todos modos, sugiero que todos se pasen al nuevo formato v3 y la herramienta docker stack lo antes posible.

Usando una pila en un enjambre (incluso en 1 nodo), puede especificar esto:

        deploy:
            mode: replicated
            replicas: 0

Tener cero réplicas esencialmente deshabilita la ejecución del servicio.

Solo necesitará alguna otra herramienta para generar ese yml si desea aplicar sustituciones de variables de entorno, como envsubst.

Luego puede usar un marcador de posición en su yml:

        deploy:
            mode: replicated
            replicas: ${R}

Y procesarlo de esta manera:

export R=0
docker stack deploy stack1 --compose-file=<(envsubst <docker-compose.yml) 

Entonces, si docker-compose va a quedar obsoleto a largo plazo, ¿cuál es exactamente el problema de fusionar la solicitud de extracción que ya está disponible ? Quiero decir, si docker-compose sigue el camino del dodo, ¿cómo es que "alguien solicitará características extrañas" es un problema real?

Como docker-compose parece descartarse a largo plazo a favor de la pila de docker

Entonces, si docker-compose va a quedar obsoleto a largo plazo

¿espera qué? docker-compose es fundamental para muchas personas para su flujo de trabajo de desarrollo, que apenas necesita un administrador de enjambres. ¿Podría señalarme alguna declaración oficial de Docker al respecto?

Puede que esté leyendo esto mal, pero parece que el enjambre de la ventana acoplable y la pila de la ventana acoplable están estrechamente relacionados con los servicios en la nube de la ventana acoplable. ¿Son estos elementos configurables en un sistema autónomo fuera de línea?

¿Se pueden configurar estas cosas en un sistema autónomo fuera de línea?

sí, puedes usarlos sin conexión.

Para mí, parece que las pilas en docker-swarm eventualmente serán un superconjunto de las características de docker-compose. Creo que los archivos descriptores ya son muy similares. Con suerte, esta transición no será demasiado difícil. La mayor molestia que puedo ver es administrar el enjambre por separado de la (s) pila (s). Más trabajo general para mí, ya que no tengo interés en ejecutar aplicaciones compuestas en más de un nodo.

¿O tal vez estoy entendiendo mal todo ...?

+1 en la opción 2!
Y creo que la caída de la ventana acoplable a favor de la pila de enjambre será un gran inconveniente para la comunidad. Docker compose es tan simple y fácil de usar.

@tberne Estoy de acuerdo con eso. docker-compose es simple y simple es algo bueno. deberíamos votar para mantenerlo

¡Je, qué discusión tan extensa! No prestes mucha atención a este comentario, solo mis dos centavos.

Al principio estuve de acuerdo con la mayoría en agregar una especie de bandera enabled .
Luego vi una propuesta de ramificar definiciones por grupos y la consideré una buena idea.
Luego leí sobre Dobi, lo probé, me aseguré de que no se pudiera usar en mi proyecto en este momento y seguí leyendo.
Luego leí los argumentos de @ shin- y los consideré suficientemente buenos, a pesar de que también estuve de acuerdo con algunos contraargumentos.

Mi solución actual es crear algunos yamls de docker-compose y escribir algunos scripts de envoltura bash para no ejecutar docker-compose a mano.

Por ejemplo, así es como ejecuto contenedores que ejecutan un sitio web ( ./docker/scripts/up script):

#!/usr/bin/env bash

def_opts="-d"

cd "$(dirname "$0")"/../

# A separate bash file with functions like: get_args, add_hosts...
. ./functions.sh

docker-compose -p ${PROJECT} up ${def_opts} $(get_args "options services" "$@") && \

# Adding host to /etc/hosts
add_hosts "$HOSTS" web && \
add_hosts "$HOSTS_MAIL" mail

Gran +1 a la opción 2 o 3.

+1 para la opción 2 o 3.

¡También el concepto propuesto de "grupo" suena interesante!

+1 para la opción 2

_Hay tantos +1 on option x , que ni siquiera puedo encontrar la declaración original. En su lugar, use los botones de reacción debajo de las publicaciones.

Para agregar una nueva idea:

¿No podemos simplemente establecer una escala predeterminada en 0 ?

web:
  image: busybox:latest
  command: echo 'scaled'
  scale: 0

Debería hacer la opción 2 (pero tal vez no comenzar o algo así) porque la gente ha estado esperando años, luego envuelve docker-compose con sus propios administradores de configuración porque la herramienta es demasiado limitada, lo que anula el punto ya que está haciendo lo que debería hacer docker compose estar haciendo. En dos años, alguien también podría crear su propia ventana acoplable más potente. Eso es mucho tiempo durante el que ha estado abierto este problema.

A largo plazo, debería considerarse la posibilidad de agrupar verdaderas opciones. Algunos son relevantes solo para construir, algunos solo para ejecutar y algunos son mutuos (realmente desea una capa de anidamiento al menos para ejecutar o simplemente separar y tener una sección de compilación, problema resuelto). Actualmente, aunque muchas cosas son problemáticas en la configuración, estoy a favor de rehacerlo todo en la versión 5, pero hacerlo bien en ese momento (principalmente al representar lo real en un dominio de nivel técnico en lugar de tratar de hacer que mapee un uso basado en dominio o demasiado simple, en su lugar, cree una capa de configuración para esos objetivos encima de la correcta, no puede hacerlo al revés) Creo que debido a ese estado de cosas, la solución rápida está justificada.

+1 para la opción 2 o 4

Si no hay planes para agregar esta función actualmente, quiero que la forma de ejecutar dichos servicios (o tareas) en una composición esté escrita en los documentos de docker-compose.

Este es un hilo antiguo, y estoy de acuerdo en que docker-compose no se preocuparán por los _servicios que no se ejecutarán desde el principio_.

Pero también agrego comúnmente un servicio test , así que esto es lo que hice:

1. Anula el entrypoint del servicio.

2. En el nuevo entrypoint , verifique si hay un tty disponible ( docker-compose run usa --tty por defecto, mientras que up no lo hace).

   # Check if there is a tty
   if [ ! -t 1 ] ; then
     echo "No tty available."
     exit 0
   fi
   

   Esto siempre hará que el servicio salga cuando se ejecuta sin tty (con docker-compose up , por ejemplo) mientras aún se ejecuta como se esperaba con docker-compose run

@paulodiovani Eso parece más un truco que una solución.

+1 para una solicitud de función.
Hacks como tener comandos que no hacen nada significa que incluso si el contenedor no se ejecuta, aún debe construirse, inicializarse, etc.

Resolví esto en mi proyecto al proporcionar un script bash simple que llama al comando docker-compose apropiado según los argumentos proporcionados.

Ahora, si hago ./docker-compose.sh -e testing up , el resultado es el mismo que si hiciera docker-compose -f docker-compose.yml -f docker-compose.testing.yml up .
Si hago ./docker-compose.sh up , obtengo, como era de esperar, docker-compose up normales.

Por lo tanto, mi opción -e ${environment} (una abreviatura de --env ) es básicamente un alias de -f docker-compose.yml -f docker.compose.${environment}.yml . Esto da como resultado que docker-compose.yml sea ​​el archivo de composición base / predeterminado y archivos como docker-compose.testing.yml sean sus extensiones.

Esto resuelve de alguna manera el problema de docker-compose al hacer cumplir los valores predeterminados. No es una solución muy robusta ya que algunos pueden usar combinaciones de archivos de composición más complejas, pero creo que docker-compose debería poder hacer algo similar. Es probable que la mayoría de los archivos docker-compose comiencen con docker-compose. y terminen con .yml todos modos, entonces, ¿por qué siempre tengo que escribir un comando tan largo ( docker-compose -f docker-compose.yml -f docker-compose.testing.yml up ) si solo necesito un único servicio adicional para mi entorno de prueba?

No es necesario envsubst, la configuración de docker-compose hace las variables de entorno y luego la pila de docker las toma de stdin:

docker-compose config | docker stack deploy --prune --compose-file -

Vamos a utilizar también las sustituciones .env de docker-compose.

@kogli Creo que el problema aquí es elegir una opción. Todos tienen pros y contras. Como dije antes:

Cada solución será mejor para algunos casos de uso y peor (o incluso inútil) para otros. Si el algo se implementa, el mantenimiento lo mantiene para siempre, así que creo que son prudentes al tomarse su tiempo con él.

@ shin- Supongo que eres tú quien pregunta: ¿Tiene sentido considerar esto? Teniendo en cuenta la posición actual del equipo, lo difícil que es diseñarlo y las muchas herramientas que existen, ¿no sería más fácil simplemente decirle a la gente que esto no sucederá? La mayoría de las personas, si no todos los que comentaron aquí, encontraron una manera de lidiar con eso.

Cerrar esto parece bastante bueno, además puede concentrarse en las cosas que importan, y nadie se pregunta si deberían hacer una solicitud de extracción y cómo satisfacer todas esas necesidades al mismo tiempo. Pueden simplemente ir a construir algo más, y tal vez incluso publicarlo para ayudar a otros.

Solo para el registro : mi solución no fue perfecta, pero mucho mejor que los 2 días que me tomó instalar las dependencias y arreglar un montón de cosas y hacer que el proyecto se ejecutara (y ya usaba Docker). Solo 3 comandos, con Docker y Docker Compose como las únicas dependencias. Sí, había más código del que quería. Sí, hay una orden de mierda para ejecutar comandos. Y sí, hay un poquito más a tener en cuenta. Una página Wiki los cubrió. Bastante bien, si lo digo yo mismo, lo que significa que Docker Compose hizo su trabajo , yo también necesitaba algo más .

El punto es: si está fuera del alcance, es una pérdida de tiempo seguir discutiéndolo. Mucha gente simplemente se detiene aquí para preguntar sobre esto y dar su opinión, antes de intentar decidir qué hacer. Aún encontrarán o construirán algo más si esto está cerrado, solo más rápido. Y tienes un hilo menos para cuidar a los niños.

Editar: Solo pensé en una buena manera de decirlo: si no hay un criterio claro para aceptar las relaciones públicas y no hay nadie en el equipo central involucrado o planeando echarle un vistazo en el futuro previsible, no es un " problema ", solo una idea.

No veo ninguna razón para saturar la lista de temas, creo que muchas ideas aquí son buenas, pero creo que pertenecen a otra parte, para bien o para mal. Han pasado casi 3 años y, en caso de que algún día la situación cambie, siempre puedes volver a abrir esto o abrir un nuevo número al respecto.

Esta función tarda como un día en implementarse porque es realmente simple. Sin embargo, después de 2 años de discusiones, todavía nada. Triste.

@rubycut Sí, eso es lo que sucede cuando los llamados "principios superiores"

@rubycut Talk es barato,

@wangwenpei ¿Estás bromeando? En primer lugar, no eres responsable de este proyecto. Si los mantenedores aceptaran esta idea y pusieran la etiqueta "Se busca ayuda", estoy seguro de que alguien podría contribuir con la solicitud de extracción. Pero dijeron que no les interesa. Entonces, ¿por qué molestarse en extraer la solicitud si no se acepta?

Para su información, "el código" ya está allí: # 3047

@wangwenpei bueno, # 3047, está la solicitud de extracción ...
esperando obtener al menos algunos comentarios al respecto durante más de dos años. Fue cerrado recientemente

por las razones destacadas en https://github.com/docker/compose/issues/1896#issuecomment -322285976

lo cual me enoja bastante para ser honesto porque los argumentos dados en https://github.com/docker/compose/issues/1896#issuecomment -322285976 no se relacionan de ninguna manera con la solicitud de extracción:

1. ¿Qué es un servicio? Por diseño, un servicio es un proceso de larga duración claramente definido que interactúa con otros servicios para formar una aplicación. Esa es la suposición básica bajo la que opera Compose y guía nuestro diseño para la mayoría, si no todas, las características que implementamos.
2. Según esa definición, un "servicio que no se inicia de forma predeterminada" no es realmente un servicio [1], es más una tarea predefinida, que se ejecuta en un contenedor y actúa sobre la aplicación, en lugar de ser parte de ella.

No veo que la afirmación By that definition, a "service that is not started by default" is not really a service sea ​​cierta. Un servicio que no se inicia por defecto es solo un servicio que no se inicia por defecto, nada más, nada menos en este momento. Que se inicie por defecto o no no dice nada sobre que el servicio sea de larga duración o no, sea parte de la aplicación o no, solo dice que no debe iniciarse por defecto.

Y eso también es exactamente lo que hace el cambio en la solicitud de extracción: agregar la capacidad de marcar un servicio para que se inicie de forma predeterminada o no.
No es necesario introducir un nuevo concepto como tareas para hacer esto. De hecho, todos los demás argumentos en https://github.com/docker/compose/issues/1896#issuecomment -322285976 se derivan de la premisa falsa de 2. y, por lo tanto, no son aplicables a la solicitud de extracción que no intenta hacer nada más.

Solo para completar:

[1] Algunas personas mencionan querer tener "servicios opcionales", pero ese no es el caso de uso más común mencionado en este hilo. La mayoría de la gente quiere la función de "tarea", hasta donde yo sé.

Sí, hubo ejemplos de tareas únicas, pero también hubo ejemplos de servicios _real_ de acuerdo con su definición, es decir, casos de uso legítimos para esta función.
Ser capaz de usar esto para _también_ ejecutar tareas únicas que realmente no puedo aceptar como un argumento válido en contra de esto. Ya es posible definir un _service_ que no es de larga duración, no exponer a ningún puerto y no es una parte esencial de la aplicación de una forma totalmente válida docker-compose.yml .

De hecho, esta es también una de las soluciones sugeridas. Simplemente divida las _tareas_ en docker-compose.yml separados.
Las otras soluciones mencionadas son usar sus propios scripts hechos en casa (dependientes de la plataforma), lo que contradice totalmente el propósito auto-declarado de docker-compose, vea mi comentario anterior , o simplemente cambie a otra herramienta, es decir, deseche su perfectamente una cadena de herramientas que funcione bien solo para obtener esta pequeña característica en la conveniencia que podría implementarse fácilmente en su cadena de herramientas actual (docker-compose).

El único argumento real que se presentó contra la implementación más básica de la opción 2, es decir, tener _alguna forma_ de decirle a docker-compose que no inicie un servicio en particular de forma predeterminada, y nada más, no hay conceptos nuevos ni nada por el estilo, es que esto podría ser_de_algunos_ usuarios.
Pero este argumento es bastante débil en comparación con la demanda y los casos de uso legítimos presentados aquí ...

@espinilla-

pero también porque [3] simplemente no tenemos el tiempo o los recursos para implementar o mantener lo que esta característica necesitaría para ser realmente útil para las personas.
[3] Y en este punto me refiero a "yo", ya que soy el único mantenedor que trabaja activamente en docker-compose en este momento.

Por un lado, resaltar que solo hay un mantenedor activo mientras que, por otro lado, simplemente ignora las solicitudes de extracción y, por lo tanto, desperdicia cualquier oportunidad de quizás involucrar a otros desarrolladores en el proyecto, no es algo que pueda comprender.
Los cambios de código provistos en # 3047 ya _ implementan una característica que sería _ realmente útil para [muchas] personas_ - tal vez no _todas las personas con _todas_ sus _ casos de uso, pero la mayoría de las personas aquí.

Todos los requisitos adicionales - tener que introducir conceptos completamente nuevos, nueva gestión de dependencias, hasta una complejidad similar a cmake - ¡simplemente se siguen de una premisa falsa!

Me encontré con este problema hace solo un par de días porque estaba buscando una función como esta.

Como desafortunadamente no está implementado, y por lo que pude recopilar, la alternativa admitida oficialmente es usar varios archivos yaml.

Bueno, creo que la idea de usar varios archivos yaml para servicios que no se ejecutan de forma predeterminada es una mala alternativa en comparación con el uso de un archivo yaml para todos los servicios que contienen una configuración adicional para cada servicio que no se ejecuta de forma predeterminada.

Entonces, aquí está mi +1.