@jmmills ¿No puede iniciar sus contenedores como: "docker-compose scale worker = 5" y ese servicio comenzaría con 5?

@aanm Sí, pero creo que la funcionalidad debería reflejarse de forma predeterminada en la definición del servicio. Tal vez tenga un conjunto mínimo de trabajadores que siempre deberían estar ejecutándose y quiero que se declare claramente como predeterminado.

@ @aanm ¿ docker-compose up tenga en cuenta el parámetro scale ? El único problema que veo con esto es que estamos introduciendo parámetros en la configuración declarativa que NO son compatibles con los conceptos subyacentes de la API de Docker / Docker, pero son muy específicos de Docker Compose.

Si hiciéramos esto en el futuro; Sugeriría algo como:

#!yaml worker: build: rqworker $scale: 5 links: - redis command: rqworker -u tcp://redis

Donde $<parameter> denota una cosa específica de Docker Compose.

Hemos ido y venido sobre si scale pertenece al YAML; ha habido un PR para agregarlo antes (# 630). Sigo siendo de la opinión de que la mayoría de la gente no debería poner números de escala en su configuración, porque la hace menos portátil, pero entiendo los casos de uso para hacerlo.

Ahora que tenemos una forma rudimentaria de aumentar los archivos de Redacción con extends (y con suerte, mejores pronto - # 1380, # 758), las preocupaciones que planteé en https://github.com/docker/compose / pull / 630 # issuecomment -69210279 son quizás un problema menor.

Me gustaría establecer scale=0 en mi yml para servicios relacionados con pruebas que normalmente no quiero que se inicien. Solo quiero crear esos servicios explícitamente con docker-compose run o un scale explícito.

@jamshid A menudo he querido eso, una definición que configura un entorno pero que no se ejecuta de forma predeterminada. Me han relegado a crear una imagen base (con la que una escala cero / sin operación también ayudaría) en la que ejecuto mis pruebas unitarias (a través de docker run ), y luego la composición de mi contenedor consume el imagen base.

Algo como esto parece bastante útil para configuraciones de desarrollo

myproject:
    build: .
    command: nosetests
    scale: 0
    links:
       - redis
redis:
    image: redis
apiserver:
    image: myproject
    command: plackup
    links:
       - redis
workerserver:
    image: myproject
    command: rqworker
    links:
        - redis

@jamshid @jmmills ¿Qué tal un parámetro / clave enabled en el archivo YAML por servicio? ¿De tal manera que pueda deshabilitar / habilitar un servicio?

@prologic ¿
Si desea imaginar un proceso / contenedor en ejecución como una instancia de una clase, incluso podría nombrarlo instances

@jmmills Solo estoy tratando de encontrar una _solución_ para su caso de uso que no implique romper el docker-compose actual como tal. Tiendo a pensar que scale=0 no parece tan apropiado y no estoy seguro de si scale=X debería ser parte de Compose.

En mi opinión, la escala (o número de copias) es parte de la composición de un servicio, por lo que debe incluirse en la redacción.

Bueno, creo que tenemos una clave scale=0 o disabled .

: +1: al tener la capacidad de establecer un tamaño predeterminado scale para una instancia. Y estoy de acuerdo, una vez que la escala está adentro, no hay necesidad de una tecla disabled , ya que simplemente establecería la escala en 0.

+1

Además, otro caso de uso: ¿Qué pasa si quiero escalar el número de contenedores pero no quiero poner en segundo plano todos los servicios, o tengo que saltar a otra terminal (o proceso) y establecer mis números de escala ...
p.ej:

$ docker-compose up && docker scale thing=4

No funciona porque up no sale.
Pero si mi archivo de composición establece la escala de mis contenedores ...

$ docker-compose up

Se convierte en DWIM.

No estoy seguro de que realmente me guste esto; de repente up adquiere dos capacidades:

• Traiga los contenedores que no tengan el parámetro scale .
• Traiga todos los contenedores que tengan scale=0 .

Ahora estamos abusando realmente del comando "arriba". "Escala" también adquiere un nuevo significado en el sentido de que ahora hace dos cosas:

• escalar contenedores hacia arriba / hacia abajo
• Deshabilite contenedores / servicios por medio de ` scale=0

¿Por qué aparecerían contenedores con un scale=0 ?
Build construiría imágenes con scale=0 , facilitando así la necesidad de una imagen base.

_Podría estar equivocado_, pero al leer su último comentario, dio a entender que :)

Déjame elaborar:

base_thing:
    build: .
    scale: 0

thing:
    image: base_thing
    # scale: 1 implied by default

workers_for_thing:
    image: some_other_image
    scale: 4
    links:
      - thing

test_harness:
    image: base_thing
    command: nosetests --where=my_test_code_dir --all-modules
    scale: 0

Ahora, comportamiento esperado: docker-compose build construye cualquier contenedor con "compilación" (¿componen las imágenes externas en la compilación? No lo recuerdo), docker-compose up ejecutaría cualquier cosa con una escala positiva (el valor predeterminado es 1), docker-compose run test_harness construiría "base_thing" si fuera necesario y ejecutaría mi único comando. ¿Comprensión? :)

Editar: docker-compose up ejecutaría 1 "thing" y 4 "workers_for_thing"

Bien gracias; tu ejemplo tiene un bi más sentido y un poco más claro en cuanto a la intención de scale=0

Creo que docker-compose "extrae" imágenes en up / run .

Necesito crear una receta que indique el número de diferencias (escala), para prueba, producción, qa, etc.

+1 por scale=X . Esto sería muy útil.
Y +1 para el comentario de @jmmills con la descripción de la configuración y los resultados esperados.

¡Hurra! por scale=x . La inicialización de un conjunto de contenedores definitivamente ayudaría a identificar posibles condiciones de carrera al configurar configuraciones de clúster.

+1 por scale=x (incluido scale=0 para deshabilitar los servicios por el docker-compose up inicial)

+1 por scale=x .

x es NaN, yo propondría -1 lugar.

+1 para escala = x.

+1

+1

¿Qué tal si nos detenemos con los +1, por favor?

Hacer +1 es útil para ver el nivel de interés de una función.

@shofetim Conozco una mejor manera de hacer precisamente eso: implementar la función en cuestión y enviar una solicitud de extracción ...

Hacer +1 también es una buena manera de ver que la gente esté de acuerdo con una solución propuesta. Su comportamiento bastante común en github. Al hacer clic en el botón para cancelar la suscripción de las notificaciones, se desactivarán si eso es un problema.

Bueno, parece gente así. Hay un elemento similar en la lista de trabajos pendientes de redacción (sobrante de la figura), estoy bastante seguro de que hice un comentario al respecto en algún momento. Intentaré darle seguimiento más tarde esta noche.
Estoy en PuppetCon la mayor parte de esta semana, así que espero que me dé algo de tiempo para hackear. Veré si puedo escribir esto.

Aquí hay una solución para el caso de uso "scale = 0":

app:
  build: .
  environment:
    - DATABASE_URL=postgres://user:password<strong i="6">@host</strong>:5432/dbname
  command: sleep 999999999999

app_web:
  extends:
    service: app
  ports:
    - "3000:3000"
  command:
    # intentionally blank to use Dockerfile's default RUN command

app_worker:
  extends:
    service: app
  command:
    rake jobs:work

@wkonkel sí, he hecho cosas similares en el pasado.

Actualmente estoy trabajando para familiarizarme con la base de código de redacción, una vez que sepa dónde están todas las cosas para componer, piratearé un PR para un parámetro de configuración de escala.
No parece que vaya a ser demasiado difícil, hay un método scale para un proyecto que es el backend de la interfaz cli, así que todo lo que realmente debería hacer es agregar "escala" al esquema de campo, asegúrese de que si está presente para llamarlo después de la creación del contenedor ... luego asegúrese de que no ejecute un contenedor si está configurado en cero.

En realidad, hay un PR muy antiguo abierto para esto: # 630.

El problema es que la escala es una preocupación operativa, no forma parte de la definición de la aplicación, por lo que realmente no encaja con el archivo de redacción.

Sería bueno admitir una configuración para un nivel de escala predeterminado, pero no creo que el archivo de redacción sea el lugar adecuado para ello.

El caso de scale: 0 ya debería ser abordado por # 1754. Un contenedor "sin operación" puede tener un comando que salga de inmediato (echo, true, etc.). Los casos para querer scale: 0 suelen ser uno de dos: contenedores de volumen de datos o "tareas ad hoc / de administración".

Muy pronto, no deberíamos necesitar contenedores de volumen de datos porque los volúmenes están obteniendo nuevos puntos finales de API, y podremos definir volúmenes sin la necesidad de un contenedor.

Las tareas administrativas se manejan mejor con # 2051. Puede definir admin.yml que extiende el núcleo docker-compose.yml y le permite vincular sus tareas administrativas a la "composición del núcleo" sin enturbiar la definición de cada una.

Ambos cambios están en el maestro ahora y estarán disponibles en la versión 1.5.0 (que está a la vuelta de la esquina).

Así que eso solo deja el caso de querer escalar un servicio a> 1 por defecto. Ya es bastante fácil escribir algo como esto, pero poder ponerlo en un archivo de configuración aún sería bueno. Creo que vamos a explorar la idea de una configuración separada en el n. ° 745. En mi opinión, esta nueva configuración sería un buen lugar para cosas que no forman parte de la definición de la aplicación (nombre del proyecto, nombre de red predeterminado, escala predeterminada, etc.).

Respetuosamente, no estoy de acuerdo con que la escala sea solo una preocupación operativa. Las aplicaciones pueden preocuparse por el recuento mínimo de servicios en ejecución.
En lo que respecta al contenedor no operativo, se siente complicado ejecutar un contenedor cuando el propósito de ese contenedor es activar una imagen base que se construirá en la que otros contenedores usan para su campo image .

Las aplicaciones pueden preocuparse por el recuento mínimo de servicios en ejecución.

¿Podría dar un ejemplo de este caso?

En lo que respecta al contenedor no operativo, se siente incómodo ejecutar un contenedor cuando el propósito de ese contenedor es activar una imagen base que se construirá en la que otros contenedores usan para su campo de imagen.

¿Hay alguna razón por la que la imagen base deba ser parte de la misma compilación? Como digo en el n. ° 1455, compose no es principalmente una herramienta de "compilación de docker". Su objetivo es proporcionar una composición de contenedores en tiempo de ejecución. Tratar de admitir todos los escenarios de compilación posibles aumenta en gran medida el alcance de la composición y aleja el enfoque de la composición del contenedor. Sería difícil que incluso una herramienta diseñada en torno a la creación de imágenes respaldara cada una de estas solicitudes. Creo que una mejor dirección es mantener la mayor parte de la complejidad de la compilación fuera de la redacción y permitir que los usuarios cambien la herramienta de compilación adecuada en lugar de docker-compose build .

El caso de uso que me importa es scale = 0 (quizás abstract = true sería un mejor descriptor). Quiero compartir imágenes y variables de entorno entre diferentes comandos. Específicamente, quiero un servidor web en ejecución y un servidor de trabajos en segundo plano en ejecución, ambos con el mismo código y ambos con las mismas variables de entorno.

@wkonkel usando tu ejemplo, ¿supongo que esto también funcionaría?

app_web:
  build: .
  ports:
    - "3000:3000"
  environment:
    - DATABASE_URL=postgres://user:password<strong i="7">@host</strong>:5432/dbname

app_worker:
  extends:
    service: app_web
  command: rake jobs:work
  ports: []

Cambia tener un servicio abstracto con una anulación no operativa command por no tener resumen con una anulación no operativa en ports . ¿Eso suena bien?

1988 está relacionado con los servicios abstractos.

@dnephin Sí, eso funciona en mi caso.

En realidad, lo retiro ... Lo intenté con docker-compose-1.4.2 y parece que "ports: []" no anula al padre, por lo que el app_worker no puede comenzar con "el puerto ya está asignado ".

@dnephin El hilo puede tener una mejor explicación, pero intentaré articularlo aquí.

Lo primero que me viene a la mente son los sistemas de trabajo donde los contenedores separados que ejecutan el mismo código podrían modelarse como un tipo de servicio principal-> fork () -> grupo secundario en el que la configuración de la aplicación predeterminada quiere un número mínimo de trabajadores para la concurrencia.

Mi inspiración para esto vino de una aplicación que usa trabajadores RQ adjuntos a diferentes colas que compartían una imagen base que contenía mis paquetes de Python (código de trabajador), pero tenía varias instancias ejecutándose para cada cola. La disponibilidad mínima de simultaneidad era un requisito de la aplicación debido a los trabajos de larga ejecución.

Simplemente creo que tener un comando sin operación parece un desperdicio de recursos solo para obtener una imagen base compartida construida de la misma manera que el resto de la pila de aplicaciones. Terminas con un ciclo while / sleep solo para una imagen base, lo cual es una buena solución, pero no parece una forma intuitiva de lograr esto. Sin mencionar que deja un elemento en nuestro árbol de procesos sin función de tiempo de ejecución.

Si docker-compose es realmente no cruzar al dominio de codificar las relaciones de construcción de imágenes, entonces tal vez la opción de construcción debería desaparecer, y se deberían crear otros sistemas de definición de construcción para poder definir un objetivo de construcción para construir una imagen base. , y luego otras imágenes que consumen esa base con algunos de los artefactos / configuración modificados, y en el orden correcto?

O tal vez, estoy siendo demasiado obstinado y debería envolver mis comandos de composición de la ventana acoplable en scripts de shell para iniciar mis servicios con escala y definir todas mis compilaciones de imágenes como objetivos de creación con dependencias.

Simplemente creo que tener un comando sin operación parece un desperdicio de recursos solo para obtener una imagen base compartida construida de la misma manera que el resto de la pila de aplicaciones.

Con el # 1754 (en la próxima versión) eso ya no es necesario. Un servicio puede salir y no detendrá el resto de servicios. Así que puedes hacer que la base salga y no te preocupes por eso.

@dnephin Genial, ¿entonces proporcionaría un link a ese contenedor base / intermedio para asegurarse de que se construya primero?

@dnephin : Tengo un corredor de CI que hace el equivalente a docker compose up . Quiero que mi entorno de prueba se ejecute con varias versiones de un servicio (es decir, escala). Podría copiar todo el bloque de configuración, pero esto implicaría repetirme. En este caso, no es "solo una preocupación operativa", es algo que necesito en mi entorno de desarrollo mientras desarrollo una aplicación en clúster, que actualmente se describe completamente como un archivo de redacción. Por el momento, tendría que tener alguna configuración de escala fuera de banda y luego de alguna manera invocar docker-compose scale , supongo, pero esto no parece ideal e introduce más oportunidades de fallas y carreras.

En casos de producción, es posible que desee destacar sus servicios con una escala mínima. Digamos, por ejemplo, que está migrando de un clúster a otro, y dejemos algunas partes difíciles de la migración como datos de copia para simplificar el ejemplo; y realmente necesita comenzar a lidiar con algo de tráfico desde el principio, por lo que debe implementar con docker-compose al menos (n) instancias de algún servicio, digamos web.

Tener una escala en el servicio en el archivo de configuración realmente manejará eso. También es un caso de uso de usabilidad, ya que si el caso de uso de hecho expone el requisito de tener al menos (n) instancias de algún servicio en ejecución y no solo una en el punto de inicio.

Desde mi punto de vista, la escala es de hecho un parámetro definitorio de una topología y composición.

@dnephin

¿Podría dar un ejemplo de este caso?

Consul, MariaDB Master-Master o cualquier otra aplicación distribuida en Swarm realmente necesita tener al menos 3 nodos en el clúster para ser confiable. Definitivamente hay casos de uso para la cantidad de servicios disponibles en el archivo de configuración, no entiendo por qué está tan en contra. Big: +1: de mí aquí.

No estoy en contra de una forma de configurar la escala, simplemente no creo que pertenezca al archivo de redacción porque es el estado el que cambia independientemente del archivo de redacción.

Tome este ejemplo que asume que agregamos alguna configuración de escala al archivo de composición:

1. Establecí una escala inicial de 3 para un servicio.
2. Ejecuto docker-compose up -d , mi servicio escala a 3
3. Yo corro docker-compose scale service=4
4. Hago algunos cambios y vuelvo a implementar con docker-compose up -d .. ¿Qué sucede? ¿Se vuelve a reducir a 3? ¿Ignora la escala por completo ahora?

Ninguno de estos escenarios suena bien o apropiado, y este es solo un ejemplo trivial que ignora las fallas de instancia (lo que lo hace aún más complicado).

Si se agregara al archivo de redacción, creo que querríamos eliminar el comando scale , para que no entren en conflicto.

El ejemplo que da es un ejemplo de un requisito operativo. No necesita varios maestros para ejecutar la aplicación, lo necesita para la confiabilidad (operación) del servicio. Y aún puede lograrlo con scale db=x .

Usando el ejemplo dado arriba por @dnephin :

Primero, creo que el comando scale también es ingenuo, ya que no puede saber si va a escalar hacia arriba o hacia abajo un servicio, teniendo dos comandos diff para explicar la intención de escalar hacia arriba o hacia abajo simplemente diciendo cuántos servicios hacen que desee crear o eliminar respectivamente, será mucho mejor.

La respuesta a la pregunta planteada por @dnephin es que espero que se ejecuten tantos servicios / contenedores como antes de la modificación.

Compose es una herramienta sin estado que no conoce ni monitorea los servicios / contenedores que usa la API de Docker para ayudar a Ops a orquestar y ahí es donde creo que está el problema, compose fue diseñado para ser una herramienta de ayuda, no un servicio de orquestación completo, y ahora necesitamos ese, tenemos un motor que funciona bien, tenemos una máquina para aprovisionar y tenemos un enjambre para unirlos a todos en un clúster, pero filtramos un servicio / herramienta de orquestación real, uno que nos dio la flexibilidad de configurar y para administrar los servicios / contenedores implementados, algo como lo hace k8s. En este momento, componer es lo que se parece mucho a eso, pero si no es en el futuro de este proyecto evolucionar hacia algo más grande, lo mejor será que los desarrolladores y mantenedores oficiales lo cuenten para que podamos resolverlo de nuevo. herramienta que puede hacerlo.

Personalmente creo que será mejor evolucionar componiendo ya que es una gran herramienta y bien conocida por todos nosotros.

Me alegrará ver esto: docker-compose > docker compose .
No estoy seguro del resto de herramientas, pero para esto sería muy bueno tener una integración de estado con el motor. Perdón por un comentario fuera del tema.

Creé el # 2496 para mi propuesta de eliminar el comando de escala y reemplazarlo con la opción de escala (de la publicación anterior). Los comentarios sobre esta propuesta serían excelentes.

@dnephin con el # 2496 compose pierde la capacidad de escalar hacia arriba o hacia abajo fácilmente, tendremos que reconfigurar el archivo de redacción y luego ejecutar componer nuevamente justo cuando lo que solo necesitamos era escalar una instancia hacia abajo o hacia arriba, creo que esto es bastante Complicado.

Nuevamente estamos perdiendo el punto de que todos estos escenarios vienen del punto que componer es una herramienta sin estado y de que no puede controlar el estado de los servicios y cuántos de ellos hay en algún momento.

El escenario que mencionas en la nueva propuesta se resolverá fácilmente con un nuevo servicio / herramienta de estado completo.

+1

+1

+1

@dnephin ¿No sería el mismo comportamiento si lo hicieras?

$ docker-compose up -d && docker-compose scale node=4 && docker-compose up -d

¿No es más un problema con la forma en que la composición persiste a escala interna?

Esa es la cuestión, "Redactar la aplicación" no tiene estado. El único estado está en 1) el archivo de redacción y 2) las etiquetas del contenedor de la ventana acoplable administradas por el motor.

El archivo de redacción solo lo edita un humano, no Compose. Sería un desastre intentar escribir yaml con los mismos comentarios, orden y estructura. No es compatible con pyyaml ​​y no es algo que realmente quisiéramos hacer de todos modos.

El motor de la ventana acoplable no es consciente de la escala, por lo que no puede almacenar ese estado. Es posible con cambios arquitectónicos mucho más grandes, pero eso está un poco fuera del alcance de este problema.

Por ahora, nuestras opciones son básicamente mantener la escala como una opción de línea de comando o moverla al archivo de redacción, pero como describo en el n. ° 2496, creo que tener ambas cosas es confuso y conduce a un comportamiento incorrecto.

up && scale && up realmente hace lo correcto ahora. up recreará todos los contenedores, y dado que no hay un valor de escala en la configuración, no hay confusión sobre cuál debería ser la escala deseada. Ya estaba establecido por el comando de escala y rastreado por las etiquetas de los contenedores.

@dnephin Creo que estoy de acuerdo con lo que dice, [podría estar equivocado en esta suposición] que lo que realmente está cuestionando es _si_ el número de instancias de un componente es en realidad la preocupación de la composición de un servicio (una agrupación de contenedores ejecutando diferentes contenedores de componentes). Yo diría que actualmente está abordando esa preocupación, solo con la advertencia de falta de paridad entre el cli y la definición de composición (yaml).

Si el alcance de la responsabilidad se determina que la escala no es una preocupación de la composición, entonces la escala debe eliminarse como una opción de cli (probablemente enojará a muchos usuarios), o si se determina que la escala es la preocupación de la composición de un servicio. que debe haber paridad entre cli y yaml con el soporte adicional de un mínimo de instancias para tener en cuenta las instancias agrupadas que requieren N + 1.

De acuerdo con @jmmills Especialmente cuando se ejecutan clústeres de contenedores de datos, cuando la disponibilidad y la replicación van de la mano, un mínimo de scale es parte de la aplicación: sin la escala adecuada, es posible que ni siquiera funcione

+1

+1

+1

Actualmente necesito declarar cosas como esa:

selenio-cromo1:
...
selenio-cromo2:
...

Sería bueno:
selenio-cromo:
escala: 2

+1

exactamente lo que dijo @caioquirino . +1

docker-compose up debería mostrar un entorno de trabajo sin requerir otro trabajo. La única forma de mostrar los servicios que requieren múltiples nodos es usar el patrón que menciona

La escala en el archivo yml corrige esto.

Big +1, también me gustaría usar esto para definir servicios que tienen una escala establecida en 0 inicialmente.

En la línea de...

consul_bootstrap:
  build: ./consul
consul_master:
  build: ./consul_master
  scale: 0

La idea es que pueda usar el mismo docker-compose.yml y realizar la transición sin problemas de un entorno de desarrollo a producción. Las instancias de consul_master se unirían automáticamente a la balsa y establecerían un quórum haciendo docker-compose scale consul_master=3 . Esto sería genial.

Para responder a @dnephin ...

Tome este ejemplo que asume que agregamos alguna configuración de escala al archivo de composición:

1. Establecí una escala inicial de 3 para un servicio.
2. Ejecuto docker-compose up -d, mi servicio escala a 3
3. Ejecuto docker-compose scale service = 4
4. Hago algunos cambios y vuelvo a implementar con docker-compose up -d .. ¿Qué sucede? ¿Se vuelve a reducir a 3? ¿Ignora la escala por completo ahora?
5. Me encanta
6. Bien
7. Sigo contigo
8. Creo que debería haber alguna diferenciación entre una implementación existente y una nueva implementación para que se pueda mantener la continuidad de la escala para las implementaciones existentes que están recibiendo actualizaciones continuas. Una implementación individual incluiría el entorno DOCKER_HOST, etc., junto con la escala de cada componente, los ID de imagen y un historial de redespliegue. ¿Este podría ser un buen lugar para conectarse a los mecanismos upstack, como la implementación continua o las implementaciones azul-verde? Me estoy imaginando un flujo de trabajo un poco más listo para la producción, por lo que simplemente puede conectarse a un DOCKER_HOST diferente y hacer un docker-compose up -d y luego proporcionar enlaces para que las herramientas upstack puedan administrar cosas como CI y despliegues azul / verde. Tal vez agregue algo como DOCKER_COMPOSE_ENV = {"testing" || "producción" || "dev"}?

En mi humilde opinión, habiendo "codificado" scale , digamos a 3, debería comenzar con 3 contenedores

Creo que mucha de la confusión sobre un parámetro de "escala" frente al comando "escala" se aliviaría nombrando el parámetro YAML "escala_inicial" o "escala_predeterminada". Eso deja bastante claro que es solo un valor que se usará si no hay algún tipo de anulación. También (al menos en mi humilde opinión) parece razonable que este parámetro "initial_scale" solo se haga referencia cuando docker-compose muestra el servicio por primera vez, y no cuando se ejecuta docker-compose de nuevo con algunas instancias del servicio que ya se están ejecutando.

+1 para "initial_scale", también describirá explícitamente este parámetro como específico de composición, porque la ventana acoplable en sí no tiene dicho parámetro.

Ocurrió algo interesante, en la publicación del blog https://blog.docker.com/2016/02/video-containers-as-a-service-caas/ en el video "48.56 muestra que en el nuevo centro de datos de la ventana acoplable puede, en el punto de creación de la pila, configurar cuántas instancias de un contenedor desea ejecutar. Por lo tanto, esta idea no es nueva para el equipo de Docker, espero que se incluya en las próximas versiones de redacción

+1

+1

Millones de problemas y solicitudes scale / initial_count y así sucesivamente ... y aún no están planificados.

Es triste ver un buen proyecto, pero las personas solo encuentran excusas y crean problemas nuevos y duplicados, cierran problemas y "hacen" el trabajo.

+1

+1

+1

+1

¡POR FAVOR DEJE DE!
¡NO AÑADIR +1!
¡SÓLO SUSCRÍBETE AL NÚMERO!

+1 ( @pierrre lo siento)

+1 es muy importante ( @pierrre , lo siento)

Estoy de acuerdo, pero no quiero recibir 100000 notificaciones por tu "+1".

/ me bifurca la ventana acoplable componer y comienza a aprender el código base.

Muchos puntos válidos anteriores, parece que tener un parámetro default/inital scale en el archivo de configuración + un comando scale cli abordará ambos. Para agregar casos de uso en apoyo de una opción de escala inicial, considere los servicios en clúster donde un quórum consiste en un número X de nodos y que no deberían estar operativos de otra manera (por ejemplo, no menos de 3). El objetivo de docker-compose es tener un descriptor completo de dicho sistema.

Mi caso de uso es:

He ampliado un servicio con algunas configuraciones comunes para permitir una menor duplicación. Sin embargo, se crea el servicio base (cuando se ejecuta sin especificar explícitamente los nombres del servicio) y luego lo apago manualmente. Me gustaría que el servicio base tuviera una escala inicial de 0.

Estoy de acuerdo en general. Aunque en mi opinión, este problema y los problemas vinculados / relacionados se reducen a un problema ligeramente diferente: up y scale finalmente quieren ser el mismo comando.

A veces ya lo están:

• docker-compose up service
• docker-compose scale service=1 .

Y, si scale expuso todas las opciones cli (por ejemplo, --force-recreate ) que hace up , o si up supiera sobre contar, entonces básicamente lo serían.

Si, como propone este número, se agrega una directiva de "escala inicial" al docker-compose.yml , entonces up tendrá que aprender a contar. En ese momento, ¿no debería up simplemente admitir la sintaxis de conteo docker-compose up service=10 (que podría sobrescribir cualquier escala definida en el yaml)?

Se hace una distinción entre "escala inicial" y "escala", que podría ser el dominio de diferentes comandos. Pero debido a que up es idempotente y está diseñado para ejecutarse repetidamente sin necesariamente cambiar de estado, no creo que esta distinción sea estricta. Creo que, en cambio, deberíamos considerar tener up canibalizar scale directamente.

@mattgiles Estoy de acuerdo, ahí es donde iba con el # 2496, sin embargo, no había considerado que el service=count podría agregarse a up . Creo que eso podría manejar la situación. El único problema que veo es que actualmente up web significa solo abrir el servicio web y sus dependencias. Intentar hacer up web=3 tendría que seguir significando lo mismo. Lo que significa que no hay forma de up todo y anular el recuento de la escala a la vez, pero probablemente esté bien.

Actualizaré la propuesta en el n. ° 2496

@dnephin Me perdí la propuesta más reciente. ¡Impresionante!

fwiw, creo que es totalmente intuitivo que docker-compose up web=3 muestre tres contenedores para el servicio "web", así como cualquier dependencia ... en las proporciones definidas en el yaml (por algo como scale directiva). De esa manera, el archivo de redacción continúa gobernando a menos que la línea de comandos lo invalide.

Las invocaciones posteriores de up podrían continuar, como lo hacen ahora, para dejar los contenedores existentes en paz. Solo si la escala actual es más pequeña que la definida en el yaml, cambiaría los conteos para estar en línea con la escala prohibida. Ninguna escala definida continuaría implicando una escala de 1.

Cosas como --force-recreate probablemente también deberían dejar los recuentos en paz si son más altos que los definidos en el yaml, pero aún así volver a crear todos los contenedores para que estén en línea con otros atributos.

También tendría sentido para mí poder matar contenedores, como se puede hacer actualmente con scale , llamando a algo como docker-compose up web=2 etc.

+1

+1 (solo para molestar a @pierrre ;))

+1

+1 para escala = x.

Relacionado con esto, me encantaría una forma de describir Singletons. scale=1

Cualquier éxito aquí con la opción de escala

+1

No he visto nada nuevo en esto desde el principio, personalmente no he tenido la oportunidad de ver si puedo hackear un parche para él.

Gracias,
Jason Mills

• enviado desde el móvil.

El 8 de agosto de 2016, a las 5:19 p.m., lavvy [email protected] escribió:

Cualquier éxito aquí con la opción de escala

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o silencie el hilo.

+1

+1

+1

+1

+1 (para molestar a @pierrre de nuevo)

+1

Me gustaría repetir el caso.

escala = 0
Útil para probar, depurar. probe, etc., servicios que normalmente no desea que aparezcan, pero que desea definir, porque generalmente se usan en el contexto de los otros servicios en el archivo.

escala = 1
Porque quiero uno y solo uno de estos, _ever_. En un clúster de MariaDB, hay casos en los que es posible que solo quiera un único nodo configurado con un motor de almacenamiento específico (por ejemplo, Spider, ColumnStore, etc.).

escala = n
Porque hay momentos en los que sé que necesito 'n' servicios ejecutándose, por ejemplo, un clúster MariaDB donde siempre tendré un Primario (con su configuración) y dos Secundarios (con su configuración diferente, de Primaria).

Tiene mucho sentido para mí @alvinr. El valor predeterminado debería ser probablemente 1.

DISCLAMER: No soy un representante de Marathon o Mesosphere

Este es otro ejemplo de una solicitud de función bastante simple que ha sido abandonada / rechazada por el equipo de soporte de Docker durante más de un año. https://github.com/docker/docker/pull/12749 es otro ejemplo. Kubernetes y Marathon tienen estas opciones desde hace bastante tiempo ("instancias": 3 en el archivo marathon.json) e incluso implementan el escalado automático. Es la falta de voluntad del grupo de apoyo de Docker lo que me ha alejado del centro de datos de Docker y el enjambre desde hace algún tiempo.

Kontena tiene esto también como instances: 3 (https://www.kontena.io/docs/references/kontena-yml)

Otra forma en que podríamos hacer esto es agregar una sección scale en la versión 2 del archivo de redacción.

No se combinaría con las opciones de solo Docker que se usan en los servicios.

Un ejemplo sería:

version: "2"

services:
  worker:
    image: something
    command: work

scale:
  worker: 2    

Esto con la capacidad de especificar scale: 0 potencialmente mataría dos pájaros de un tiro, siendo el otro https://github.com/docker/compose/issues/1896

Esto parece una obviedad.

Quiero implementar nginx + nodejs + mongodb con 3 o 4 instancias de nodejs. Cada vez que inicio la aplicación.

Si tiene una opción de línea de comandos para hacerlo, ¿por qué no en el archivo yml?

docker-componer a escala nodejs = 4

Haría.

Es simple. Quieren seguir la ruta de "alguien más lo construye y nosotros
intentará admitirlo ". Aparte de la ventana acoplable base, no han creado
cualquier cosa. Componer era un producto diferente que consumían y ahora tienen
no tengo idea de cómo apoyarlo / extenderlo, razón por la cual productos como maratón y
los kubernetes son más populares que enjambres.

El 16 de octubre de 2016 a las 21:36, "Michael Schwartz" [email protected]
escribió:

Esto parece una obviedad.

Quiero implementar nginx + nodejs + mongodb con 3 o 4 instancias de nodejs. Cada
vez que inicio la aplicación.

Si tiene una opción de línea de comandos para hacerlo, ¿por qué no en el archivo yml?

docker-componer a escala nodejs = 4

Haría.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/compose/issues/1661#issuecomment -254093296,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AES98nZt1uIejnIU9iajVt54QbzdlVK1ks5q0tETgaJpZM4FS8ZQ
.

Honestamente, estoy un poco sorprendido de que haya _cualquier_ rechazo en esto, ya que parece tan obvio tener ...

@westlakem Esperemos que Docker para MacOS no sufra el mismo destino, con suerte los chicos de Unikernel se quedan.

Sería bueno mostrar una pila completa en su tamaño funcional de una sola vez. En nuestro caso de uso actual, la pila de servicios debe tener "trabajadores = 16" para funcionar correctamente.

Esto es horrible:

docker-compose up -d
docker-compose scale workers=16
docker-compose down
docker-compose up --abort-on-container-exit

que claramente podría reemplazarse con algo como:

docker-compose up --abort-on-container-exit --scale workers=16

Editar: Veo que "Rancher" tiene una sintaxis similar a la de docker-compose y admite un parámetro de escala inicial: https://paypertrail.com/blog/tech/docker-rancher-and-laravel-easy-and-safe-scalability

Una solución alternativa es usar las capacidades de unión y anclaje YAML y duplicar el servicio dentro del archivo docker-compose.

services:
  toscale: &my_service
     ... # all paramteres
  # second instance
  toscale2: 
     << : *my_service
     ports:
       - 81:80 # override port if needed

etc ...

¡Esto sería muy útil!

Esto es muy raro, esto no existe ...

Podría terminar teniendo que crear servicios duplicados porque soy así de vago.

Esto ya está en el trabajo en el archivo compositor v3 https://github.com/aanand/compose-file/blob/master/schema/data/config_schema_v3.0.json que será y ya es compatible con docker-compose v1. 10.0-rc1

Sus ofertas de "Servicios" tienen el parámetro incorporado. Es muy triste que, como
suscriptor a este problema, nadie del equipo de desarrollo nos informó que
venía en el producto de Servicios, y alguien tenía que leer las notas de RC
por 1,10 para cualquier información. ¿Dónde están los representantes de Docker?

El viernes 6 de enero de 2017 a las 6:30 a. M., Yasmany Cubela Medina <
[email protected]> escribió:

Esto ya está en el trabajo en el archivo del compositor v3 https://github.com/aanand/
compose-file / blob / master / schema / data / config_schema_v3.0.json que será
y ya es compatible con docker-compose v1.10.0-rc1

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/compose/issues/1661#issuecomment-270886347 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AES98nOAW-h0BVaR8D9uQfLpMCQRfdyfks5rPiXEgaJpZM4FS8ZQ
.

+1

+1

Hola, tengo una pregunta relacionada.
Alguna vez me pregunté si docker-compose up puede recordar la escala que configuré.

Por ejemplo, ejecuto docker-compose scale nodejs_web=4 luego docker-compose down ,
luego empiezo de nuevo docker-compose up , se iniciará 4 nodejs_web.

Quiero saber dónde guarda el comando scale el número 4?

El docker-compose.yml puede ser:

version: '2'
services:
  nodejs_web:
    image: node
    command: node

Apoyo la propuesta de @dnephin en # 2496
Por favor dénos esta característica básica.

Los servicios de la nueva versión de Docker ofrecen una función de "réplicas".

El lunes, 20 de marzo de 2017 a las 3:28 p.m., alwaysastudent [email protected]
escribió:

Apoyo la propuesta de @dnephin https://github.com/dnephin en # 2496
https://github.com/docker/compose/issues/2496
Por favor dénos esta característica básica.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/compose/issues/1661#issuecomment-287870998 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AES98uWGEnbyCFyxNSSlv7QkXy5oBek1ks5rntNBgaJpZM4FS8ZQ
.

@westlakem : esa característica es para enjambres. No es para escalar el servicio regular.

Tantos pros, pocos contras. ¿Qué pasa con este problema?

Hay una propuesta más reciente sobre la eliminación completa del comando scale en https://github.com/docker/compose/issues/2496

Realmente no entiendo por qué o por qué no hay la opción initial_scale: 3 en el archivo de redacción (entiendo por qué no puede ser solo scale: 3 )

Implementado en 1.13.0. Gracias a todos por sus comentarios y paciencia.

@ shin- ¿Por qué se considera cerrado? Al administrar aplicaciones a gran escala donde TODO está automatizado y en control de versiones, ahora debo modificar mi Ansible, que ejecuta Docker para definir cuántas instancias de un servicio se ejecutarán.

Ansible debería estar configurando todo para que Docker pueda ejecutarse. Docker debería definir cuántas instancias de un servicio necesita la aplicación. Ahora es responsabilidad de Docker conocer el inventario de servicios, pero es responsabilidad de Ansible llamar a Docker para que sepa cuántos contenedores activar.

@greenscar Lo siento, no estoy seguro de cuál es el problema. ¿No está satisfecho con la forma en que se implementó la función? Si es así, ¿de qué manera podemos mejorarlo?

¿Por qué no está presente en la versión 3? Extremadamente confuso ya que "deploy.replicas" y "up" no son equivalentes, se podría decir que esta característica falta en v3.

@cgarciae deploy.replicas tiene el mismo propósito que scale . ¿Por qué no son equivalentes en su opinión?

@ shin- Si no quiero crear un enjambre y solo uso docker-compose up -d , docker compose me dice que ignorará la configuración de "implementación".

@cgarciae ¿

Creo que todos los que usan la ventana acoplable esperan que el parámetro de escala funcione para los archivos de la ventana acoplable 2 o 3. No hay ninguna razón para que no lo haga e incluso podría establecer el valor predeterminado para deploy.replicas también. Si se establece deploy.replicas, anula la escala en swarm. ¿Qué tiene de malo esta imagen aparte de que es lo que todo el mundo espera que suceda (y, por supuesto, si no te gusta no es necesario que la uses en tu docker-compose.yml)?

El parámetro de escala faltante hizo que un servicio fallara, ya que olvidé escalarlo como estaba antes desde la última redistribución -.- ¿Por qué esto no es algo que salvaría el servicio y tal vez incluso vidas dependiendo de lo que se esté ejecutando?

Solo golpee este problema también. ¿Parece que no hay forma de especificar cuántos servicios comenzar desde dentro de la configuración de composición de la ventana acoplable? Es aún más confuso que la documentación de docker compose tenga mucha documentación para cosas que no funcionan con docker-compose ...

Oh, espera, si cambio la configuración de composición de mi ventana acoplable a version: "2.2" entonces puedo usar scale: 2 pero si uno quisiera ir a una versión posterior, ¿ya no hay una opción para hacer esto?

Ok, veo que este problema de "versión" no significa realmente que las versiones ya se han mencionado, https://github.com/docker/compose/issues/4693

Utilizo v3.6 porque necesito algunas configuraciones que no existen en 2.2. Para el desarrollo local no uso swarm, pero quiero establecer scale = 0 en algunos contenedores en mi docker-compose.overrides.yml. Porque algunos de ellos son solo para procesos de compilación como el contenedor frontendbuild. Este contenedor comparte algunos volúmenes con otros contenedores en ejecución, pero no debe iniciarse junto con estos otros contenedores en docker-compose up. Entonces el buildcontainer solo se ejecuta con el comando run. Sí, puedo configurar el parámetro --scale para llamar a docker-compose, pero creo que es mejor escribirlo directamente en la configuración. :)

Gracias por el parámetro de escala. Pude usarlo en un docker-compose.yml que no es de producción para que cualquiera pueda usar una configuración HA de Consul y Vault. El parámetro de escala facilitó el aprovisionamiento de una configuración HA local. https://github.com/samrocketman/docker-compose-ha-consul-vault-ui

En este caso, solo está destinado a que alguien pruebe Consul y Vault en una configuración HA y use Consul DNS.

¿En qué versión de Docker Compose se está ejecutando? Desde la versión 3, esta función se ha eliminado (por gota, quiero decir, nunca implementada), por lo que se ignora. Ver https://docs.docker.com/compose/reference/scale/

Nunca uso el formato v3 debido a la falta de funciones. Tiendo a usar el formato 2.1 o 2.2 más bajo, dependiendo de las funciones que esté usando.

Editar: por no decir que evito el formato v3. Solo que cuando voy a escribir un archivo de redacción, generalmente falta lo que quiero usar.

Ok, supuse que hablas de docker compose con swarm stack, por eso. Nunca lo intenté, pero es extraño hablar de HA con docker compose sin orquestador y nodo mutli. ¿Es para "poc" o con fines de prueba? De todos modos, nunca lo intenté en este contexto.

En este caso, HA simplemente se refiere a un clúster de cónsul y un clúster de bóveda. Está destinado a servir como una prueba de concepto disponible para la experimentación y la facilidad de arranque. La HA no se refiere a Docker HA o incluso a HA multimáquina. Es solo HA en el sentido de que la persona que experimenta puede matar uno de los contenedores del clúster y ver que el servicio de cónsul y / o bóveda no se ve afectado.