Compose: Agregue `copy` a la configuración de yaml

¿Cuál es la semántica de copy aquí? ¿Estamos copiando archivos del host desde donde se ejecuta docker-compose en el contenedor recién ejecutado usando docker cp ?

AFAIK, no hay una forma actual de hacer esto:

Ver:

`` #! bash
$ docker cp -h

Uso: docker cp [OPCIONES] CONTENEDOR: PATH HOSTDIR | -

Copie archivos / carpetas de un PATH en el contenedor a un HOSTDIR en el host
ejecutando el comando. Utilice '-' para escribir los datos como un archivo tar en STDOUT.

--help = false Uso de impresión
''

¿Cuál es la semántica de la copia aquí? ¿Estamos copiando archivos desde el host desde donde se ejecuta docker-compose en el contenedor recién ejecutado usando docker cp?

si

AFAIK, no hay una forma actual de hacer esto:

Veo que el comando docker cp no puede hacerlo. Sin embargo, todavía es posible accediendo a los datos del contenedor en el lado del host (lo cual, según reconozco, es feo)

http://stackoverflow.com/a/24805696/210090

Sí, no voy a defender que hagamos esto en absoluto. Esto romperá muchas cosas y suposiciones sobre Docker. Esto también depende en gran medida del controlador de almacenamiento subyacente que se utilice. Docker está destinado a ser agnóstico. Creo que _ deberíamos_ una solución diferente a tu problema :)

Ahora que docker-1.8 agregó soporte para copiar en un contenedor a través de docker cp y swarm-0.4.0-rc2 agregó soporte para docker cp , sería genial volver a examinar este problema en el nivel de redacción. Este es el caso de uso (que refleja lo que realmente hacemos en _casi_ producción ahora):

Un archivo docker-compose.yml que menciona muchos contenedores por etiqueta de imagen construida por CI (es decir, no usamos build: en producción; tal vez podríamos ahora, pero no funcionó bien con swarm en versiones anteriores) que todos necesitan, por ejemplo, archivos de configuración de hadoop estáticos mapeados en los que coincidan exactamente con el entorno de implementación. Actualmente, uno debe sincronizar manualmente el directorio en el que reside docker-compose.yml con la ruta exacta en _ cada_ docker-machine de destino en el enjambre. Luego se agrega una pila de volume: líneas.

Admitir docker cp permitiría la eliminación de una sincronización de archivo de configuración personalizada en nuestro método de implementación del sistema y permitiría un mejor control de cuándo se inyectan los cambios de configuración (ya que cualquiera que cambie los archivos mencionados en las líneas volume: está afectando todos los contenedores implementados anteriormente (y en cualquier momento en que las implementaciones internas vuelvan a leer dicha configuración, tal vez solo en el próximo reinicio del contenedor, tal vez cuando se inicien varias herramientas dentro del contenedor; lo que puede ser inesperado) y en el futuro (lo que se espera).

OTOH, (como se mencionó brevemente arriba) tal vez deberíamos usar build: . La desventaja aquí es que necesitamos escribir un Dockerfile adicional por tipo de contenedor de implementación. Uno para las imágenes creadas por CI y un segundo para el inyector de archivos de configuración estática. copy: en redacción respaldada por los cambios recientes en docker cp nos permitiría evitar toda esta duplicación.

Todavía parece que usar un volumen es una mejor manera de hacer esto. No tiene que ser un volumen de host, debería funcionar con un contenedor de volumen de datos.

Bedies docker-machine tiene docker-machine scp todos modos lo que puede hacer con la preparación de la máquina; y luego puede hacer volúmenes de host de la manera normal con docker o docker-compose

"Todavía parece que usar un volumen es una mejor manera de hacer esto. No tiene que ser un volumen de host, debería funcionar con un contenedor de volumen de datos".
No veo cuál es la mejor forma de hacerlo cuando el objetivo es un enjambre. AFAICS, uno no tiene forma de expresar que debería existir un contenedor de volumen de datos en cada posible nodo de enjambre.

¿No puede implementar un contenedor de volumen de datos en cada nodo a través de swarm de todos modos como puede hacerlo con cualquier otra estrategia de programación de contenedores?

"Bedies docker-machine tiene docker-machine scp de todos modos, lo que puede hacer con la preparación de la máquina; y luego puede hacer volúmenes de host de la forma normal con docker o docker-compose"
Actualmente hago esto. Es doloroso. Las personas que administran las implementaciones se olvidan de mover los archivos de configuración. Si fuera compatible con docker-compose yml, sucedería cada vez que se recreara un contenedor sin los pasos manuales.

"¿No se puede implementar un contenedor de volumen de datos en cada nodo a través del enjambre de todos modos, como se puede hacer con cualquier otra estrategia de programación de contenedores?"
Quizás podríamos, pero admito que no veo cómo a la luz de la escala.

"¿No se puede implementar un contenedor de volumen de datos en cada nodo a través del enjambre de todos modos, como se puede hacer con cualquier otra estrategia de programación de contenedores?"
Humm, si sé que mi enjambre es de tamaño 10 nodos; ¿Puedo escalar el contenedor de volumen de datos para que tenga un tamaño 10 con una política de que no se permiten dups en un nodo de motor de Docker determinado? El problema (a menos que me haya perdido algo) es que, por ejemplo, los contenedores que necesitan hacer referencia a ese volumen de datos no tienen forma de --volumen- desde un contenedor con un índice que coincida. Chicos, he estado analizando este problema durante 2 meses. Lo mejor que pude hacer es crear un script que use docker-machine scp . Pero es un paso manual después de editar un archivo de configuración y antes de docker-compose up . También requiere que uno pueda escribir la ruta exacta en las máquinas de destino del enjambre como la raíz del docker-compose.yml (es decir, huele a un truco importante).

¿Quizás mis esfuerzos en la fábrica pueden ayudar a automatizar este proceso de poner en marcha máquinas acoplables y agrupar clsuters con los datos "correctos" listos para usar? (_ aunque todavía está en desarrollo temprano y lo estoy usando para combinar docker-machine y docker-compose en un solo setp_0.

copy es una operación, no parte de la configuración del servicio, por lo que no pertenece al archivo de redacción.

Docker 1.9 está agregando una nueva API de volúmenes y los controladores de volumen ya están incluidos. Los volúmenes son realmente la forma correcta de respaldar esto. No intentar copiar archivos.

¡Gracias por la sugerencia! pero no creo que esto realmente encaje con el diseño de componer en este momento.

copiar es una operación, no parte de la configuración del servicio, por lo que no pertenece al archivo de redacción.

¿Qué pasa si uno quiere copiar solo un archivo de configuración? (a un enjambre de docker, por lo que volume_from no funcionaría)

Tengo exactamente la misma situación, quiero copiar archivos de configuración mysql, nginx, haproxy, etc. personalizados, tenemos clústeres en producción, y en lugar de usar un solo comando de copia para copiar configuraciones de local a remoto

Tengo que usar imágenes, compilar, extraer cada vez, mientras que no hay ninguna necesidad y solo copiar el comando ahorrará mucho tiempo de implementación y desarrollo

Es muy sorprendente para mí que más personas no tengan problemas con que esto no sea fácilmente programable. ¿Estoy pensando mal en Docker? Creo que mi solución ahora sería usar ansible para copiar los archivos de configuración al host y luego montar el volumen desde el host a los contenedores que lo necesitan

Golpeando el mismo problema. Estoy reutilizando un Dockerfile para N servicios diferentes y no quiero crear N Dockerfiles diferentes con su propio comando COPY o crear un volumen solo para eso.

Por cierto, actualmente estoy resolviendo eso ejecutando docenas de líneas de comandos sed: http://unix.stackexchange.com/questions/112023/how-can-i-replace-a-string-in-a-files

Tal vez no sea la solución óptima, pero funciona teniendo en cuenta que docker-compose no admite la copia de archivos.

Por cierto, el montaje y la copia son posibles, por supuesto, pero va en contra de las ofertas de docker-compose de automatización; si prefiriera hacer todo manualmente, no usaría docker-compose, ¿no?

Cuanto más he profundizado en Docker, más parece que muchas de estas herramientas son buenas para "hola mundo" / "mira lo rápido que puedo hacer girar esta cosa genial con \ shell \ commands \ like \ this \" en un casos de uso de un solo tipo de máquina (docker-compose incluido). Si va mucho más allá de eso, las cosas comienzan a complicarse bastante y la OMI se desmorona un poco, que es donde las herramientas de aprovisionamiento tradicionales pueden entrar y salvar el día cuando se usan adecuadamente.

Descubrí que usar Ansible para configurar máquinas de una manera idempotente es muy fácil cuando tengo volúmenes, archivos y archivos de configuración de plantilla específicos de la máquina que deben existir para que se inicie la imagen de la ventana acoplable. Luego, al final, puedo usar Ansible para invocar docker-compse o incluso usar el módulo de la ventana acoplable Ansible cuya sintaxis es casi exactamente la misma que la de la ventana acoplable con algunas características adicionales interesantes.

Al final del día, el enfoque anterior permite que todo sea programado, idempotente y, lo más importante, verificado en el control de fuente.

@dnephin Algunas personas sugirieron el caso de uso de CP como parte de la configuración, ¿tendría sentido revisar la suposición de que CP es solo para operaciones y no para configuración?

Un ejemplo simple es crear un contenedor, copiar la configuración en el lugar correcto e iniciar el contenedor una vez que se haya copiado la configuración.

Esto permite la creación de imágenes que no incorporan la configuración real y solo implementan la configuración cuando se inicia el contenedor.

Definitivamente será de mucha ayuda. Ahora estoy trabajando con la imagen de postgres como back-end de la base de datos y no quiero reconstruirla, solo para actualizar un script en la carpeta /docker-entrypoint-initdb.d .

¿Por qué no vuelven a abrir este problema hasta que se implemente la función o se encuentre una solución viable que le guste a la gente, ya que a nadie aquí le gustan las opciones sugeridas?

Este problema debe reabrirse, como mencionó @ctindel .

+1 por haber reabierto el problema

+1 para abrir también.

+1 para reapertura.

+1 para reapertura.

+1 para reapertura.

+1 para reapertura.

+1 para reapertura.

+1 para reapertura.

¿Qué pasa con un volumen de solo lectura?

myservice:
    image: foo/bar
    volume:
        - src:dest:ro

@michaelarnauts ven esto .

👍 para reabrir

+1 para reapertura.

+1 para reapertura.

+1 por reapertura

+1 por reapertura

+1 por reapertura

+1 por reapertura

+1 por reapertura

+1 por reapertura

Aquí está mi razón fundamental para permitir una copia en Redactar.

Tengo una aplicación que se ejecuta en numerosos contenedores. Por el bien del argumento, estipulemos que todos ejecutan Apache. Todos tienen definiciones de DocumentRoot que apuntan a cosas como "/ var / www / partX". El Dockerfile no sabe nada sobre el contenido de la configuración de Apache, y Compose define la referencia de volumen para / var / www / partX. Esto funciona muy bien para el desarrollo, porque puedo depurar y modificar el código sin modificar el contenido del contenedor.

El problema es cuando quiero desplegar. Uno de los principales atractivos de Docker es que puedo implementar un contenedor que es su propio universo. Para obtener todo en el contenedor, tengo que copiar los archivos, lo que significa que tendría que tener definiciones Dockerfile y Compose separadas de las que uso para el desarrollo. En un proyecto grande, esto significa que tengo que mantener dos conjuntos de archivos de definición, lo que introduce más posibilidades de errores.

Mi preferencia sería mantener un solo conjunto de Dockerfiles y hacer la orquestación en el archivo Compose. Redactar sería donde defino si voy a configurar / var / www / partX como un volumen compartido o si estoy copiando archivos en el contenedor.

La implementación con volúmenes compartidos parece una lata de gusanos. Si actualizo una versión existente en producción que depende de un volumen compartido, no puedo actualizar ese volumen compartido sin configurar una ventana de mantenimiento o sin crear un esquema para versionar mi volumen compartido. Estoy acoplando estrechamente contenedores con archivos externos, y si estoy introduciendo ese tipo de complejidad, estoy negando algunos de los beneficios de usar Docker.

Parece que podría realizar cambios en el script de las definiciones de Dockerfile para copiar archivos de forma condicional, pero parece más "lógico" manejar toda la lógica de Docker en el universo de Docker, y Compose parece un lugar lógico para hacerlo.

+1 para reapertura.

+1. Sería muy útil copiar un archivo de configuración en docker-compose.yml archivo en lugar de Dockerfile .

+1. Simplemente lo encontré tratando de proporcionar un archivo de configuración para el servicio. El volumen de solo lectura parece una opción, pero preferiría copiarlo.

Simplemente montar un volumen podría hacer el truco:

version: '2'
services:
  foobar:
    image: 'postgres:9.6-alpine'
    volumes:
      - './docker/schemas/foobar:/docker-entrypoint-initdb.d'

@raszi - Yah, la configuración montada es la dirección en la que vamos a ir por ahora. Sin embargo, una de las cosas que realmente me gustó de Docker fue la noción de un contenedor autónomo en el que podía ejecutar pruebas de integración, sin preocuparme por las dependencias externas (como la configuración vinculada). Si estoy haciendo implementaciones azul / verde o A / B, y hay diferencias en las configuraciones utilizadas por las diferentes versiones de contenedores, las cosas pueden ponerse un poco frágiles. Puedo evitar esto haciendo cosas como versionar archivos de configuración en un volumen compartido de cada uno de mis entornos, pero parece más complejo o frágil de lo que podría ser.

"Los contenedores Docker envuelven una pieza de software en un sistema de archivos completo que contiene todo lo necesario para ejecutarse: código, tiempo de ejecución, herramientas del sistema, bibliotecas del sistema, todo lo que se pueda instalar en un servidor. Esto garantiza que el software siempre se ejecutará de la misma manera, independientemente de su entorno ". Para mí, eso idealmente incluiría la configuración. Compose es una especie de "compilar / compilar y ejecutar", creo que algunos de nosotros aquí estamos deseando que Compose pueda hacer "compilar / compilar, vincular y ejecutar". No es como funciona hoy y puedo entender la falta de entusiasmo por ir por ese camino, pero bueno, es un foro, no está de más preguntar;)

Estoy de acuerdo, sería genial tener esta función. Acabo de publicar mi solución para ayudar a otros.

+1 para reapertura.

+1

+1 para reapertura o solución diferente sin volúmenes.

Actualmente se utilizan variables de entorno en docker-compose.yml y j2 en docker-entrypoint.sh para analizarlas en archivos de configuración antes de ejecutar la aplicación principal del contenedor. Funciona para mí, aunque es una imagen personalizada y no se puede usar de inmediato con imágenes completas ya disponibles.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 por reapertura

Para agregar la posibilidad de tener un archivo yaml diferente para cada contenedor en lugar de una configuración basada en variables de entorno

+1 característica muy necesaria

+1, ¡es bueno tener una función!

+1

+1

+1

+1

+1 reapertura. Marcado como favorito

+1 esta es una característica muy necesaria.

Si hubiera alguna forma de marcar un volumen compartido como una capa, de modo que el volumen permaneciera RO pero las escrituras se aplicaran a una capa superior, viviría felizmente sin una directiva copy . Me gustaría compartir, por ejemplo, un artefacto de compilación extraído, pero el servicio escribe en ese directorio (registros o archivo PID, etc.).

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 para reabrir ya que sería una característica muy útil

Quizás la función de plantilla de https://github.com/jwilder/dockerize pueda ayudar a algunos de ustedes

+1

+1

+1

+1

+1

+1 para reabrir el problema

+1

Use los secretos de la ventana acoplable, en este ejemplo, los secretos se usan con la imagen nginx para copiar el certificado del servidor y el archivo de configuración
https://docs.docker.com/engine/swarm/secrets/#intermediate -example-use-secrets-with-a-nginx-service

Ese es un buen punto. Honestamente, parece que dado que ya tenemos secretos, deberíamos tener una copia, ya que los secretos son, en cierto modo, solo un tipo específico de archivo que copiarías. Es decir, uno que se aprovisiona con más cuidado, que no necesitamos para los archivos de configuración.

Es mejor que el host montar un volumen para cada archivo de configuración que desee incluir.

Como se dijo antes:

...
volúmenes:
- ./nginx/default.conf:/etc/nginx/conf.d/default. conf: ro
- ./nginx/nginx.conf:/etc/nginx/nginx. conf: ro
...

La razón por la que copiar es mejor: a) en entornos de enjambre, donde los hosts son de hecho máquinas separadas, no debería tener exactamente el mismo archivo en el mismo lugar en cada máquina. b) La copia también se puede restringir a la carpeta en la que se encuentra la composición, mientras que un montaje de host requiere una ruta absoluta. c) Creo que el objetivo de la ventana acoplable es minimizar el número de lugares en los que la aplicación contenida irrumpe en el host. Los montajes de host, incluso cuando están configurados como de solo lectura, crean una responsabilidad en el host de tener y conservar archivos. No deberíamos tener que usar montajes de host para resolver este simple problema.

Creo que la copia podría modelarse de manera similar al proceso docker build , donde el Dockerfile generalmente se envía en un repositorio de git, junto con todos los archivos que necesita enviar al contexto de compilación. El Dockerfile no tiene permitido enviar nada que exista fuera de su estructura de directorio, incluso si tiene un enlace simbólico correcto. Podríamos tener algo similar con compose, donde src está restringido al directorio (y los siguientes) de docker-compose.yml . Básicamente, el flujo de trabajo sería, docker-compose crea el contenedor, y luego, por cada src:dst par, busque src en el directorio actual y cópielo en el contenedor sin iniciar, luego inicie el contenedor.

Actualmente, se pueden evitar los montajes de host agregando Dockerfiles adicionales y construyendo los archivos conf en imágenes enmendadas, pero esto me parece excesivo, ya que implica volver a etiquetar una nueva imagen o forzar a los usuarios para usar el atributo docker-compose build lugar del atributo más preferible (IMO) image . Si ya está utilizando el atributo build en la definición de su servicio, y desea hacer las cosas de esta manera, se verá obligado a contaminar su generador de imágenes, que de otro modo sería agnóstico, con un archivo de configuración muy obstinado que debería pertenecer a compose y el proceso de implementación.

+1 para la función de copia de docker-compose

+1

+1

+1

+1 para copiar.

+1 para la función de copia de docker-compose. Creo que los argumentos a favor anteriores son convincentes.

+1 para copiar

+1 para copiar.

Aunque en mi POV. Puede resultar útil, pero también puede perder el control o abusar de muchos usuarios e incluso hacer que el volumen quede obsoleto. Si solo necesita que los archivos se coloquen en el contenedor, especialmente para swarm, entonces puede usar configs o secrets; Pero para mi caso, como poner carpetas estáticas en un contenedor nginx, tengo que usar compilaciones de múltiples etapas en mi Dockerfile para colocar esas carpetas estáticas en el contenedor, lo que requiere mucho proceso antes de que se logre mi objetivo. Entonces creo que agregar una opción de copia podría ser muy útil

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 por reapertura

+1

+1 por reapertura

¿No funcionaría una característica que opera en un volumen después de que el contenedor (o él mismo) alcance cierto estado?
Podría ser una bandera como readonly, pero copyonly en

+1 para reapertura. El montaje de volumen no siempre es una opción. Por eso publico aquí hoy. Necesito modificar una gran cantidad de contenedores a mano para copiar archivos debido a un escenario único donde el montaje de volumen está prohibido.

+!

+1

+1 para la función de copia de docker-compose

+1

+1

Empiezo a pensar que esto no tiene sentido. Docker solo agrega características en torno al caso de uso particular para el que la construyeron; esta es una de las características fuera de su caso de uso, por lo que probablemente nunca la agregarán.

+1

@stuaxo El hecho de que mucha gente esté pidiendo pistolas no significa que debamos implementarlas automáticamente.

En este caso, los archivos que un servicio requiere para ejecutarse deben integrarse en la compilación (declarados en Dockerfile), estar disponibles a través de volúmenes o (en el caso de docker stack / modo Swarm) existir como config u objetos secretos. Copiar archivos en destinos potencialmente múltiples en tiempo de ejecución es lento, propenso a errores y no resistente a fallas.

Saludos, disculpas si eso pareció gruñón.
Cuando dice "ejecutar un servicio", supongo que se refiere a algo de larga duración como un servicio web, Docker lo tiene bien cubierto.

Los acopladores de capas y el almacenamiento en caché son útiles para otras cosas;

Pongo mi antiguo blog de WordPress en la ventana acoplable, pero solo lo ejecuto a veces durante unos minutos para poder exportar datos o verificar cómo se ve una publicación allí.

Esto requirió un poco de trabajo para usar docker compose para separar MySQL y Apache, pero no me importaría si todos estuvieran juntos.

El almacenamiento en caché de Dockers es divertido cuando se experimenta con la creación de bibliotecas de escritorio como Cairo. He olvidado los detalles de la mayoría de las cosas que estaba tratando de hacer, pero están más en el lado de la construcción, que en algo relacionado con los servicios en ejecución.

Se debe agregar una copia de composición de Docker +1. Permite un flujo mucho más sencillo de archivos de configuración y actualizaciones de contenedores.

Utilice docker cp y docker config

El viernes 2 de marzo de 2018 a las 21:19, James Hahn [email protected] escribió:

Se debe agregar una copia de composición de Docker +1. Permite un flujo mucho más fácil
de archivos de configuración y actualizaciones de contenedores.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/compose/issues/1664#issuecomment-370055493 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABOv-q5VO9n9HDvBP6YJ1BCePz5tGu-pks5tabdrgaJpZM4FTTPg
.

>

James Mills / prológico

E: [email protected]
W: prologic.shortcircuit.net.au

+1 para copia de composición de Docker. La idea es tener solo copia para los archivos como se describe aquí

+1

+1

En este caso, los archivos que un servicio requiere para ejecutarse deben integrarse en la compilación (declarados en Dockerfile), estar disponibles a través de volúmenes o (en el caso del modo Docker stack / Swarm) existir como objetos de configuración o secretos. Copiar archivos en destinos potencialmente múltiples en tiempo de ejecución es lento, propenso a errores y no resistente a fallas.

Excepto que en muchos casos todo lo que desea es actualizar un solo archivo de configuración, en cuyo caso crear su propia imagen de una imagen oficial estándar es una mala práctica y genera una gran deuda técnica para el futuro, los volúmenes son exagerados X10 y usted no desea o necesita que los archivos se sigan sincronizando, sin mencionar los problemas de tener que lidiar con toda la carpeta y no solo con un solo archivo en una ubicación predeterminada, y necesita actualizar un archivo del sistema

Entiendo sus preocupaciones, pero decirles a todos que sus necesidades no son reales solo alejará a las personas de su proyecto y de la comunidad que quiere usarlo y apoyar su trabajo. Queremos trabajar con usted aquí para encontrar una solución que funcione, pero todo lo que quiere decir es que no necesitamos lo que creemos que necesitamos.

Wow, no puedo creer que esto no se haya hecho todavía. Pensé que esta funcionalidad básica ya estaría en docker-compose. Oh, la belleza de los proyectos OSS ...

Resuelto con docker-compose --force-recreate --rebuild , copia los archivos nuevos si han cambiado (o eso parece). No es ideal, pero funciona.

+1

+1

+1

+1

+1 esto es de bajo perfil que me vuelve loco, parece una tontería tener que montar un volumen solo para un archivo de configuración.

+1

Tenemos una forma de agregar archivos a un contenedor mediante la ventana acoplable componer con volúmenes. Me di cuenta de que la documentación de Compose tiene una configuración configs ahora, por lo que también podemos agregar archivos individuales.

https://docs.docker.com/compose/compose-file/#configs

Sin embargo, lo que creo que la gente quiere es una forma de fusionar archivos del host en un directorio en el contenedor, siendo la preferencia overwrite if exists , la forma en que esperaría que funcione una copia.

Me resulta extraño que la configuración volumes en el archivo de redacción tenga una opción nocopy :

https://docs.docker.com/compose/compose-file/#volumes

volumes:
  - type: volume
  source: mydata
  target: /data
  volume:
    nocopy: true

Que se describe así:
volume: configure additional volume options
nocopy: flag to disable copying of data from a container when a volume is created

Entonces, ¿desactiva exactamente lo que se desea?

Mi caso de uso deseado son las aplicaciones web para el desarrollo. Quiero que la imagen contenga todo lo que necesita para servir un sitio web, incluido un sitio web predeterminado para servir, pero tengo la opción de fusionar / sobrescribir esos archivos con el estado de trabajo actual de un sitio web sin otra configuración (la clave) más allá de tener los archivos en el lugar correcto en el anfitrión. Archivos que, cuando se copian en el contenedor, son efímeros. Es decir, no en una red compartida.

Un ejemplo de un marco que se beneficiaría de eso es algo como Laravel. Donde hago una imagen que será capaz de servir a la página de inicio de Laravel sin otra configuración (volúmenes, recursos compartidos de red, etc.), pero el archivo de composición se escribe para copiar archivos desde el host a la raíz de Laravel del contenedor para que puedan ser sobrescrito.

El uso de un recurso compartido de red para esto es un mantenimiento adicional para un entorno efímero (el desarrollo no siempre es constante). Usar un montaje de volumen para ello, con un marco como Laravel, requiere construir la aplicación en ese volumen, lo que significa instalar PHP y el compositor en el host o compartir la ubicación en el host en el que se crearía la aplicación. Ambos crean más mantenimiento.

Editar:

Después de la prueba, parece que cuando monta un volumen, los archivos que existían en la imagen en esa ubicación se copian en el volumen persistente con preferencia al contenido original del volumen. Lo que significa que no sobrescribe.

De hecho, creo que esta es una solución para el resultado deseado.

Hola, chicos, solo para su información, es mejor dar una reacción de pulgar hacia arriba al mensaje principal sobre este tema que agregar un comentario "+1", ya que los problemas se pueden ordenar por la cantidad de reacciones que han recibido.

+1

+1 Por favor, equipo de Docker, considere su comunidad.

@ shin- El problema en este momento es que la función de volúmenes hace que sea imposible conectar un solo archivo de configuración desde un volumen externo a un contenedor.

Supongamos que quiero conectar un archivo de configuración nginx en /etc/something/whatever.conf sin aniquilar todo lo demás que está en esa carpeta. No puede crear un volumen con nombre para un solo archivo (consulte moby / moby # 30310), y tampoco puede crear un volumen de directorio que contenga un solo archivo, luego montar ese archivo en particular en el contenedor (ver moby / moby # 32582).

La única opción que le queda es contaminar ubicaciones fijas en su host Docker real con los archivos de configuración y luego enlazar montarlos. Esto, por supuesto, se desmorona si desea moverse entre hosts Docker o trabajar con un Docker host al que no tiene acceso al sistema de archivos (por ejemplo, CI en línea), o incluso simplemente ejecuta múltiples pilas en paralelo.

Algo tiene que ceder aquí, o la función de volúmenes en Docker debe cambiar para que podamos usarla para lograr inyectar archivos de configuración en nuestra pila, o tenemos que solucionarlo en la composición usando algo como copy config opción.

FWIW Ya no soy un mantenedor de Compose, pero me parece que ese caso de uso se serviría mejor inyectando el archivo de configuración en el momento de la compilación usando un Dockerfile.

@ shin- Desafortunadamente, los archivos de configuración no se conocen en el momento de la compilación, las imágenes se preparan en un servidor de CI mucho antes de que sepamos dónde vamos a implementarlas y en qué configuración.

Estoy con @masaeedu , entiendo el ideal conceptual de evitar que la función de

A) tener que improvisar algún tipo de trabajo de escritura horrible para levantar los contenedores en cuestión (la misma cosa que componer estaba destinada a ayudar a estandarizar y evitar que tengamos que hacer),

B) tener que agregar alguna otra herramienta que maneje toda nuestra configuración (que si bien es factible agrega una gran cantidad de gastos generales para proyectos pequeños y medianos que realmente solo necesitan copiar un .conf y .env específico a cada contenedor, algo que no desea hacer en el momento de la creación de la imagen, eso equivale a decir que en lugar de que su software tenga un archivo de configuración, debe codificar todas sus opciones en C ++, esto conduce a docenas de imágenes adicionales que debe mantener), o

C) tener que mantener una imagen separada para cada configuración posible de un software dado que alguna vez necesitaremos / crear una imagen personalizada cada vez que tengamos que hacer un cambio de configuración menor ... lo cual es inviable en el mundo real del software de producción, y también hace que sea imposible tener el tipo de control de calidad robusto y la canalización de pruebas que necesitamos para el software de producción.