Solo estaba investigando esto

Uso: compilación de docker [OPCIONES] RUTA | URL | -

así que si corres

docker build -t my / thing my-dockerfile

se queja de que el archivo tar es demasiado corto.

Me parece que la opción 'PATH' no está documentada, por lo que podría tener algún significado heredado.

Entonces, me pregunto si detectar si PATH es un archivo y no es un Tarfile.

personalmente, tengo un conjunto de Dockerfiles que uso para probar, y preferiría tenerlos todos en un directorio y también tener un contexto completo.

Ese PATH se refiere a un directorio, no a un Dockerfile específico.

oh, y luego Tars ese directorio para enviarlo al servidor - ¡genial!

por lo que es posible detectar isafile, subir el directorio en el que se encuentra y luego reemplazar el Dockerfile en ese tarball con el archivo especificado.

o usar -f de la misma manera, permitiendo que sus definiciones de Dockerfile vivan por separado de la carga útil

ahora para averiguar cómo funcionan las pruebas, pruébelo y vea si funciona para mí

No alquila nada: la RUTA es un directorio en el que se supone que hay un Dockerfile

eso no es todo lo que hace con esa RUTA - leyendo el código, el 'contexto' se envía al servidor tarando el directorio.

(ok, todavía no sé ir, y solo he estado leyendo el código durante los últimos minutos, así que tómatelo con un poco de escepticismo)

Correcto, por lo que todos los archivos no remotos a los que se hace referencia a través de ADD también deben estar en ese mismo directorio o el demonio no podrá acceder a ellos.

Ah, veo lo que está diciendo, sí, eso es exactamente lo que quiero, una forma de especificar un archivo docker con -f, y luego el directorio PATH que podría estar separado.

para que yo pudiera tener:

docker build -t my/thing fooproj
docker build -t my/thing -f debug-dockerfile fooproj

2108 (agregar una directiva de inclusión a Dockerfiles) agrega una arruga interesante

si el include es relativo al dockerfile especificado, o al PATH. aunque no es importante todavía.

divertida:

docker build -t my/thing fooproj
docker build -t my/thing -f ../../debug-dockerfile fooproj
docker build -t my/thing -f /opt/someproject/dockerfiles/debug-dockerfile fooproj

como bonificación adicional, todavía no hay pruebas de CmdBuild, así que adivinen qué aprenderé primero :)

@SvenDowideit ¿estás trabajando en esto? Estaba pensando en piratearlo hoy

Poco a poco me estoy familiarizando con el código y listo, así que adelante, me estoy divirtiendo demasiado escribiendo las pruebas unitarias (tal vez puedas usar las confirmaciones de prueba para ayudar :)

Voy a hacer :)

También me gustaría ver esta funcionalidad. Tenemos un sistema que puede ejecutarse en 3 modos diferentes y nos gustaría implementar 3 contenedores diferentes, 1 para cada modo. Eso significa 3 archivos de ventana acoplable prácticamente idénticos, siendo solo el CMD diferente. Pero debido a que las rutas solo son directorios, y los directorios son el contexto para los comandos ADD, no puedo hacer que esto funcione en este momento.

Entonces: ¡+1 de mí!

Parece que esto puede tener el mismo objetivo final que el # 1618 (aunque con diferentes enfoques). La idea es usar un solo Dockerfile con múltiples instrucciones TAG que resulten en múltiples imágenes, versus múltiples Dockerfiles y un sistema de inclusión como se describe aquí. ¿Pensamientos?

Parece que si puede canalizar un Dockerfile, también debería poder especificar una ruta. Interesado en ver lo que viene del # 1618 pero creo que esto ofrece muchas más posibilidades.

Aquí es donde estoy: https://github.com/peterbraden/docker/compare/2112-specify-dockerfile?expand=1

Me sorprendió el hecho de que la documentación no indica claramente que el directorio que contiene el Dockerfile es el contexto de compilación; asumí erróneamente que el contexto de compilación era el directorio de trabajo actual, así que si pasé una ruta al Docerfile en su lugar de estar en el directorio actual, los archivos que traté de AGREGAR desde el directorio de trabajo actual fallaron con errores de "no hay tal archivo o directorio".

Recibo el mismo error, cualquier idea

docker build Dockerfile

Subiendo contexto

2013/12/11 21:52:32 Error: Error de compilación: Tarball demasiado corto

@bscott prueba docker build . lugar. La compilación toma un directorio, no un archivo, y ese es el "contexto de compilación". :)

Funcionó Thx !, solo me gustaría elegir entre diferentes archivos Docker.

+1 de mi parte.

Necesito crear varias imágenes de mi fuente. Cada imagen es una preocupación separada que necesita el mismo contexto para construirse. Contaminar un solo Dockerfile (como se sugiere en el n. ° 1618) es complicado. Sería mucho más limpio para mí mantener 3 archivos <image-name>.docker separados en mi fuente.

Me encantaría ver implementado algo como esto.

Esto es más difícil de implementar de lo que parece a primera vista. Parece que ./Dockerfile está bastante integrado. Después de la investigación inicial, al menos estos archivos están involucrados:

api/client.go
archive/archive.go
buildfile.go
server.go

El client usa archive para tar build context y enviarlo al server que luego usa archive para untar build context y entregar los bytes a buildfile .

La implementación más sencilla parece implicar cambiar client y archive para sobrescribir el ./Dockerfile del tar con el archivo especificado a través de esta opción. Investigaré más.

@thedeeno Echaré un vistazo muy rápido y te mostraré dónde se debe hacer el cambio. Creo que está solo en un lugar.

+1 de mi parte!

He estado siguiendo tanto el # 1618 como el # 2112 y esta es la solución más elegante.

Hay un caso de uso particular en mi desarrollo en el que esta característica sería increíblemente útil ... Cuando se trabaja en aplicaciones que tienen roles tanto de "web" como de "trabajador". Me gustaría crear dos archivos de ventana acoplable para esta situación "Dockerfile-web" y "Dockerfile-worker". Luego podría construirlos a ambos, etiquetarlos y enviarlos a mi repositorio de imágenes. Luego, ejecutaría varias instancias de front-end web detrás de un equilibrador de carga y varios trabajadores para manejar las tareas que se envían a las colas.

+1 como alternativa a # 2745.

+1

Me asombró descubrir que Dockerfile está codificado, así como que el contexto de compilación se ve obligado a ser el directorio de Dockerfile y no se puede anular incluso con indicadores de línea de comandos. Esto limita gravemente la utilidad y la flexibilidad de Docker como herramienta de desarrollo, prueba e implementación.

+1
Apreciaría ese cambio

+1
Realmente necesito esto.

5033 debería permitir esta función. cc / @ crosbymichael

@shykes ¿qué opinas de este cambio? No creo que esté de acuerdo o tal vez conozca una mejor solución para resolver el mismo problema.

Estoy indeciso.

Por un lado, no quiero limitar la capacidad de las personas para personalizar su construcción.

Por otro lado, me preocupa que suceda lo mismo que con _run -v / host: / container_ y _expose 80: 80_. En otras palabras, permitirá que el 1% que sabe lo que está haciendo agregue una personalización genial, y el otro 99% se pegará un tiro en el pie bastante mal.

Por ejemplo, tenemos muchos usuarios nuevos de Docker que comienzan con volúmenes montados en el host en lugar de volúmenes normales. Y tuvimos que desaprobar la sintaxis _expose 80: 80_ por completo porque demasiadas personas publicaron imágenes que no podían ejecutarse más de una vez por host, sin una buena razón.

Entonces mi pregunta es: ¿no nos arriesgamos a tener muchos repositorios de origen que no se pueden construir repetidamente con _docker build

@shykes Me estoy encontrando con el problema que describe _porque_ esta limitación de Dockerfile. A continuación, se muestran algunos casos de uso:

1. Tengo un entorno de compilación basado en Docker que produce un artefacto (archivo JAR en este caso). El entorno de compilación es diferente del entorno de ejecución (diferentes dependencias, imagen más grande, etc., por lo que no quiero heredar el entorno de compilación en tiempo de ejecución. Para mí tiene más sentido tener la compilación Dockerfile y ejecutar el entorno de ejecución alrededor del JAR. Así que tengo un archivo Dockerfile.build separado que compila y ejecuta el entorno de compilación y crea el JAR. Pero, como no puedo especificar el Dockerfile, tuve que crear un archivo scripts/build archivo que hace un docker build < Dockerfile.build y luego monta el volumen de host con docker run -v ... para ejecutar la compilación (ya que no puedo usar ADD con Dockerfiles canalizados). En su lugar, me gustaría poder ejecutar docker build -t foobar/builder -f Dockerfile.build , docker run foobar/builder , docker build -t foobar/runtime , docker run foobar/runtime y simplemente usar los comandos ADD en ambos Dockerfiles.
2. Con las instrucciones de ONBUILD, me gustaría poder poner Dockerfiles en subdirectorios (o tener archivos Dockerfile.env, etc. en la raíz) que tienen la raíz Dockerfile en su instrucción FROM, pero aún pueden usar la raíz del proyecto como su contexto de construcción. Esto es útil, por ejemplo, para incorporar parámetros de configuración para diferentes entornos. El Dockerfile raíz aún produciría un contenedor útil, pero los otros crearían diferentes variantes que necesitamos.

Así que supongo que lo que realmente me gustaría es poder separar los conceptos de "contexto de compilación" de "ubicación / nombre de Dockerfile". Hay muchas formas posibles de hacerlo, por supuesto, pero me parece relativamente sencilla.

@ cap10morgan ¿Alguna posibilidad de que pueda señalarme su ejemplo 1, o algo que se aproxime a él? Así que puedo jugar y asegurarme de que estamos hablando de lo mismo.

@shykes https://github.com/shykes no es este sueño de portabilidad exactamente
¿Para qué sirve el índice de imágenes? ¿Por qué los entornos de construcción deben ser
portátil también?

Algunos procesos de construcción requieren más de lo que es posible con vainilla
Dockerfile. Además, la aplicación de un Dockerfile por contexto (que es lo que
esta solicitud pretende corregir) es muy limitante.

Esto realmente afecta a nuestro equipo. En nuestra configuración, nos gustaría producir múltiples
imágenes del mismo "contexto". Al agregar la opción --file podemos hacer
lo que realmente queremos hacer, que es agregar foo.docker y bar.docker
en la raíz de nuestro repositorio. En cambio, terminamos escribiendo scripts bash para copiar
toneladas de archivos en ubicaciones temporales para establecer un contexto y cambiar el nombre de nuestro
archivos acoplables con nombre en la magia Dockerfile para que docker build pueda
trabaja.

Para mí, estos aros existen sin una buena razón. Si alguien de nuestro equipo quiere
para crear nuestras imágenes, necesitan ejecutar scripts personalizados para hacer el trabajo -
exactamente lo que cree que puede evitar si se ciñe a esta limitación.

El lunes 7 de abril de 2014 a las 4:23 p.m., Solomon Hykes [email protected] escribió:

@ cap10morgan https://github.com/cap10morgan cualquier posibilidad que puedas señalar
yo a su ejemplo 1, o algo que se aproxime a él? Para que pueda jugar
y asegúrese de que estamos hablando de lo mismo.

Responda a este correo electrónico directamente o véalo en Gi
.

@shykes, dado que parece que esto no se está solucionando, ¿puede señalar los documentos o una explicación de la forma certificada de Docker para tratar este problema?

Mi caso de uso es que tengo una aplicación que me gustaría construir con Docker donde las pruebas tienen requisitos diferentes a los de una imagen de producción. Creo que esto es bastante común.

Este y el problema .dockerignore (https://github.com/dotcloud/docker/pull/3452) (copiando todo mi directorio .git en el contexto de compilación) son los primeros puntos críticos algo críticos que encuentro al probar Docker para uno de nuestros proyectos en los últimos días y no me parece una idea genial, pero parece haber un retroceso en estos temas.

+1 en la necesidad de esto también: tenemos una única base de código con múltiples microservicios que se están desarrollando allí. Nos gustaría poder generar múltiples imágenes, por ejemplo, una imagen que contenga services / base / * y services / fooservice / *; y otra imagen que contiene services / base / * y services / barservices / * y también staticfiles / *.
No podemos colocar Dockerfiles dentro de la carpeta de servicio porque Docker trata esa carpeta como un contexto y no podemos AGREGAR nada que esté más arriba en la estructura de carpetas. No podemos colocar dos Dockerfiles en root porque tendrían el mismo nombre.
La única solución que tenemos es colocar el Dockerfile en la carpeta de servicio y luego escribir un script personalizado para analizar el Dockerfile seleccionado, determinar qué rutas querrá agregar (todas especificadas en relación con la raíz del proyecto), luego copiarlas a una nueva carpeta temporal, copie el Dockerfile seleccionado a la raíz de esa nueva carpeta y finalmente ejecute "docker build tempfolder". ¿Es eso realmente necesario?
Habría sido mucho más sencillo si pudiera simplemente decirle a "docker build" por separado dónde está el Dockerfile y dónde está el contexto.

Al encontrarme con este problema también ... me encantaría ver algún tipo de solución.

+1, codificar alrededor de esta limitación es un gran dolor.

+1 para el indicador -f que especifica la ruta de Dockerfile separada del contexto de compilación

Docker es una gran herramienta, pero esta estrecha combinación de contexto y Dockerfile específico definitivamente contamina un poco al equipo de Docker. La estructura del directorio no siempre refleja exactamente la estructura del 'contenedor / subsistema'.

¿Qué tan difícil puede ser arreglarlo? Y ha habido algunas relaciones públicas para esto, pero se han ignorado.

Una adición simple relacionada es tener un archivo de ignorar para las cosas que no queremos agregar al contexto; sí, te estoy mirando, .git ...

En realidad, esto podría llevarme a omitir Docker por ahora y volver a Vagrant + Ansible. Bonito.

@davber .dockerignore está en -> # 6579

Pero, sí, la gestión de contribuciones es un poco dolorosa en este momento y una de las raras cosas desalentadoras sobre Docker hasta ahora. Creo que están un poco abrumados, con suerte.

Equipo de Docker, ¿cómo pueden las personas hacer que se revisen y se incluyan cosas como esta? Si hay una idea clara sobre por qué esto es realmente malo y cómo los proyectos deben evitar este problema, nos encantaría escucharlo, pero esto parece un problema simple de describir y un problema simple de resolver.

/ cc @shykes @creack @crosbymichael @vieux

+1 para la bandera -f. También una variable de entorno DOCKERFILE para anular la configuración de compilación.

@jakehow sí, definitivamente hay un elemento de estar abrumado, por cada mantenedor hay al menos 1,000 personas que solicitan activamente algo y exigen una explicación detallada de por qué aún no se ha hecho. Realmente estamos haciendo nuestro mejor esfuerzo, y si visita los canales irc #docker y # docker-dev, será testigo de la manguera de incendios de primera mano.

Pero en este caso ha habido una respuesta clara de por qué es mejor mantener el mapeo 1-1 de Dockerfile y el directorio de origen. Lo repetiré una vez más: queremos preservar la propiedad de autodescripción de las compilaciones de Docker. El hecho de que pueda apuntar a un directorio de código fuente, _sin otra información fuera de banda_, y construir una imagen a partir de él exactamente según la especificación del desarrollador original, es muy poderoso y un diferenciador clave de Docker.

Claro, poder combinar dinámicamente el directorio X con Dockerfile Y sobre la marcha es algo conveniente (aunque nunca sentí una necesidad urgente de hacerlo y uso mucho Docker). Pero hace que sea demasiado fácil hacer algo estúpido, es decir, romper la naturaleza autodescriptiva de tu construcción. Y eso parece una compensación enormemente pobre. De ahí la decisión de no implementar esta característica.

En cuanto a los ejemplos de "1 repositorio de origen, varias imágenes", sí, definitivamente estoy de acuerdo en que es necesario. Lo que necesitamos es una forma estándar de Docker para que un directorio de origen único defina múltiples objetivos de compilación. Eso podría hacerse con un Dockerfile de varias partes, o con varios Dockerfiles _ siempre que haya una convención de nombre de archivo bien definida que permita que estos Dockerfiles se enumeren y seleccionen de una manera no ambigua_.

Si alguien quiere contribuir con esto, nos encantaría fusionarlo. Y, como de costumbre, estaremos encantados de ayudar a los contribuyentes nuevos, ven a saludar en IRC y te ayudaremos a empezar.

@davber Tenía la impresión de que Vagrant tiene la misma restricción de 1 archivo de descripción por proyecto (presumiblemente por razones similares). ¿Cómo se resolverá exactamente tu problema volver a Vagrant?

@gabrtv , ¿quieres intentar recuperar varias imágenes? Aquí hay una propuesta tentativa:

$ ls | grep Dockerfile
Dockerfile
db.Dockerfile
frontend-prod.Dockerfile
frontend-dev.Dockerfile
$ docker build -t shykes/myapp .
Successfully built shykes/myapp/db
Successfully built shykes/myapp/frontend-dev
Successfully built shykes/myapp/frontend-prod
Successfully built shykes/myapp
$ docker build -t shykes/myapp2 --only frontend-dev .
Successfully built shykes/myapp2/frontend-dev

Esa propuesta funcionaría bien para nosotros y puedo ver que también resolverá otros problemas para otras personas.

@shykes No creo que compre que aumentar la complejidad del formato Dockerfile sea una compensación que valga la pena para mantener un Dockerfile.

Tomemos, por ejemplo, los archivos MAKE: es más común que un proyecto tenga un archivo MAKE, pero make también le permite especificar con "-f" un archivo MAKE diferente.

También creo que el mapeo 1: 1 entre la carpeta de origen y la imagen es menos útil de lo que crees: he descubierto que es común generar una carpeta de compilación y compilar desde dentro para mantener la cantidad de datos copiados en el contexto a un mínimo, y por lo tanto imágenes más pequeñas.

dices "Entonces mi pregunta es: ¿no nos arriesgamos a tener muchos repositorios de código fuente que no se pueden construir repetidamente con la compilación de Docker?"

Pero creo que este ya es el caso, algunos requisitos de proyectos significan que una sola forma de compilar no es práctica, y la sintaxis de Dockerfile no permite una gran cantidad de configurabilidad (por diseño y no quisiera que eso cambiara ...).

Tampoco me gusta particularmente la sugerencia --only. Creo que el valor predeterminado que las personas / quieren / cuando compilan es que se compile un determinado contexto, no todo: cuando ejecuto la compilación de la ventana acoplable, quiero / solo / que se ejecute Dockerfile . Pero también quiero la posibilidad de tener otra imagen que / pueda / ser construida.

Según tengo entendido, el problema aquí reside en el hecho de que cuando
canalizando un Dockerfile (cat Dockerfile | docker build -) perdemos el trabajo
directorio para ADD y CP.

Resolverá el problema agregando una marca para la compilación de la ventana acoplable que nos permita
especificar dónde reside el contenido de la carpeta de origen?

cat Dockerfile | docker build --cwd=~/my_docker_data_files -

En esta propuesta, el indicador --cwd especifica la carpeta base para ADD y CP
comandos.

2014-06-29 19:42 GMT + 10: 00 Peter Braden [email protected] :

dices "Entonces mi pregunta es: ¿no nos arriesgamos a tener muchas fuentes
repositorios que no se pueden construir repetidamente con la compilación de Docker, "

Pero creo que este ya es el caso, algunos requisitos de proyectos significan que
una forma única de compilar no es práctica, y la sintaxis de Dockerfile no
permitir una gran cantidad de configurabilidad (por diseño y no querría
que cambiar ...).

Tampoco me gusta particularmente la sugerencia --only. Creo que el predeterminado
que la gente / quiere / cuando construye es para que se construya un determinado contexto,
no todo: cuando ejecuto la compilación de la ventana acoplable, quiero / solo / el archivo Docker para
ser ejecutado. Pero también quiero la posibilidad de tener otra imagen que / pueda / ser
construido.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/dotcloud/docker/issues/2112#issuecomment -47449994.

@llonchj en realidad https://github.com/dotcloud/docker/pull/5715 resuelve eso (de alguna manera) y eso ya está fusionado para master.

@shykes definitivamente está abierto a otro PR de múltiples imágenes, aunque después de mirar el número 5715 me pregunto si este PR en particular ya es relevante.

Por comentario original de @peterbraden ...

Sería bueno poder especificar [comando redactado] para poder AGREGAR archivos, y también tener múltiples archivos docker.

Por @ cap10morgan ...

Así que supongo que lo que realmente me gustaría es poder separar los conceptos de "contexto de compilación" de "ubicación / nombre de Dockerfile".

¿No es eso exactamente lo que hace el # 5715? Como yo lo entiendo:

$ cd myapp
$ ls Dockerfile
Dockerfile
$ docker build -t gabrtv/myimage
Successfully built gabrtv/myimage
$ ls subfolder/Dockerfile
Dockerfile
$ tar -C subfolder -c . | docker build -t gabrtv/myotherimage -
Successfully built gabrtv/myotherimage

Sé que esto no resuelve las compilaciones de múltiples imágenes desde la raíz del repositorio (lo cual estoy de acuerdo que sería bueno), pero me pregunto si esta implementación / RP en particular se puede dejar de lado ahora con # 5715.

@gabrtv Me parece que el # 5715 no se ajusta al criterio de tar -C subfolder -c . | docker build -t gabrtv/myotherimage - es, para mí, extremadamente no obvio.

Además, impone restricciones molestas (si no onerosas) al desarrollador con respecto al diseño del repositorio. No se puede arreglar, pero "Ah, y tendré que reorganizar todo el repositorio" no ayudará a nadie a convencer a su jefe de que se cambie a Docker.

Personalmente, me gusta bastante la sugerencia más reciente de @shykes , con potencialmente múltiples archivos .dockerfile (¿por qué no solo .docker?), Todos construidos por defecto. Esto facilita la puesta en marcha con un comando sin importar qué, y optimiza más tarde.

Dependiendo de la implementación, se podría cargar el contexto de compilación solo una vez para esto en todas las imágenes, lo que reduciría el costo de compilar varias imágenes. Debido a que no tengo un .dockerignore, mi contexto de compilación es de varios cientos de megabytes y tengo que esperar bastante para que se cargue mi contexto, por lo que sería bueno.

@rattrayalex créeme, estoy de acuerdo con el objetivo de "tener un solo comando que siempre funcione". Hay una buena posibilidad de que termine escribiendo el código y enviando el PR. :guiño:

Mi punto es que, desde el punto de vista de la organización del proyecto, deberíamos tener esa discusión en otro lugar en lugar de en un tema extenso titulado Allow specifying of a dockerfile as a path, not piping in :

1. La mayor parte de la discusión aquí no guarda relación con @shykes nueva propuesta en https://github.com/dotcloud/docker/issues/2112#issuecomment -47448314
2. El problema subyacente original (que separa el contexto de compilación de Dockerfile) se aborda en # 5715, aunque tal vez no sea del agrado de todos

Citando a @llonchj ...

Según tengo entendido, el problema aquí reside en el hecho de que al canalizar un Dockerfile (cat Dockerfile | docker build -) perdemos el directorio de trabajo para ADD y CP.

En otras palabras, si estaba de acuerdo con docker build -t <image> -f <path-to-dockerfile> , puede usar tar -C <path-to-context> -c . | docker build -t <image> - como una solución alternativa funcionalmente equivalente hasta que podamos armar un PR para la propuesta de @shykes .

Sugiero que cerremos esto y comencemos una nueva discusión en otro lugar (¿lista de correo? ¿Nuevo número?).

Gracias a todos los que intervinieron en este tema hoy:

@shykes gracias por el razonamiento. Creo que nuestro razonamiento para querer esto (otras personas pueden intervenir) está en nuestra experiencia: cada aplicación requiere información fuera de banda para ejecutarse en un contexto elegido. Todas nuestras aplicaciones tienen más de un contexto. La forma en que se estructuró la compilación de la ventana acoplable obligó a los desarrolladores de aplicaciones a trasladar el conocimiento de esa información a la estructura de su repositorio, o hacer scripts de compilación personalizados que anularan el comportamiento de la compilación de la ventana acoplable que contienen la información.

@gabrtv Creo que casi toda la discusión aquí está relacionada específicamente con este tema, y ​​me alegra ver que finalmente se discute aquí. El título del problema y algunas de las publicaciones de 'descubrimiento' probablemente sean un poco irrelevantes, por lo que un nuevo número o relaciones públicas con un comienzo limpio que haga referencia a este probablemente sea bueno.

La propuesta del comentario de @shykes me suena como una solución, ¿se ha realizado un trabajo previo sobre esto en algún lugar que pueda ser recogido o consultado como referencia?

¿No sería mejor "Dockerfile.frontend-prod" para que todos los Dockerfiles
en un directorio, naturalmente, se ordenan juntos?

Lo siento, pero eso es una tontería. Si mi repositorio crea 100 servicios, ciertamente no quiero tener 100 Dockerfiles en la raíz. (Ejemplo: el repositorio dotCloud PAAS).

No quiero un solo Dockerfile enorme con 100 secciones, tampoco.

Quiero 100 Dockerfiles y los quiero en directorios separados.

(Y no, no puedo simplemente crear cada servicio en su propio directorio, ya que casi todos los servicios usarán código común y bibliotecas que viven _fuera_ del directorio de cada servicio).

Nuevamente, no entiendo por qué tener una bandera adicional para especificar la ruta al Dockerfile (por defecto solo Dockerfile ) es tan importante.

Además, la propuesta actual ( <imagename>.Dockerfile ) no se corresponde en absoluto con el diseño actual de las compilaciones automatizadas. Si un repositorio en cualquiera de mis sistemas de compilación se ve comprometido, el atacante podría sobrecargar todos mis repositorios ...

@jpetazzo, como la mayoría de las personas razonables, doy la bienvenida al desacuerdo, pero no me gusta que me llamen tonto. Por favor, haga un esfuerzo por presentar sus argumentos sin insultar la inteligencia de sus compañeros. Gracias.

_De nuevo, no entiendo por qué tener una bandera adicional para especificar la ruta al Dockerfile (por defecto solo Dockerfile) es tan importante. _

Hice un argumento específico arriba. Siéntase libre de leerlo y presentar un contraargumento.

Re: desorden. @gabrtv tenía la misma preocupación sobre IRC. Después de un poco de discusión, se nos ocurrió esta alternativa:

$ ls Dockerfile Dockerfiles/*
Dockerfile
Dockerfiles/frontend-prod
Dockerfiles/frontend-dev

La misma idea, pero menos archivos individuales en el repositorio raíz.

Además, la propuesta actual (.Dockerfile) no se correlaciona en absoluto con el diseño actual de las compilaciones automatizadas. Si un repositorio en cualquiera de mis sistemas de compilación se ve comprometido, el atacante podría sobrecargar todos mis repositorios ...

Bueno, ¿cómo se llaman ahora? Si tiene un repositorio llamado "abc" con solo un Dockerfile simple, entonces la imagen generada por ese archivo se llamaría "abc". Si tiene un repositorio "xyz" con "Dockerfile.abc" y "Dockerfile.zzz" en él, entonces sería conveniente que nombrara compilaciones a partir de ellas como "xyz-abc" y "xyz-zzz".

Estoy en una situación similar a la tuya también (muchos servicios, cada uno en sus propias subcarpetas con partes comunes) y la opción explícita de configurar un Dockerfile para usar en el momento de la compilación facilitaría mi pensamiento, pero luego también puedo ver cómo puedo combinar la propuesta "Dockerfile. *" con el "archivo tar como contexto" ya publicado para poder obtener lo que quiero: los archivos docker de raíz para cada servicio generarían sus imágenes de compilación (con compiladores y demás) y cuándo se ejecutan, generarían un tar de contexto con ejecutables ya compilados y un Dockerfile de producción (tomado de la carpeta del servicio) que describiría una imagen con solo las dependencias de tiempo de ejecución.

De hecho, ahora incluso estoy escribiendo esto con un único Dockerfile raíz porque mi entorno de compilación es más o menos el mismo para todos los servicios y puedo simplemente pasarle un parámetro en tiempo de ejecución para decirle qué tar de contexto de lanzamiento de servicio quiero que cree.

@shykes bueno, si llegamos tan lejos como para tener Dockerfile / *, entonces ¿por qué no ir un paso más allá y hacer que "docker build" simplemente busque archivos llamados "Dockerfile. *" en todas las subcarpetas del directorio actual, de forma recursiva y ejecutarlos todos en el contexto del directorio actual? Y mientras estamos en if, ¿proporcionamos una opción para simplemente construir uno de ellos ... como "-f"? :)

... no me gusta que te llamen tonto

No sabía que "tonto" podía parecer ofensivo; Simplemente quise decir "torpe", tal vez, y por lo tanto me disculpo por el mal uso de la palabra.

Creo que su argumento específico fue "No quiero que la gente comience a colocar Dockerfiles en lugares aleatorios y use sistemáticamente -f cuando no es estrictamente necesario". ¿Está bien? En ese caso, tiene sentido ordenar un Dockerfile en la parte superior del repositorio, enumerando los otros Dockerfiles. Si ese archivo está ausente, el constructor puede negarse a operar (o emitir una advertencia), y si solo enumera un Dockerfile, el constructor también puede emitir una advertencia. No creo que el paralelo con -v y -p sea ​​apropiado aquí.

@aigarius si ./Dockerfile.* y ./Dockerfiles/* es que se asignan a un solo espacio de nombres que podemos usar para nombrar las imágenes resultantes. Por el contrario, si tengo ./foo/Dockerfile.db y ./bar/Dockerfile.db , y yo docker build -t shykes/myapp . , ¿cuál se llama shykes/myapp/db ?

cuál se llama shykes / myapp / db?

Ninguno. En tal escenario, codificaría una ruta completa al Dockerfile en el nombre, por lo que tendría "shykes / myapp / bar / db" y "shykes / myapp / foo / db". Esto _es_ se acerca incómodamente al espacio de nombres de Java, pero dejaré que otros decidan si eso es bueno o malo.

@shykes : con respecto a Vagrant, bueno, yo, y probablemente algunos otros, uso Vagrant para algunas funciones superpuestas de Docker. Entonces, para mí, necesito estar convencido de que mis compilaciones de múltiples máquinas actuales, que hago en Vagrant, con múltiples definiciones de máquinas, no se vuelven más incómodas al usar Dockerfiles. La cuestión es que el "contexto" es mucho más flexible en Vagrant, donde puedo obtener el contexto sobre la marcha desde cualquier ubicación mediante directorios compartidos, y también lo es el idioma, así que si solo quiero construir un servicio (o máquina) Puedo establecer una variable de entorno y 'vagabundear / aprovisionarla'. Utilizo ese método a diario para crear o proporcionar algunos de los servicios en mi sistema. Y, si me irrita demasiado un Vagrantfile en crecimiento, puedo 'cargar' fácilmente un sub-Vagrantfile que describe un servicio o aspecto individual.

En cuanto a las sugerencias concretas para manejar múltiples Dockerfiles, sí, eso nos permitiría dividir nuestra lógica para servicios individuales. Excelente. Pero, a menudo quiero o necesito construir un servicio de forma aislada, por lo que todavía vuelvo a la necesidad de especificar un Dockerfile específico ...

Entonces, mis problemas aquí son dobles:

1. No obtener un archivo desordenado enorme para todos los servicios
2. Ser capaz de crear un servicio específico en ese archivo / grupo de archivos

Nuevamente, Docker es una idea y una herramienta geniales, por lo que QUIERO que personas como yo renuncien a Vagrant por cierto tipo de funcionalidades o casos de uso.

Lo siento si repito algo tratado a fondo anteriormente, pero no veo cómo cualquier solución es mejor que admitir una opción '-f'. Es decir, problemas de implementación de módulo debido a una dependencia profundamente arraigada en el Dockerfile que reside en la raíz de contexto, no veo ninguna desventaja con él.

Con una opción '-f', definitivamente se podrían estructurar los subdirectorios y los sub Dockerfiles como se desee, como los Dockerfiles / enfoques anteriores. Sí, entonces se necesitaría un basher simple de una línea para imitar el comportamiento exacto ...

Parece haber tensión entre compartir y flexibilidad.

Si compartir es la característica más importante, entonces sí, un dockerfile estándar
tiene sentido.

No creo que compartir sea la característica más importante. Se logra compartir
a través de imágenes.

Además, usamos Docker en proyectos que NO se pueden compartir explícitamente. En
En estos casos la flexibilidad es mucho más valiosa para nosotros. Suena como muchos en
el hilo cualquiera está en esta misma posición.

La opción -f intencionada nos da la flexibilidad que necesitamos. Por otro lado,
ser capaz de especificar una ruta absoluta para el contexto de compilación también
trabaja.
El 3 de julio de 2014 a las 6:00 p.m., "David Bergman" [email protected] escribió:

Lo siento si repito algo tratado a fondo anteriormente, pero no veo
cómo cualquier solución es mejor que admitir una opción '-f'. Es decir, modulo
problemas de implementación debido a una dependencia profundamente arraigada en el
Dockerfile que reside en la raíz de contexto, no veo ninguna desventaja con
eso.

Con una opción '-f', definitivamente se podrían estructurar los subdirectorios
y sub Dockerfiles como uno quiera, como los Dockerfiles /
enfoques anteriores. Sí, entonces se necesitaría un basher simple de una línea para
imitar el comportamiento exacto ...

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/dotcloud/docker/issues/2112#issuecomment -47989616.

Estuve de acuerdo en que -f proporciona la mayor flexibilidad con una "sorpresa" mínima (yo personalmente asumí que existía una bandera de este tipo y la probé antes de llegar a este hilo).
Agregar un -c , ya sea de un directorio o un tar, para proporcionar el contexto también parece una excelente adición. Esto eliminaría la constante cd s de los procesos de construcción grandes, por ejemplo; en empresas.

Además, un archivo README que contiene instrucciones para docker build -f foo/bar/Dockerfile -c foo/ simplemente no me parece desagradable.
También acordó que docker build podría buscar fácilmente Dockerfile s. De esta forma, un repositorio estructurado como tal:

-- README
-- foo/
---- Dockerfile
---- etc
-- bar/
---- Dockerfile
---- etc
---- subbar/
------ Dockerfile
-- context/
---- etc

evitaría cualquier posible conflicto de nombres ( repo/bar/subbar ), sería fácil de razonar la cantidad y debería tener sentido en muchos contextos de desarrollo. Permitiría un uso fácil tanto de docker build , que construiría muchos contextos, como de docker build -f , que podría dejar los Dockerfile extraños en la mayoría de los contextos.

Si -f es un archivo en lugar de un directorio que contiene Docker, eso también debería funcionar, para que un desarrollador pueda tener un archivo docker que no se compile cuando se ejecuta docker build .

Para que esto no se pierda, ayer en la discusión de IRC con @shykes tuvo otra idea sobre

• Hay un Dockerfile maestro en la raíz del repositorio que contiene solo varias líneas en un nuevo formato como "INCLUDE foo / bar / Dockerfile AS bar-foo" para cada imagen que se generará.
• Cada subproyecto (como el módulo de barra del subproyecto foo), que necesita una imagen separada, mantiene un Dockerfile regular en foo / bar / Dockerfile. Las rutas en ese Dockerfile (para ADD y COPY) siguen siendo relativas a la raíz de contexto, que es la raíz del repositorio (donde reside el Dockerfile maestro)
• Llamada regular a "docker build -t mycorp / myapp". construirá todas las imágenes registradas en el Dockerfile raíz y les asignará nombres como "mycorp / myapp / bar-foo" en este ejemplo
• Debería introducirse una opción de línea de comando adicional para "docker build" para compilar solo algunas de las imágenes declaradas, como "docker build -t mycorp / myapp --only bar-foo, baz-db"

En caso de que la gente siga buscando una solución alternativa:

#!/bin/bash
ln -s Dockerfile-dev Dockerfile
docker build -t image/name-dev:latest .
rm Dockerfile

@shykes ping? Si hay una aprobación del desarrollador principal para una solución de diseño específica, entonces es mucho más probable que alguien intente implementarla y haga una solicitud de extracción.

+1 a la solución -f, aunque estoy de acuerdo en que cada repositorio debería, en teoría, implementar su propio servicio. Algunas personas no pueden darse el lujo de esa solución. Mi problema particular es que tengo un repositorio de chef con varios libros de cocina y necesito poder crear muchos servicios. Pero necesito poder AGREGAR directorios arriba. Por lo tanto, mantener el contexto en la raíz y apuntar a un archivo de ventana acoplable en un subdirectorio es óptimo.

"-f" probablemente no se implementará por las razones ya dadas.

Es imperativo que una compilación funcione exactamente igual de un host a otro, y tener cosas que dependen de que el host se configure de una manera particular (es decir, Dockerfile en algún lugar y contexto aleatorio en algún otro lugar) rompe este contrato.

Creo que el # 7115 es probablemente la solución adecuada para esto.

También hay # 7204 que también se ajusta a gran parte del caso de uso para esto, creo.

No me gustan las dos soluciones propuestas que implican agregar sintaxis al dockerfile. Ninguno de los dos parece sencillo. # 7115 todavía no parece que resolvería el caso de uso en el que quería generar varios tipos de imagen desde un solo repositorio, como lo estoy haciendo, por ejemplo, en uno de mis proyectos para generar una imagen de 'prueba' y una imagen de 'prod'. # 7204 parece una solución demasiado complicada que resuelve un problema diferente -f permite _configurability_ a una compilación, mientras que ambas soluciones abordan _sub_builds_.

Realmente me gustaría una explicación de "Es imperativo que una compilación funcione exactamente igual de un host a otro". No veo por qué este es un principio tan clave.

Tal como están las cosas, estoy usando make para generar el entorno de la ventana acoplable como una solución a todo este problema, que parece que ya viola su imperativo host-to-host run-the-same.

Para mí, -f parece una solución pragmática, pero si no es aceptable, entonces quizás podamos pensar en una solución que no implique convertir el dockerfile en una sintaxis de programación completa.

Es imperativo que una compilación funcione exactamente igual de un host a otro

A mí también me gustaría saber más sobre por qué esto es clave. Nuestro equipo está actualmente
forzado a programar el proceso de compilación, exactamente lo que está tratando de evitar.

Cuando descargo una imagen de un registro, simplemente funciona. No necesito
constrúyelo. ¿No es eso lograr la repetibilidad de host a host? ¿Por qué construye
también tiene que ser repetible de host a host?

El lunes 28 de julio de 2014 a las 10:43 a. M., Peter Braden [email protected]
escribió:

No me gustan las dos soluciones propuestas que implican agregar sintaxis a la
dockerfile. Ninguno de los dos parece sencillo. # 7115
https://github.com/docker/docker/issues/7115 todavía no lo parece
resolvería el caso de uso en el que quería generar varios tipos de imagen
desde un solo repositorio, como lo estoy haciendo, por ejemplo, en uno de mis proyectos para
generar una imagen de 'prueba' y una imagen de 'prod'. # 7204
https://github.com/docker/docker/pull/7204 parece un
solución demasiado complicada que resuelve un problema diferente -f permite
_configurability_ a una compilación, mientras que ambas soluciones abordan
_sub_builds_.

Realmente me gustaría una explicación de "Es imperativo que una compilación funcione
exactamente lo mismo de un host a otro ". No veo por qué esta es una clave
principio.

Tal como están las cosas, estoy usando make para generar el entorno de la ventana acoplable como un
solución a todo este problema, que parece que ya viola su
host-a-host ejecutar-el-mismo imperativo.

Para mí, -f parece una solución pragmática, pero si no es aceptable,
entonces tal vez podamos pensar en una solución que no implique cambiar el
dockerfile en una sintaxis de programación completa.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/docker/issues/2112#issuecomment -50347483.

Por lo que tengo entendido, la idea clave es que puede extraer un repositorio de git y si ve un Dockerfile allí, puede ejecutar "docker build -t mytag". en él y obtenga la compilación completa esperada. La clave aquí es que no hay instrucciones de compilación personalizadas que las personas puedan equivocarse o no conocer.
Lo que _podría_ ser un compromiso es una forma de definir múltiples imágenes de Docker en un solo contexto donde, de manera predeterminada, todas están construidas con sub-etiquetas predefinidas y luego podría tener la opción de construir solo una de las muchas imágenes posibles.
De esta manera, la sintaxis de construcción común se conserva al mismo tiempo que permite: 1) generar muchas imágenes diferentes a partir de un contexto; 2) Solo elige generar uno de ellos con una opción "avanzada".
La sintaxis propuesta se describe en mi comentario anterior: https://github.com/docker/docker/issues/2112#issuecomment -48015917

@algarius gracias, creo que en este punto deberíamos abrir una nueva propuesta de diseño para la sintaxis _INCLUDE_. Para ver ejemplos de propuestas de diseño, consulte el n.º 6802 o el n.º 6805.

El proceso se ve así:

• Presentar propuesta de diseño
• Discutir propuesta de diseño
• Apruebo propuesta de diseño
• Enviar PR para propuesta de diseño

Seamos honestos, las compilaciones no son realmente repetibles ahora.

Si tengo RUN apt-get update && apt-get install build-essentials ruby python whatever en mi Dockerfile, entonces ya estoy a merced de
lo que sea "último" en los repositorios en el momento en que construyo la imagen. Si
USTED crea la imagen una semana después, es posible que obtenga diferentes versiones de
dependencias a las que tengo.

@codeaholics Pero eso

Probablemente un comentario justo

@codeaholics, tienes razón en que la repetibilidad de las compilaciones no es perfecta, aunque hay opciones para controlarla (como la fijación de versiones) y deberíamos proporcionar más. Pero al menos la compilación siempre tiene el mismo _punto de entrada_, lo que significa que _ podemos_ introducir una mejor repetibilidad en el futuro. Sin embargo, una vez que su compilación depende de una herramienta de terceros en sentido ascendente de Docker, no hay vuelta atrás: la repetibilidad de su compilación es básicamente cero y ninguna mejora futura de Docker puede solucionarlo.

Tampoco se trata solo de repetibilidad. Si su compilación depende de un conjunto particular de argumentos, no detectable por _docker build_, entonces su herramienta personalizada es la única herramienta de compilación en el mundo que puede construirla: ya no puede beneficiarse de las diversas herramientas y complementos de CI / CD que asumen un _docker build_ nativo y detectable.

@peterbraden en # 7115, una vez que agregue la capacidad para múltiples llamadas PUBLISH , ahora puede producir múltiples imágenes. Luego, puede agregar capacidad de configuración al permitir seleccionar qué subimágenes construir. La clave es que la configurabilidad tiene lugar _dentro del conjunto de subimágenes detectables por Docker_. De esa forma, conserva la visibilidad.

@shykes > una vez que su compilación dependa de una herramienta de terceros en sentido ascendente de Docker
sí mismo ... la repetibilidad de su compilación es básicamente cero.

Estoy de acuerdo. Creo que la mayoría de mis Dockerfiles dependen de apt y los repositorios de apt
están cambiando constantemente. Una construcción hoy no es lo mismo que una construcción
el dia de ayer. Una imagen construida es el único estándar de oro en mi opinión.

Si la repetibilidad no es el motivo principal de la restricción, el complemento CI
El soporte parece una alternativa bastante débil. Las herramientas de construcción están diseñadas para
admitir casos de uso idiosincrásicos. Un complemento que no hace más que
configurar un docker build cmd parece bastante inútil. Mi herramienta de construcción es
ya es un entorno de secuencias de comandos. Peor aún, palear todo el potencial
casos de uso en el Dockerfile, el tiempo extra parece una mala manera de diseñar
eso. El Dockerfile debe permanecer enfocado en simplemente producir una nueva imagen
agregando capas a una imagen base. Otro trabajo parece fuera de banda.

Amo a Docker hasta ahora. ¡Increíbles chicos de trabajo! Este problema en particular simplemente sucede
ser un punto de dolor.

El lunes 28 de julio de 2014 a las 12:25 p.m., Solomon Hykes [email protected]
escribió:

@peterbraden https://github.com/peterbraden en # 7115
https://github.com/docker/docker/issues/7115 , una vez que agregue la capacidad
para múltiples llamadas PUBLISH, ahora puede producir múltiples imágenes. Entonces tú
puede agregar configurabilidad al permitir seleccionar qué subimágenes construir.
La clave es que la configurabilidad tiene lugar dentro del conjunto de
subimágenes detectables por Docker_. De esa forma, conserva la visibilidad.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/docker/issues/2112#issuecomment -50361586.

@thedeeno el objetivo del Dockerfile es especificar cómo transformar un repositorio de código fuente en algo que Docker pueda ejecutar.

¿Qué tal "el objetivo de _a_ Dockerfile es especificar cómo transformar un repositorio de código fuente en algo que Docker pueda ejecutar"?

Creo que podemos estar de acuerdo en que existe una necesidad real de una forma de tener múltiples mapeos de repositorios-> imágenes. Tal como están las cosas, muchos de nosotros estamos abusando de los scripts de shell y los archivos MAKE para hacer esto. En mi experiencia, no he visto muchos Makefiles personalizados con nombre: la configuración y los valores predeterminados son una fuerza poderosa. Debido a esto, no estoy convencido de que la gente que abusa de las convenciones sea un escenario realista.

La alternativa que propone, agregar una palabra clave a la sintaxis de Dockerfile, hace que la creación de Dockerfiles sea más compleja. Estoy a favor de mantener esa sintaxis lo más simple posible. PUBLISH et al, parecen poco elegantes en comparación con el resto de la sintaxis de Dockerfile.

También existe la idea de seguir las convenciones de herramientas existentes. Como se ha mencionado, -f es un patrón tan común que la gente lo prueba sin siquiera saber que funciona. Una interfaz de usuario debe ser intuitiva y la gente _get_ -f banderas. La nueva sintaxis de Grokking Dockerfile no es tan intuitiva.

@peterbraden @shykes Estoy de acuerdo en ser más simple e intuitivo. Originalmente encontré este problema porque _esperaba_ que Docker ya tuviera esta función y la busqué (presumiblemente cuando no funcionaba de forma predeterminada) el primer día que comencé a probarla para nuestras aplicaciones.

Este no es un caso extremo, a menos que se encuentre en una situación en la que no pruebe su software ni lo ejecute en varios entornos. Cada repositorio que he tocado en los últimos 10 años tiene el requisito de poder ejecutarse en diferentes contextos. Creo que mucha gente en este hilo tiene el mismo problema. Todos estamos de acuerdo (creo) en que tener una convención es obviamente valioso para el contexto predeterminado de su aplicación (suponiendo que tenga una).

Leí # 7115 (rápidamente) y no entiendo cómo resuelve este problema para nosotros, tal vez este sea un problema de documentación sobre el PR, pero si es difícil comunicarse, causará frustración y errores en mi opinión, mientras que -f o una bandera similar requeriría poco esfuerzo para explicarla y usarla correctamente.

Creé una nueva propuesta con esa idea INCLUYE - https://github.com/docker/docker/issues/7277

Como nota al margen, podría valer la pena pensar en un comando "APT" más eficiente en lugar de un torpe "RUN apt-get install -y ...." (y luego, posteriormente, YUM, EMERGE, PACMAN y cualquier otra cosa)

Ah, y considerando que mucha gente simplemente prueba la opción "-f" de todos modos, sería lindo si cada vez que intenta usarla, obtiene un mensaje de error que lo dirige a una página en la documentación que describe la nueva solución.

Realmente creo que todos estamos ignorando al elefante en la habitación.

@shykes está diciendo cosas como "El hecho de que puedas apuntar a un directorio de código fuente, sin otra información fuera de banda, y construir una imagen a partir de él exactamente según la especificación del desarrollador original, es muy poderoso y una diferenciador clave de Docker ".

Estoy bastante seguro de que esto equivale a decir "escribir docker build . en un directorio siempre debería hacer lo correcto", lo que equivale a decir "Si tienes un proyecto en el que no hay algo correcto obvio para docker build . por hacer, estás equivocado "

No puedo hablar de las motivaciones de otras personas suscritas a este tema, pero mis propias motivaciones para este tema son exactamente aquellos casos en los que docker build . no tiene un comportamiento obvio. ¿Quería una versión de depuración o una versión de lanzamiento? ¿Quería postgres horneado o debería emitir imágenes de postgres y aplicaciones separadas? ¿Quería que se cargara con datos de prueba o datos de producción? ¿Quería ejecutar las pruebas?

Claro, me gustaría vivir en un mundo donde la gente no tuviera que responder estas preguntas para conseguir una construcción. Pero yo no vivo en ese mundo. Por supuesto, podría elegir arbitrariamente algunas respuestas a esas preguntas y definir un comportamiento para docker build . . Pero el quid de la cuestión es que construir algo arbitrario cuando el usuario escribe docker build . no está "haciendo lo correcto".

La realidad de la situación es que hay proyectos en los que no hay nada correcto para construir. Hay muchas formas de resolver eso dentro de la ventana acoplable, como -f soporte, o hacer que el usuario elija de una lista de objetivos importados de otro lugar, o varias otras propuestas. Pero todos tienen la propiedad de que docker build . rompe, por diseño. Aquí hay un desajuste de impedancia fundamental, no puede simplemente proponer su salida.

La idea de que cada proyecto puede elegir algo sensato para hacer por docker build . es una fantasía. Existen proyectos que no pueden hacer algo sensato, y en número. La única pregunta en este punto es si Docker apoyará la naturaleza de productos de compilación múltiple de esos proyectos directamente o si recurrirán a las herramientas de compilación tradicionales como make o incluso a los scripts de shell. Esto está sucediendo ahora : por ejemplo, Discourse, uno de los proyectos distribuidos en Docker más grandes, utiliza un sistema de compilación propio en parte para resolver este problema.

@drewcrawford, ya ves, ese es exactamente el problema. "compilación de docker". debería construir _la_ imagen. La única imagen verdadera. Se supone que debe cambiar los parámetros de ejecución de la ventana acoplable para ajustar el comportamiento de la única imagen a diferentes entornos.
En este contexto, es probable que desee una versión de lanzamiento, solo la aplicación, nada más. Todas las demás cosas, como "la imagen de postgres", son cosas diferentes que se vinculan a su aplicación en tiempo de ejecución. Puede tomar la misma imagen de lanzamiento y ejecutarla con un comando no predeterminado para ejecutar sus pruebas en ella.
Idealmente, con la compatibilidad con varias imágenes, ni siquiera tiene que elegir entre compilaciones de "lanzamiento", "depuración" y "con pruebas"; solo tiene todas ellas con una compilación base y tres compilaciones de pequeñas diferencias en la parte superior.
Si intentas doblegar a Docker a la antigua forma de pensar, lo pasarás mal. No intente martillar un tornillo con un destornillador.

@algarius Creo que el problema es que este pensamiento no se aplica a aplicaciones reales, y nadie ha explicado cómo lo hace si realmente se supone que tenemos un cambio de paradigma aquí.

Permitir múltiples imágenes es la forma más simple e intuitiva de cumplir con el requisito que tienen la mayoría de las aplicaciones accesibles en red del mundo real (múltiples entornos con diferentes dependencias). ¿Es deseable hacer la gramática más complicada de una manera que no se pueda comunicar para resolver esto? Al final, solo está rediseñando y ocultando el hecho de que tiene> 1 entorno con diferentes dependencias que podrían expresarse fácilmente de una manera simple como múltiples Dockerfiles que casi no necesitan explicación para los usuarios finales del software.

@drewcrawford proporcionó un ejemplo concreto de cómo se trata esto en una aplicación popular del mundo real actual que se distribuye con el soporte de Docker. ¿Cómo deberían estar haciendo esto?

@aigarius No es que no entienda "el camino del muelle". Creo que está mal.

Por ejemplo, las pruebas pueden necesitar una compilación diferente (una _recompilación _ honesta) porque cierto código de registro que es demasiado lento para la producción debe compilarse condicionalmente.

Si esto suena como un trabajo para un sistema de creación, tiene razón, y eso es lo que hacen las personas como yo, encuentran formas de crear scripts de compilaciones de Docker utilizando sistemas de compilación reales.

El problema aquí es que un Dockerfile no puede ser tanto la interfaz de usuario preferida para la construcción como sustancialmente menos potente que, por ejemplo, make . Puede ser la interfaz de usuario preferida para la construcción, con potencia similar a la de un fabricante, o puede ser una herramienta de bajo nivel con make etc. como interfaz de usuario real. Pero los sistemas de compilación "reales" no son arbitrariamente complicados, son complicados porque la gente usa las funciones, y ninguna cantidad de compilaciones de Docker simplificadas van a cambiar eso. Todo lo que sucederá es que Docker se convertirá en el nuevo cc , que la gente invoca con make .

@shykes @drewcrawford @aigarius He escrito una propuesta para una opción -f simple de la misma manera que @shykes descrita anteriormente en este hilo aquí: # 7284

@drewcrawford tiene razón, para ser la interfaz de usuario preferida para la compilación, docker build debe ser al menos tan potente como, por ejemplo. make . Hay 2 formas de hacer esto:

• 1) Podríamos intentar volver a implementar todas las características de cada variación de make, así como todas las alternativas disponibles: Maven, scons, rake y, por supuesto, buenos scripts de shell antiguos.

O

• 2) Podríamos reconocer que estas herramientas de compilación son en sí mismas programas ejecutables, lo que significa que tienen dependencias de tiempo de ejecución y que se construyeron a partir de dependencias de compilación, y así sucesivamente. Y podríamos proporcionarle una forma de que _utilice_ realmente su herramienta de compilación favorita. Por lo tanto, no necesitaríamos volver a implementar make porque en realidad podemos compilar y ejecutar make.

Cuando dices make , ¿a qué sabor de marca te refieres? ¿Cual version? ¿Construido a partir de qué svn checkout exactamente? ¿Con qué opciones de construcción? ¿A qué libc está vinculado? La misma pregunta para cc que también mencionas. Tal vez no importe, tal vez su aplicación resulte exactamente igual independientemente de la versión aleatoria de make que termine usándola para compilar. Pero de nuevo, tal vez sí importe. Tal vez la única forma de obtener exactamente la misma compilación que tú es usar exactamente la misma compilación de Make y Cc que tú. Y no hay una manera fácil de hacer eso hoy, pero eso es lo que me gustaría hacer.

Realmente no pienso en docker build como una herramienta de compilación, exactamente, sino más bien como una herramienta de metacompilación: un punto de partida conocido desde el cual puede reconstituir cualquier entorno de compilación de manera confiable. Esa es la motivación del # 7115.

@shykes No creo que sea necesario realmente replicar _todas_ características de make, Maven, rake, etc. Después de todo, estas herramientas no replican todas las características entre sí, y de alguna manera se llevan bien.

Sin embargo, es necesario (si Docker va a ser la interfaz de usuario preferida para crear imágenes) que Dockerfile se convierta en un lenguaje más expresivo de lo que es actualmente.

La propuesta en este número es en realidad un movimiento bastante modesto en esa línea: está diciendo "Necesitamos un equivalente para hacer _objetivos_". La cuestión de "qué versión de make" realmente no entra en la imagen: el concepto de un "objetivo" es común para hacer, Maven, rake y cualquier otro sistema de construcción serio. Tienen una sintaxis diferente, pero el hecho de que la función en sí sea universal debería ser una pista de que esto es algo que las personas hacen con frecuencia cuando construyen cosas.

No importa si lo que están construyendo es un programa en C, una imagen de Docker o algo intermedio, todavía está construyendo algún objetivo. La idea de un objetivo de compilación es tan fundamental que abarca las implementaciones de sistemas de compilación, los lenguajes de programación y los sistemas operativos. No estamos hablando de replicar alguna característica oscura específica de GNU Make aquí, estamos hablando de algo que tiene el acuerdo más amplio posible.

Estás intentando introducir algún concepto de una "herramienta de meta-construcción" aquí, pero no existe tal cosa. Así como Docker puede orquestar las compilaciones de Make, también puede orquestar las compilaciones de Docker y, de hecho, make se está utilizando ahora mismo de esa manera, porque no hay forma de especificar un objetivo de compilación para Docker. Pero en cualquier caso, ninguno de los sistemas es intrínsecamente más o menos meta que el otro, todos son solo sistemas de compilación, que compilan objetivos, pero en el caso de Docker solo se le permite uno, que es el problema.

Propuestas como la # 7115 son interesantes, pero a menos que me pierda algo, no son un sustituto eficaz de los objetivos. Un objetivo te dice qué construir. # 7115 le brinda un DSL más flexible que aún puede construir una sola cosa. Eso es algo, pero no es lo que se solicita aquí.

docker build -t my_project_builder .
# Builds the builder container
docker run my_project_builder my_target | docker build -t my_project/my_target -< Dockerfile_MyTarget
# target is built, tarballed, and sent to stdout, then piped into a new docker build as the context and custom Dockerfile name

@drewcrawford solo para confirmar, si la make clean; make foo , 2) por defecto para construir _todos_ objetivos, y 3) tener una forma de enumerar objetivos ... ¿Eso sería satisfactorio para usted?

Eso sería satisfactorio ... Preferiría establecer de forma predeterminada en un objetivo elegido por el desarrollador en lugar de hacerlo en todos los objetivos, pero aceptaría cualquiera de las soluciones

Esta bien.

@shykes @drewcrawford : +1:

Todo lo que sucederá es que Docker se convertirá en el nuevo cc, que la gente invoca con make.

La propuesta en este número es realmente un paso modesto en esa línea: dice "Necesitamos un equivalente para hacer los objetivos". La cuestión de "qué versión de make" realmente no entra en la imagen: el concepto de un "objetivo" es común para hacer, Maven, rake y cualquier otro sistema de construcción serio. Tienen una sintaxis diferente, pero el hecho de que la función en sí sea universal debería ser una pista de que esto es algo que las personas hacen con frecuencia cuando construyen cosas.

@drewcrawford : +1: +1.000.000

Esta es la situación en la que sigo encontrándome:

Quiero crear dos contenedores Docker desde mi repositorio. Quizás uno sea el servidor, uno sea la base de datos. O tal vez uno es el servidor y el otro es un cliente que ejecuta pruebas automatizadas contra el servidor a través de llamadas a la API.

En cualquier caso, hay algunos archivos en el repositorio que necesito AGREGAR para ambos contenedores. Tal como está, es imposible hacer esto sin recurrir a copiar los Dockerfiles separados uno a la vez en un script bash, hacer la compilación y luego reemplazar o eliminar el Dockerfile.

Necesito ya sea:

1. El comando -f para especificar el archivo que se utilizará como Dockerfile.
2. La capacidad de AGREGAR un archivo que no sea la ruta descendente del Dockerfile.

Dado que se ha dicho repetidamente que el número uno es un no-go, y supongo que el número dos es aún más difícil técnicamente, ¿cuál es la forma "correcta" de hacer esto?

@ShawnMilo

El último comentario de

@jakehow Gracias por la actualización. Por tanto, parece que todavía falta mucho para encontrar una solución oficial al problema. Mientras tanto, ¿hay una "buena manera" de hacerlo? La mejor idea que tengo es un script bash que copia los archivos uno a la vez en "Dockerfile" en la raíz del repositorio y crea las imágenes. Funcionará pero se siente sucio.

@ShawnMilo sí, creo que la mayoría de la gente está usando una herramienta de construcción (make, rake, etc.) o simplemente un viejo script bash para hacer esto.

Arriba, alguien mostró un fragmento en el que tiene una imagen de constructor que también se ocupa de esto.

Esta es mi forma de abordar este problema. Tengo que crear una imagen para diferentes versiones de una plataforma, digamos v2 y v3. Entonces tengo un Dockerfile.v2 y un Dockerfile.v3 Cuando quiero hacer una compilación, primero ejecuto ln -s ./Dockerfile.v3 ./Dockerfile luego docker build . En realidad tengo un script y simplemente ejecuto ./build v3 o ./build v2

Si bien actualmente estoy usando un script que vincula un Dockerfile específico a ./Dockerfile , esta sería una buena característica.

Creé un PR # 7995 para tratar de solucionar este problema. Algunas de las soluciones que se discuten en este (largo :-)) hilo parecen terriblemente dolorosas para que las personas las usen. Uno de los mayores puntos de venta de Docker (para mí) fue lo fácil que es de usar y, por lo tanto, pedirle a la gente que supere este tipo de obstáculos por lo que parece una pregunta bastante fácil no se siente bien.

Ahora bien, es posible que me esté perdiendo algo, pero ¿hay alguna razón técnica por la que deba llamarse "Dockerfile"? Mientras creaba el PR no pude encontrar uno y me sorprendió gratamente lo fácil que fue cambiarlo.

@duglin tienes todo mi apoyo.

Esto es lo que estamos haciendo para solucionar la falta de una opción -f en nuestro proyecto actual.

# build.sh
...
mv specialDockerfile Dockerfile
docker build -t $(PROJECT) .

Considere esto como un +1 para agregar -f .

Actualmente también estoy manejando cosas como kikito. Escribí un par de scripts de shell para crear diferentes imágenes desde el mismo contexto, pero me encantaría ver una forma de especificar un archivo docker desde el argumento CLI como ya se sugirió. +1 para esta solicitud.

+1000

Me encontré con esto hoy cuando intentaba construir un proyecto de golang multiplataforma usando Docker. Esto funciona, vea boot2docker , pero necesito un Makefile para unir el interior y el exterior del proceso de compilación de la ventana acoplable, por ejemplo, docker cp los artefactos desde dentro de la ventana acoplable a mi directorio de compilación.

Sin embargo, si trato de usar esto en un subdirectorio de mi repositorio, mi GOPATH se rompe, ya que falta la carpeta .git en la raíz del repositorio. Necesito ADD la raíz del repositorio y luego compilar dentro de mi subdirectorio, pero Docker no lo permite.

Después de leer este largo hilo, vi una preocupación por no poder reproducir compilaciones. Una forma en que esto podría mitigarse es permitir que solo la opción -f apunte dentro del contexto de compilación o hacia abajo. De esta manera, puede tener varios Dockerfiles en subdirectorios y compilarlos desde la raíz del repositorio. Además, puede limitar esto para que esté dentro de los límites del repositorio, por ejemplo, al mismo nivel que .git / .hg / .foo y por debajo, pero no fuera del repositorio.

Esto es lo que estoy pensando

FROM scratch
BUILD myname1 path/to/dockerfile/in/context
BUILD myname2 path/to/dockerfile2/in/context

docker build -t myimage .

Esto produciría 3 imágenes:

1. Imagen principal llamada "myimage", que en realidad no tiene nada, por ejemplo
2. Una imagen llamada myimage-myname1
3. Una imagen llamada myimage-myname2

La palabra clave BUILD tomaría un nombre y una ruta a un Dockerfile. Este Dockerfile debe estar dentro del contexto original.
Cada instrucción de compilación tendría acceso al contexto completo de la compilación principal.
Aunque puede valer la pena limitar el contexto al árbol de directorios en el que está contenido el Dockerfile.

-1

Puede usar un alimentador de contexto para docker build - como dockerfeed para este caso especial.

@itsafire El objetivo es llevar este tipo de funcionalidad a Docker para que pueda ser una forma compatible de construir su proyecto. Estoy seguro de que a la gente le encantaría que esto también funcione con compilaciones automatizadas.

Estoy perdido aquí. Tenemos varias solicitudes de extracción para esta función adicional, ¿verdad? Y no parece difícil de hacer ... Incluso se podría hacer cumplir la regla que mencionó @maxnordlund : restringir la ruta para que sea relativa al contexto / raíz. Eso al menos lo haría funcionar mejor con boot2docket y demás, y lo haría "portátil".

Esta es, con mucho, la brecha más irritante en Docker, y a medida que más y más herramientas comienzan a usar Docker como parte de su funcionalidad, es importante que agreguemos rápidamente la capacidad de una marca '-f' para que esas herramientas estén preparadas para eso antes de volverse demasiado definitivo ... Relacionado: tener un Dockerfile de múltiples imágenes no es suficiente, ya que estas herramientas "meta" relacionadas a menudo asumen _una_ imagen por Dockerfile! Además, el uso de '-' no es suficiente con estas herramientas y restringe la funcionalidad en gran medida, como todos sabemos.

¿Alguien con autoridad puede explicar por qué esta solución aún no se ha fusionado, o al menos por qué esta característica que tanto falta todavía no está allí?

Empezando a sentirme como en Twilight Zone.

Supongo que hay una falta de coincidencia en la forma en que el equipo de Docker usa Docker / quiere que se use Docker y en cómo una gran parte de la comunidad usa Docker. Corrígeme si estoy equivocado.

El equipo de Docker quiere construir un repositorio de software que no se parezca mucho al repositorio del proyecto Debian. Donde las personas pueden obtener su software favorito y ejecutarlo fácilmente. El proceso de construcción del software debe ser repetible y obvio.

Otros quieren automatizar su implementación de software interno existente, que ya puede ser muy complejo con muchas herramientas de construcción, sistema CI, etc. Para ellos, Docker es simplemente otra herramienta que tiene que encajar en su infraestructura. Y necesitan un poco más de flexibilidad sobre cómo pueden usar Docker.

Creo que Docker (como .deb) puede satisfacer las necesidades de ambas partes, pero habrá que hacer concesiones.

El problema básico es: ¿dónde termina esto? ¿Turing completitud para Dockerfile? Probablemente no. Siempre existirá la necesidad de mayor flexibilidad para resolver un caso especial. Algunas ideas entrarán en el lenguaje de Dockerfile, otras no. Dado que Docker puede comer un contexto a través de stdin en una compilación, la funcionalidad faltante se puede implementar a través de un preprocesador.

@itsafire La última vez que lo comprobé, la Dockerfile pero no un contexto. De hecho, el contexto se ignora cuando proporciona un Dockerfile de esa manera. Si agregaran soporte para lo que sugirió, este sería un problema cerrado.

No he mirado en un tiempo, pero la solicitud básica es la siguiente: danos una forma explícita de proporcionar un Dockerfile Y un context durante la compilación. Honestamente sorprendido, esto es como 8 meses después y todavía está abierto.

@thedeeno esto es posible
cat mystuff.tar.gz | docker build -

@ cpuguy83 pero no puedo proporcionar un Dockerfile explícito con ese comando. ¿Derecha?

@thedeeno sí, alquila cualquier Dockerfile que desee con el contexto que desee.

@ cpuguy83 @thedeeno No, eso no funciona, porque entonces no puedes AGREGAR ningún archivo porque ninguno está en el alcance "cwd" que usualmente obtienes con un Dockerfile.

Editar: esta declaración es incorrecta; Entendí mal el ejemplo de

@ShawnMilo sí lo es. Cualquier cosa en el alquitrán está dentro de contexto.

@ cpuguy83 Lo siento, mi error. Lo leí apresuradamente como una tubería en el Dockerfile, no como un tarball completo.

@ cpuguy83 ¡

Pregunta secundaria, en mi solución personalizada, las marcas de tiempo rompieron el caché al tarar. ¿Eso sigue siendo un problema? Si alquilo la misma carpeta varias veces, ¿usará el caché en la compilación?

¡Mantener el buen trabajo!

Canalizar todo un contexto no alivia en absoluto lo que hablamos anteriormente.

Lo que queremos y necesitamos es una forma de utilizar el mismo contexto con varios Dockerfiles. Como las mencionadas "compilar con registro" y "compilar sin registro", como imágenes individuales. Tengo muchos otros casos de uso en los que esto es necesario.

No veo cómo el tar-balling en un directorio ayudaría en esto. Sí, uno podría crear un directorio especial y copiar el Dockerfile específico allí, y luego todo el directorio de contexto, o tar y agregar un nuevo Dockerfile, y luego gzip. Pero, ¿cómo es eso más fácil que la solución [bastante terrible] que tenemos que emplear actualmente de tener un script de preprocesador que coloque el Dockerfile correcto en su lugar antes de ejecutar la ventana acoplable?

Y esto no ayudará con la ecología de Docker, como señalé anteriormente.

¿Me he perdido algo?

Nuevamente, una simple opción '-f'. Por favor. Por favor, muy por favor. Oblígalo a ser una ruta relativa del contexto. Eso está bien.

@davber Lo que realmente desea es que Docker maneje el tarballing del contexto y el Dockerfile por usted.
Y no estoy totalmente en contra de esto. Aunque creo que las compilaciones anidadas pueden ser una mejor solución para esto.

@ cpuguy83 : sí, así que quiero que Docker se encargue de eso por mí, sí, lo que incluiría elegir la parte de contexto de un lugar y el Dockerfile de potencialmente otro lugar, o con un nombre no estándar. Es decir, para admitir una bandera '-f' separada :-)

Las compilaciones anidadas no resuelven los problemas que enfrentamos, que iniciaron este hilo y lo mantienen en funcionamiento.

Es decir, todavía queremos usar el mismo contexto raíz.

Sí, podemos copiar archivos y, sí, lo hacemos para evitar este extraño acoplamiento de contexto con un Dockerfile exacto llamado 'Dockerfile'. Pero eso no es ideal, y configurar rsync para garantizar que los archivos sean idénticos a los originales es simplemente extraño.

@ cpuguy83 : ¿puedes explicar cómo me ayudarían las compilaciones anidadas, o cualquier otro de los "quejicas" aquí? :-)

@davber
Mi opinión es la siguiente:

FROM scratch
BUILD myname1 path/to/dockerfile
BUILD myname2 path/to/another/dockerfile

Y esto:

docker build -t myimage .

Produciría 3 imágenes, "myimage", "myimage-myname1", "myimage-myname2".
Cada compilación interna tendría acceso al contexto de compilación completo como rutas absolutas. Las rutas relativas serían relativas al Dockerfile.
Y la "myimage" podría tener sus propias cosas además de las instrucciones de BUILD.

Como mencioné anteriormente, muchas de las nuevas herramientas en la ecología de Docker más grande (¡y genial!) Asumen que cada Dockerfile está asociado con exactamente una imagen de Docker. Las diversas herramientas de orquestador tipo "Fig" que existen. Y muchas de las soluciones en la nube nuevas y antiguas que tienen soporte específico para Docker también tienen esta suposición de uno a uno. Por supuesto, en el mundo creado por una opción '-f', entonces no solo tendrían que obtener un contexto, como una bola de alquitrán, por ejemplo, sino también un Dockerfile, potencialmente separado. Pero cada una de estas cargas seguiría correspondiendo exactamente a una imagen de Docker.

Si seguimos la ruta de separar potencialmente el Dockerfile de la raíz de contexto, espero que estas herramientas comiencen a vivir con este escenario:

Each deployment/use of a Docker image is done with an upload of either:

   1. a Dockerfile solely, when no contextual operations are needed
   2. a context tar ball only, containing the context with a top-level Dockerfile
   3. both a context tar ball and a separate Dockerfile

Cuanto más tiempo permanezcamos con este fuerte acoplamiento de 'Dockerfile' en el nivel superior del contexto, más arraigado estará en la ecología. Es decir, deberíamos actuar ahora, ya que el mundo de Docker se mueve rápidamente, debido a la genialidad general.

Y, honestamente, esa es una suposición razonable y conceptualmente atractiva, tener un isomorfismo entre Dockerfiles e imágenes, aunque el primero sería estrictamente un espacio de producto de directorios de contexto (tared up ...) y Dockerfiles, por defecto a (null, file) si solo se proporciona Dockerfile y (contexto, contexto / 'Dockerfile') si solo se proporciona contexto.

E incluso para la implementación local: digamos que queremos usar Fig para al menos la orquestación local: ¿cómo haría uno para hacer eso? Lo que habría que hacer es crear previamente las imágenes a partir de un Dockerfile de compilación múltiple de este tipo y luego consultar esas imágenes en la Fig. No es óptimo.

un isomorfismo entre Dockerfiles e imágenes

Esta suposición ya está rota en cómo las personas en este hilo están usando Dockerfiles. Es decir, usar secuencias de comandos para reemplazar el Dockerfile manualmente antes de ejecutar la compilación de la ventana acoplable. Probablemente también tengan su propia orquestación. Esta solicitud de función no se trata de cambiar el panorama de la ventana acoplable, se trata de hacer que la ventana acoplable funcione para un tipo de uso específico.

@hanikesn : dos comentarios:

1. por qué se rompe esa suposición al tener que copiar Dockerfiles en su lugar antes de compilar; todavía sería un Dockerfile <-> una imagen?
2. lo que estoy argumentando es que quiero cualquier solución que se nos ocurra aquí para _ trabajar con_ el panorama de Docker existente y en crecimiento, sin que se necesiten cambios demasiado grandes en este panorama; y creo que al mantener el isomorfismo mencionado, lo hacemos.

Otras sugerencias aquí han sido tener un Dockerfile de múltiples imágenes, potencialmente llamando a sub-Dockerfiles. Eso no funcionaría con la forma en que la mayoría de las herramientas (Fig, etc.) usan actualmente Docker.

@davber

Las compilaciones anidadas no resuelven los problemas que enfrentamos, que iniciaron este hilo y lo mantienen en funcionamiento.

Propongo esta solución que ya señalé anteriormente:

$ docker-pre-processor [ --options ... ] . | docker build -

Mientras que --options son las reglas, el contexto en el directorio actual (aquí) debe modificarse y pasarse a la ventana acoplable. Esto debe hacerse sobre la marcha creando un archivo tar temporal que contenga el contexto. De esa forma, el contexto de origen puede permanecer intacto. Es más fácil cambiar el preprocesador que la sintaxis de Dockerfile.

@itsafire

¿Qué pasa con las herramientas que esperan Dockerfiles hoy? Cada vez son más abundantes, utilizando Amazon, Google o similares. Y Fig y marcos de orquestación similares.

Entonces tendríamos que impulsar una herramienta estandarizada de 'preprocesador acoplable' y el uso de dicha herramienta a esos marcos, proveedores y herramientas.

Seguramente sería mucho más fácil tener el soporte adecuado de 'docker' al menos la opción que activa este hilo.

@itsafire todos los que tienen este problema y lo han resuelto ya están usando algún tipo de preprocesador o envoltorio alrededor de la compilación de la ventana acoplable para lograr este objetivo.

La fragmentación en torno a esta situación está en conflicto con el objetivo declarado del equipo de @docker de 'repetibilidad'. Esta discusión y las demás tratan de resolver este problema.

Más de 1 año y más de 130 comentarios y contando por un problema simple que afecta a la mayoría de los usuarios ... Estoy impresionado. ¡Sigan con el buen trabajo, Docker!

+1

Las herramientas deben ayudar a las personas a seguir su propio camino, pero no a imponer el camino "correcto". Un caso simple que me llevó a esta discusión:

`-- project
     |-- deploy
     |    |-- .dockerignore
     |    |-- Dockerfile
     |    ...
     `-- src

Mi forma es mantener limpia la raíz del proyecto. Pero ADD ../src y -f deploy/Dockerfile no funcionan. Por ahora tengo Dockerfile y .dockerignore en la raíz del proyecto, pero es doloroso para mí.

Por mi parte, he creado un script que prepara una carpeta con los archivos requeridos y ejecuta la línea de comando estándar docker build -t my/image . ya que encontré el problema de que el archivo .dockerignore es ignorado por el ADD ...

+1 seguro que le gustaría poder tener múltiples Dockerfiles en un solo repositorio. Mi caso de uso: una imagen es para uso e implementación de producción, otra imagen es una instancia de informes diseñada para usar las mismas herramientas de backend y conectividad de base de datos, pero no requiere de front-end, web, servicio del sistema o supervisión de procesos ...

+1 para esto. Necesito agregar archivos a diferentes imágenes de la misma carpeta, para diferentes servidores.

+1 Estoy disfrutando de Docker hasta ahora, pero debido a la forma en que configuro mi equipo, realmente necesito una forma de construir diferentes implementables que compartan una buena parte de código, desde un repositorio. No estoy particularmente interesado en construirlos a todos en un contenedor de uberdocker, ya que sus ciclos de implementación / lanzamiento están innecesariamente vinculados. ¿Cuál es la mejor práctica para evitar esto?

@jfgreen :

@ShawnMilo Gracias, parece una solución muy razonable.

+1

+1

+1 a -f . Hay un valor sensato por defecto que si se omite la bandera, Docker hará lo correcto. En el caso de que, por alguna razón, la vista muy específica de lo correcto sea para un usuario, lo incorrecto, hay -f . Las comparaciones anteriores con herramientas como make creo que son razonables. make también es una utilidad muy obstinada escrita originalmente en 1976 y, como tal, tuvo una cantidad de tiempo razonable para estabilizar un conjunto de características. Creo que es instructivo que en man make la única bandera que se menciona en la muy breve sinopsis es ... -f .

       make [ -f makefile ] [ options ] ... [ targets ] ...

No hay problema en las utilidades obstinadas y centradas en ux, pero algunas cosas como -f son guiños pragmáticos al mundo real en el que viven los usuarios. Una herramienta debería hacer su vida más fácil y no más difícil. Si tengo que escribir un Makefile o un script de shell para trabajar con una herramienta sin un -f eso es una falla de la herramienta. Claramente, por la cantidad de usuarios que se han tomado el tiempo para comentar y han sopesado +1, la función tiene una utilidad significativa incluso un año después de que se propuso inicialmente.

+1

+1 (o una publicación de blog oficial con la solución recomendada)

+1

+1

@crosbymichael Creo que esto se puede cerrar ahora debido a la fusión del # 9707

VICTORIA.

Si todos quieren probar esta nueva función, pueden descargar los binarios para master en:

master.dockerproject.com

¡Gracias @duglin !

:aplaudir:

¡Gracias @crosbymichael por el binario! : +1:

¡Bien hecho muchachos! :aplaudir:

¿Entonces es docker build -f Dockerfile.dev . ? editar: sí