Moby: COPIAR con archivos excluidos no es posible

Consulte https://docs.docker.com/reference/builder/#dockerignore -file
Puede agregar entradas a un archivo .dockerignore en la raíz del proyecto.

.dockerignore no resuelve este problema. Como escribí, "la otra parte está sujeta a otra COPIA".

Entonces, ¿quieres copiar condicionalmente en función de alguna otra copia?

El contexto contiene muchos directorios A1...A10 y un directorio B. A1...A10 tiene un destino, B tiene otro:

COPY A1 /some/where/A1/
COPY A2 /some/where/A2/
...
COPY A10 /some/where/A10/
COPY B some/where/else/B/

Y esto es incómodo.

¿Qué parte es incómoda? ¿Enumerarlos a todos individualmente?

COPY A* /some/where/
COPY B /some/where/else/

¿Esto funciona?

Los nombres A1..A10, B eran falsos. Además, COPY A* ... junta los _contenidos_ de los directorios.

Hay un par de opciones, lo admito, pero creo que todas son incómodas. Mencioné tres en mi publicación original. Una cuarta opción es reorganizar mi código fuente permanentemente para que A1..A10 se mueva en un nuevo directorio A. Esperaba que esto no fuera necesario porque un nivel de anidamiento adicional no es algo que desear, y mis herramientas actuales necesitaban caso especial mis proyectos dockerizados entonces.

(Por cierto, #6094 (siguiendo enlaces simbólicos) ayudaría en este caso. Pero aparentemente, esta tampoco es una opción).

@bronger si COPY se comportara exactamente como cp , ¿eso resolvería su caso de uso?

No estoy seguro de entender al 100%.
Tal vez @duglin pueda echar un vistazo.

@bronger Creo que @ cpuguy83 hizo la pregunta correcta, ¿cómo resolverías esto si estuvieras usando 'cp'? Miré y no noté algún tipo de opción de exclusión en 'cp', por lo que tampoco estoy seguro de cómo resolvería esto fuera de una 'compilación de ventana acoplable'.

Con el comportamiento de CP, podría mejorar la situación diciendo

COPY ["A1", ... "A10", "/some/where/"]

Todavía es un problema de mantenimiento leve porque tendría que pensar en esa línea si agregara un directorio "A11". Pero eso sería aceptable.

Además, cp no necesita exclusiones, porque copiar todo y eliminar las partes no deseadas casi no tiene impacto en el rendimiento más allá de la copia en sí. Con COPY de docker, significa caché invalidado incorrectamente cada vez que se cambia B e imágenes más grandes.

@bronger puedes hacer:

COPY a b c d /some/where

tal como estabas sugiriendo.

En cuanto a hacer un RUN rm ... después del COPY ... , sí, tendrá una capa adicional, pero aún debería poder usar el caché. Si ve una pérdida de caché debido a eso, hágamelo saber, no creo que deba hacerlo.

Pero

COPY a b c d /some/where/

copia el contenido de los directorios abcd juntos, en lugar de crear los directorios /some/where/{a,b,c,d}. Funciona como rsync con una barra inclinada añadida al directorio src. Por lo tanto, las _cuatro_ instrucciones

COPY a /some/where/a/
COPY b /some/where/b/
COPY c /some/where/c/
COPY d /some/where/d/

Se necesitan.

En cuanto al caché... si digo

COPY . /some/where/
RUN rm -Rf /some/where/e

entonces el caché no se usa si e cambia, aunque e no se incluye efectivamente en la operación.

@bronger sí, lamentablemente tienes razón. Supongo que podríamos agregar un tipo de indicador --exclude zzz , pero según https://github.com/docker/docker/blob/master/ROADMAP.md#22 -dockerfile-syntax, es posible que no obtenga una gran cantidad de tracción en este momento.

Lo suficientemente justo. Luego usaré COPY+rm por el momento y agregaré un comentario de FixMe. ¡Gracias por tu tiempo!

Solo para :+1: este problema. Regularmente lamento que COPY no refleje la semántica de barra inclinada final de rsync. Significa que no puede COPIAR varios directorios en una sola declaración, lo que lleva a la proliferación de capas.

Regularmente encuentro un caso en el que quiero copiar muchos directorios excepto uno (que se copiará más adelante, porque quiero que tenga diferentes efectos de invalidación de capas), por lo que --exclude también sería útil.

Además, desde man rsync :

       A trailing slash on the source changes this behavior to avoid  creating
       an  additional  directory level at the destination.  You can think of a
       trailing / on a source as meaning "copy the contents of this directory"
       as  opposed  to  "copy  the  directory  by name", but in both cases the
       attributes of the containing directory are transferred to the  contain‐
       ing  directory on the destination.  In other words, each of the follow‐
       ing commands copies the files in the same way, including their  setting
       of the attributes of /dest/foo:

              rsync -av /src/foo /dest
              rsync -av /src/foo/ /dest/foo

Supongo que no se puede cambiar ahora sin romper un montón de salvajes Dockerfile s.

Como ejemplo concreto, digamos que tengo un directorio con este aspecto:

/vendor
/part1
/part2
/part3
/...
/partN

Quiero algo que se parezca a:

COPY /vendor /docker/vendor
RUN /vendor/build
COPY /part1 /part2 ... /partN /docker/ # copy directories part1-N to /docker/part{1..N}/
RUN /docker/build1-N.sh

Entonces, part1-N no invalida la construcción de /vendor . (ya que /proveedor rara vez se actualiza en comparación con part1-N).

Previamente he solucionado esto colocando part1-N en su propio directorio, así que:

/vendor
/src/part1-N

Pero también me he encontrado con este problema en proyectos que no tengo la libertad de reorganizar tan fácilmente.

@praller buen ejemplo, nos enfrentamos exactamente al mismo problema. El principal problema es que la ruta de archivo de Go. Match no permite mucha creatividad en comparación con las expresiones regulares (es decir, sin patrón anti)

Se me acaba de ocurrir una solución un tanto descabellada para esto. COPY no puede excluir directorios, pero ADD _puede_ expandir tgz.

Es un paso de compilación adicional:
tar --exclude='./deferred_copy' -czf all_but_deferred.tgz .
compilación de la ventana acoplable...

Luego en tu Dockerfile:
AGREGAR ./all_but_deferred.tgz /application_dir/
.. cosas en las capas que rara vez cambian ..
AGREGAR . /dir_aplicación/
.. cosas en las capas que cambian a menudo

Eso da la sintaxis completa de tar para incluir/excluir/lo que sea sin montones de capas desperdiciadas tratando de incluir/excluir.

@jason-kane Este es un buen truco, gracias por compartir. Un pequeño punto: parece que no puede agregar el indicador z (gzip) a tar ; cambia el valor de la suma de comprobación sha256, lo que invalida la memoria caché de Docker. De lo contrario, este enfoque funciona muy bien para mí.

+1 para este problema, creo que podría admitirse de la misma manera que muchas bibliotecas globales lo admiten:

Aquí hay una propuesta para copiar todo excepto node_modules

COPY . /app -node_modules/

También me encuentro con el mismo problema, y ​​​​es un poco doloroso para mí cuando mis aplicaciones web de Java tienen aproximadamente 900 MB, pero casi el 80% de eso rara vez cambia.
Es un estado inicial de mi aplicación y la estructura de carpetas es algo estable, por lo que no me importa agregar 6-7 capas de COPY para poder usar el caché, pero seguramente dolerá a largo plazo cuando haya más y más archivos y directorios. se agregan

👍

Tengo el mismo problema aunque con docker cp , quiero copiar todos los archivos de una carpeta excepto uno

Exactamente el mismo problema aquí. Quiero copiar un repositorio de git y excluir el directorio .git.

@oaxlin podría usar el archivo .dockerignore para eso.

@antoineco ¿estás seguro de que funcionará? Ha pasado un tiempo desde que lo intenté, pero estoy bastante seguro de que .dockerignore no funcionó con docker cp , al menos en ese momento

@kkozmic-seek absolutamente seguro :) Pero el subcomando CLI docker cp que mencionó es diferente de la instrucción COPY que se encuentra en Dockerfile, que es el alcance de este problema.

docker cp no tiene nada que ver con Dockerfile y . dockerignore, pero por otro lado no se usa para construir imágenes.

Realmente me gustaría esto también: para acelerar la compilación, podría copiar alguna carpeta en partes anteriores de la compilación y luego el caché me ayudaría ...

No estoy seguro de entender cuál es el caso de uso, pero ¿no bastaría con tocar los archivos para excluirlos antes de COPIAR para resolver el problema?

RUN touch /app/node_modules
COPY . /app
RUN rm /app/node_modules

AFAIK COPY no sobrescribe el archivo, por eso creo que esto podría funcionar.

Vaya, no importa, parece que COPY en realidad sobrescribe los archivos. Ahora estoy un poco desconcertado por https://nodejs.org/en/docs/guides/nodejs-docker-webapp/ que npm instala y luego hace COPY . /usr/src/app . ¿Supongo que se supone que node_modules se ignora por docker? Por otro lado, tener un comando COPY_NO_OVERWRITE (se necesita un mejor nombre) podría ser una forma de lograr ignorar archivos durante la copia (tendría que crear archivos/directorios vacíos para las cosas que desea ignorar).

FWIW, encuentro esto muy feo.

Encontré otra solución de pirateo:

Ejemplo de estructura de proyecto:
aplicación/
configuración/
texto/
Especificaciones/
estático/
...

Queremos:

1. Copia estática/
2. Copiar otros archivos
3. Copiar aplicación/

solución de pirateo:
ADD ./static /home/app
ADD ["./[^s^a]*", "./s[^t]*", "/home/app/"]
ADD ./app /home/app

El segundo ADD es equivalente a: copiar todo, excepto "./st " y "./a ".
¿Alguna idea para mejorar?

¿Cuál es el estado del comentario ?

👍

👍

👍

👍

¿Qué hay de tener un archivo .dockerignore de la misma manera que .gitignore?

@mirestrepo Vea los dos primeros seguimientos de este número.

Actualmente, este es un nerf megaperf para el desarrollo de C#/dotnet.

Lo que quiero:

• Primero copie todos los dll externos a las imágenes de la ventana acoplable (todo excepto My * .dll)
• Luego copie todos mis dll (comenzando con My.*.dll).

Ahora parece que esto no es (fácilmente) posible porque no puedo copiar todo excepto.

Entonces, los dlls se copian dos veces, lo que aumenta el tamaño del archivo docker o todo se copia en una capa.
El último es un mega nerf porque los archivos DLL externos se copian cada vez en lugar de almacenarse en caché.

@adresdvila gracias por la solución pude dividirla en:

COPY ["[^M][^y]*","/app/"] 
COPY ./My* /app/

Aunque esto todavía deja el problema de que los archivos .json se copian en el primer comando

Solo intervino para decir gracias a @antoineco , mi problema está resuelto. Ya no copio el directorio .git en mis imágenes acoplables.

Esto mejoró drásticamente el tamaño de la imagen y hace que mi imagen sea mucho más amigable para el sistema de almacenamiento en caché de la ventana acoplable.

Tengo el mismo problema. Tengo un archivo grande que quiero copiar antes que el resto de los archivos para que cualquier cambio en el contexto no se repita, ya que lleva mucho tiempo copiarlo (archivo bin de 7 GB). ¿Hay nuevas soluciones?

El problema con el enfoque COPY y prune es que la capa antes de la poda sigue teniendo todos los datos.

COPY . --exclude=a --exclude=b sería extremadamente útil. ¿Qué opinas, @cpuguy83?

@Nowaker Me gusta. Parece estar en línea con tar y rsync todos modos.
Supongo que esto debería admitir el mismo formato que dockerignore.

@tonistiigi @dnephin

Creo que este caso sería manejado por #32507.

@ cpuguy83 Sí. En particular, en línea con COPY --chown=uid:gid

@dnephin RUN --mount suena como un caso de uso totalmente diferente, centrado en generar algo basado en datos que no necesitamos después de generar la salida. (Por ejemplo, compilar con Go, generar HTML desde el archivo Markdown, etc.). RUN --mount es genial y definitivamente lo usaría en el proyecto en el que estoy trabajando actualmente (generando documentos API usando Sphinx).

COPY somedir --exclude=excludeddir1 --exclude=excludeddir2 se centra en la copia de datos que tienen que terminar en la imagen pero esparcidos en varias instrucciones COPY, no solo en una. El objetivo es evitar COPY first second third .... eleventh destination/ explícitos cuando el proyecto tiene muchos directorios en la raíz y está sujeto a cambios o aumentos.

En mi caso, primero quiero copiar la mayoría de los archivos, excepto aquellos que no son esenciales, para asegurarme de que se use el caché si los archivos de origen no cambiaron. Luego, compile/genere, y use el caché si los archivos copiados no cambiaron (sí). Al principio, copie los archivos que excluí anteriormente, que podrían haber cambiado desde la compilación anterior, pero su cambio no afecta la compilación/generación. Obviamente, tengo una tonelada de archivos y directorios en formato . que quiero COPIAR primero, y solo un par que quiero COPIAR en algún lugar al final.

La idea es que RUN --mount sea ​​capaz de resolver muchos problemas. COPY --exclude resuelve un solo problema.

Prefiero agregar algo que resuelva muchos problemas que agregar un montón de sintaxis para resolver problemas individuales. Usaría RUN --mount... rsync --exclude ... (o algún script que copie cosas individuales) y sería el equivalente a COPY --exclude .

@dnephin ¡Oh, no pensé en RUN --mount rsync ! ¡Excelente! 👍

Eso es excelente de hecho. Sin embargo, no podrá aprovechar el almacenamiento en caché de manera eficiente @Nowaker , porque el caché se invalidará si algo cambia en el directorio montado, no solo lo que desea rsync.

Si usa la salida de ese rsync como una entrada para otra cosa y ningún archivo realmente cambió allí, el caché se recuperará nuevamente. Si realmente está dispuesto a hacerlo, puede hacerlo actualmente con algo como https://gist.github.com/tonistiigi/38ead7a4ed60565996d207a7d589d9c4#file -gistfile1-txt-L130-L140 . El único cambio en RUN --mount (o LLB en el kit de compilación) es que no tiene que copiar archivos entre etapas, pero puede acceder a ellos directamente, por lo que es mucho más rápido.

¿Qué tal usar https://docs.docker.com/develop/develop-images/multistage-build/?

FROM php:7.2-apache as source
COPY ./src/ /var/www/html/
RUN rm -rf /var/www/html/vendor/
RUN rm -rf /var/www/html/tests/

FROM php:7.2-apache
COPY --from=source /var/www/html/ /var/www/html/

@antoineco Welp, entonces ya no es excelente. Gracias por señalar..

@MartijnHols Esta es una buena solución. Gracias por publicar.

Para los mantenedores: dicho esto, podríamos decir "por qué implementar --chown en COPY, puede usar RUN chown en una compilación de varias etapas". Necesitamos --exclude para la cordura. Hay demasiadas soluciones en Dockerfiles en estos días.

Tengo un caso de uso que se beneficiaría de COPY --exclude . Tengo una carpeta de datos grandes que debe copiarse en el contenedor en su totalidad. El contenido de ese directorio está sujeto a cambios frecuentes. Para mejorar el rendimiento de la memoria caché, hay un solo archivo grande en el directorio que quiero copiar en su propia capa, antes de copiar el resto. A partir de ahora, es innecesariamente detallado describir este tipo de contenedor.

¿Cuál es la forma correcta de usar el almacenamiento en caché en capas centrado en los requisitos.txt

Tengo esto:

/root-app
 - /Dockerfile
 - /requirements.txt
 - /LICENSE
 - /helloworld.py
 - /app-1
     -/app-1/script1
     -/app-1/script2
     -/app-1/script3
 - /app-2
     -/app-2/script1

Y Dockerfile:

FROM python:slim
COPY ./requirements.txt /
RUN pip install --trusted-host pypi.python.org -r /requirements.txt
WORKDIR /root-app
COPY . /helloworld
CMD ["python", "helloworld.py"]

¿Cuál es la forma correcta de usar el segundo comando COPY para excluir la memoria caché de compilación de requisitos ... y de manera similar superponer mi aplicación 1 y aplicación 2 si no cambian mucho?

@axehayz No estoy seguro de si esto es lo que está preguntando, pero haría algo similar al flujo de trabajo del nodo en https://medium.com/@guillaumejacquart/node -js-docker-workflow-12febcc0eed8.

Es decir, está bien que su segunda copia sea solo COPY . ; siempre que su pip install venga antes, esto no invalidará el almacenamiento en caché para los paquetes instalados.

Enfrentó el mismo problema. Por el momento preferiría expandir los archivos en diferentes directorios.

Tengo otro caso para COPY --exclude=... --exclude=...

Estoy tratando de hacer COPY --from=oldimage para reducir el tamaño de mi imagen y necesito copiar la mayoría de los archivos, pero sin algunos. Puedo hacerlo directorio por directorio, lo cual es doloroso, pero funciona... Pero poder --excluir una lista de directorios/archivos o proporcionar múltiples --excluir opciones sería mucho mejor y más fácil de mantener.

Entonces, después de tres años y medio, ¿no hay ningún reconocimiento?

@asimonf Hay toneladas de reconocimiento y de ida y vuelta para comprender el caso de uso. ¿Supongo que quiere decir que nadie ha hecho este trabajo? Eso es correcto. Todos tenemos que tomar decisiones sobre las cosas en las que trabajamos.

Honestamente, esto se puede hacer con bastante facilidad utilizando la funcionalidad existente, incluso si eso significa que tiene que escribir un poco más en su Dockerfile para que esto suceda.

# haven't tested exact syntax, but this is the general idea
FROM myRsync AS files
COPY . /foo
RUN mkdir /result && rsync -r --exclude=<pattern> /foo/ /result/

FROM scratch
COPY --from=files /result/* /

Con buildkit ni siquiera necesitas una etapa adicional

#syntax=docker/dockerfile:experimental
..
RUN --mount=target=/ctx rsync ... /ctx/ /src/

A menos que me esté perdiendo algo, usar una compilación de varias etapas no parece ser la solución aquí. El caché todavía está invalidado en la etapa COPY.

A menos que me esté perdiendo algo, usar una compilación de varias etapas no parece ser la solución aquí. El caché todavía está invalidado en la etapa COPY.

Esto es correcto. Como es el problema que estoy teniendo en este momento.

Multi-etapa funciona muy bien para mí.

Estoy dividiendo mi compilación en varias etapas, para aprovechar al máximo el caché, se parece a esto:

FROM alpine as source

WORKDIR /app
COPY . ./
RUN scripts/stagify-files

FROM node:12.4.0

WORKDIR /app

# Step 0: Setup environments
COPY --from=source /app/stage0 ./
RUN stage0-build.sh

# Step 1: Install npm packages
COPY --from=source /app/stage1 ./
RUN stage1-build.sh

# Step 2: Build project
COPY --from=source /app/stage2 ./
RUN stage2-build.sh

@zenozen , el desafío con ese proceso es que tuvo que organizar el diseño de su aplicación específicamente para una compilación de ventana acoplable, algo que muchas personas no quieren hacer.
El uso de la ventana acoplable es una de las muchas consideraciones a tener en cuenta al determinar cómo diseñar los archivos de su aplicación (p. ej., capacidad de mantenimiento, facilidad de uso para las nuevas contrataciones, estándares de proyectos cruzados, requisitos del marco, etc.).

@cfletcher No estoy seguro de entender completamente lo que quieres decir.

Para el cambio que mencioné anteriormente, en realidad moví mi Dockerfile a un sub-subdirectorio (lo que me causó muchos problemas al intentar usar rsync para organizar esos archivos), lo que significa que estaba tratando de ocultar mi Dockerfile.

El enfoque que propuse es general como imagino. Digamos que tiene 100 archivos en su proyecto. Simplemente elige 1 de ellos para formar la etapa 0, luego 1+10 de ellos para formar la etapa 1 y luego los 100 para formar la etapa 2. Cada etapa se apila sobre la anterior y tiene un comando de construcción diferente. Para una estructura de proyecto complicada, solo significa que la lógica de stagify-files sería complicada.

Para mí, la razón principal es que divido mi código en módulos y necesito que se copien todos los archivos package.json antes de ejecutar npm install .

También me gustaría algún tipo de argumento de exclusión para la copia. Tenemos más de 20 archivos y más de 10 directorios en el directorio raíz. Codificamos mucho en 2 de los directorios y algunos de los archivos. Me gustaría dividirlos en dos capas COPY. Uno para los archivos y directorios estáticos que nunca tocamos, y el otro para los archivos y directorios que siempre tocamos.

Es muy triste que esto todavía sea ignorado. Esto me habría ayudado a ahorrar 5 minutos por compilación si pudiera excluir UN directorio para no invalidar el caché.

Con el kit de compilación, el caché no depende de la imagen principal como si fuera un kit de compilación previo.
Entonces, sí, con la solución rsync mencionada, recibirá un golpe porque necesitará sincronizar cada vez que haya algún cambio, pero las etapas posteriores se almacenarán en caché según el contenido, y si el contenido de lo que se transfiere no se cambia, entonces. .. al menos en mi teoría completa sobre el terreno, esas etapas deberían usar el caché.

Es triste agregar una simple bandera de --exclude a COPY es una venta tan difícil. Está en el TOP30 de los boletos más votados y es relativamente fácil de implementar en comparación con otros boletos del TOP30. :(

No es controvertido, requiere trabajo.

@cpuguy83 Sí . Parecía controvertido/algo rechazado. ¿Significa que probablemente se aceptaría una RP adecuada con COPY --exclude , si supera los estándares de calidad?

No puedo hablar por todos los mantenedores, pero hablé con @tonistiigi hace aproximadamente un mes sobre esto y el IIRC es el mayor obstáculo: cómo se relaciona esto con dockerignore, la sintaxis, etc. (y el hecho de que dockerignore es insuficiente sintácticamente).

El cambio tendría que ir a buildkit.

Upvoting COPY --exclude=... --exclude=... - también es necesario en mi caso de un repositorio monolítico

Votando a favor! Probé con COPY !(excludedfile) . que debería funcionar en Bash pero no en Docker

No me gustan las sugerencias de tener que repetir todo dentro del archivo .dockerignore para cada instrucción COPY en el Dockerfile . Ser capaz de permanecer SECO con lo que será parte de la imagen y no debería ser una prioridad, en mi humilde opinión.

En cuanto a #33923, no creo que sea una coincidencia que lo que desea excluir del contexto de compilación sea exactamente lo mismo que desea excluir de las declaraciones de COPY . Creo que algo como esto sería una buena solución:

COPY --use-dockerignore <source> <target>

O tal vez incluso algo como esto:

COPY --use-ignorefile=".gitignore" <source> <target>

Al ver que .dockerignore suele ser una reproducción del 90% de .gitignore , se siente muy molesto tener que repetir cada archivo y carpeta ignorados una vez más para cada declaración COPY . Tiene que haber una mejor manera.

@asbjornu .gitignore y .dockerignore no son lo mismo en absoluto. Especialmente para compilaciones de varias etapas en las que los artefactos se generan en una etapa de compilación y no están presentes en Git, sin embargo, deben incluirse en la imagen resultante.
Y sí, con las compilaciones de varias etapas introducidas, DEBERÍA EXISTIR la capacidad de usar diferentes archivos .dockerignore por etapa, absolutamente.

A menudo quiero copiar fuera de la "construcción de la ventana acoplable". En estos casos, .dockerignore no hace nada. Necesitamos una enmienda a "docker cp" es la única solución sensata

Hace 5 años que se abrió este tema. En septiembre de 2020, todavía quiero esto. Mucha gente ha sugerido trucos para solucionarlo, pero casi todos ellos y otros han solicitado el indicador exclude de una forma u otra. Por favor, no dejes que este problema quede sin resolver por más tiempo ahora.

Si quieres algo, necesitas trabajar en ello o encontrar a alguien que trabaje en ello.

Si quieres algo, necesitas trabajar en ello o encontrar a alguien que trabaje en ello.

Primero necesitamos saber si upstream quiere esto.

https://github.com/moby/moby/issues/15771#issuecomment-550571058

Después de la revisión del código fuente, creo que deberíamos ampliar la función de copia aquí https://github.com/tonistiigi/fsutil/blob/master/copy/copy.go en primer lugar. Después de eso, podemos extender backend.go en libsolver, y solo después será posible extender AST y frontend de buildkit.
Pero después de eso, la copia estará más cerca de rsync semántica que de unix cp.

ACTUALIZACIÓN: sí, después de extender copy.go, todo estará cerca de https://github.com/moby/buildkit/pull/1492 más la lista de análisis de exclusiones.