Entiendo que esta pregunta ya tiene algunas respuestas populares. Pero hay una forma más nueva de almacenar archivos en caché para los administradores de paquetes. Creo que podría ser una buena respuesta en el futuro cuando BuildKit se vuelva más estándar.
A partir de Docker 18.09, existe soporte experimental para BuildKit . BuildKit agrega soporte para algunas características nuevas en Dockerfile, incluido el soporte experimental para montar volúmenes externos en RUNpasos. Esto nos permite crear cachés para cosas como $HOME/.cache/pip/.
Usaremos el siguiente requirements.txtarchivo como ejemplo:
Click==7.0
Django==2.2.3
django-appconf==1.0.3
django-compressor==2.3
django-debug-toolbar==2.0
django-filter==2.2.0
django-reversion==3.0.4
django-rq==2.1.0
pytz==2019.1
rcssmin==1.0.6
redis==3.3.4
rjsmin==1.1.0
rq==1.1.0
six==1.12.0
sqlparse==0.3.0
Un ejemplo típico de Python Dockerfilepodría verse así:
FROM python:3.7
WORKDIR /usr/src/app
COPY requirements.txt /usr/src/app/
RUN pip install -r requirements.txt
COPY . /usr/src/app
Con BuildKit habilitado usando la DOCKER_BUILDKITvariable de entorno, podemos construir el pippaso sin caché en aproximadamente 65 segundos:
$ export DOCKER_BUILDKIT=1
$ docker build -t test .
[+] Building 65.6s (10/10) FINISHED
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 120B 0.0s
=> [internal] load metadata for docker.io/library/python:3.7 0.5s
=> CACHED [1/4] FROM docker.io/library/python:3.7@sha256:6eaf19442c358afc24834a6b17a3728a45c129de7703d8583392a138ecbdb092 0.0s
=> [internal] load build context 0.6s
=> => transferring context: 899.99kB 0.6s
=> CACHED [internal] helper image for file operations 0.0s
=> [2/4] COPY requirements.txt /usr/src/app/ 0.5s
=> [3/4] RUN pip install -r requirements.txt 61.3s
=> [4/4] COPY . /usr/src/app 1.3s
=> exporting to image 1.2s
=> => exporting layers 1.2s
=> => writing image sha256:d66a2720e81530029bf1c2cb98fb3aee0cffc2f4ea2aa2a0760a30fb718d7f83 0.0s
=> => naming to docker.io/library/test 0.0s
Ahora, agreguemos el encabezado experimental y modifiquemos el RUNpaso para almacenar en caché los paquetes de Python:
# syntax=docker/dockerfile:experimental
FROM python:3.7
WORKDIR /usr/src/app
COPY requirements.txt /usr/src/app/
RUN --mount=type=cache,target=/root/.cache/pip pip install -r requirements.txt
COPY . /usr/src/app
Adelante, haz otra compilación ahora. Debería llevar la misma cantidad de tiempo. Pero esta vez está almacenando en caché los paquetes de Python en nuestro nuevo montaje de caché:
$ docker build -t pythontest .
[+] Building 60.3s (14/14) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 120B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> resolve image config for docker.io/docker/dockerfile:experimental 0.5s
=> CACHED docker-image://docker.io/docker/dockerfile:experimental@sha256:9022e911101f01b2854c7a4b2c77f524b998891941da55208e71c0335e6e82c3 0.0s
=> [internal] load .dockerignore 0.0s
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 120B 0.0s
=> [internal] load metadata for docker.io/library/python:3.7 0.5s
=> CACHED [1/4] FROM docker.io/library/python:3.7@sha256:6eaf19442c358afc24834a6b17a3728a45c129de7703d8583392a138ecbdb092 0.0s
=> [internal] load build context 0.7s
=> => transferring context: 899.99kB 0.6s
=> CACHED [internal] helper image for file operations 0.0s
=> [2/4] COPY requirements.txt /usr/src/app/ 0.6s
=> [3/4] RUN --mount=type=cache,target=/root/.cache/pip pip install -r requirements.txt 53.3s
=> [4/4] COPY . /usr/src/app 2.6s
=> exporting to image 1.2s
=> => exporting layers 1.2s
=> => writing image sha256:0b035548712c1c9e1c80d4a86169c5c1f9e94437e124ea09e90aea82f45c2afc 0.0s
=> => naming to docker.io/library/test 0.0s
Aproximadamente 60 segundos. Similar a nuestra primera construcción.
Realice un pequeño cambio en requirements.txt(como agregar una nueva línea entre dos paquetes) para forzar una invalidación de caché y ejecutar nuevamente:
$ docker build -t pythontest .
[+] Building 15.9s (14/14) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 120B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> resolve image config for docker.io/docker/dockerfile:experimental 1.1s
=> CACHED docker-image://docker.io/docker/dockerfile:experimental@sha256:9022e911101f01b2854c7a4b2c77f524b998891941da55208e71c0335e6e82c3 0.0s
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 120B 0.0s
=> [internal] load .dockerignore 0.0s
=> [internal] load metadata for docker.io/library/python:3.7 0.5s
=> CACHED [1/4] FROM docker.io/library/python:3.7@sha256:6eaf19442c358afc24834a6b17a3728a45c129de7703d8583392a138ecbdb092 0.0s
=> CACHED [internal] helper image for file operations 0.0s
=> [internal] load build context 0.7s
=> => transferring context: 899.99kB 0.7s
=> [2/4] COPY requirements.txt /usr/src/app/ 0.6s
=> [3/4] RUN --mount=type=cache,target=/root/.cache/pip pip install -r requirements.txt 8.8s
=> [4/4] COPY . /usr/src/app 2.1s
=> exporting to image 1.1s
=> => exporting layers 1.1s
=> => writing image sha256:fc84cd45482a70e8de48bfd6489e5421532c2dd02aaa3e1e49a290a3dfb9df7c 0.0s
=> => naming to docker.io/library/test 0.0s
¡Solo unos 16 segundos!
Estamos obteniendo esta aceleración porque ya no estamos descargando todos los paquetes de Python. Fueron almacenados en caché por el administrador de paquetes ( pipen este caso) y almacenados en un montaje de volumen de caché. El montaje de volumen se proporciona al paso de ejecución para que pippueda reutilizar nuestros paquetes ya descargados. Esto sucede fuera de cualquier almacenamiento en caché de la capa de Docker .
Las ganancias deberían ser mucho mejores a mayor tamaño requirements.txt.
Notas:
- Esta es una sintaxis experimental de Dockerfile y debe tratarse como tal. Es posible que no desee construir con esto en producción en este momento.
Las cosas de BuildKit no funcionan bajo Docker Compose u otras herramientas que usan directamente la API de Docker en este momento. Ahora hay soporte para esto en Docker Compose a partir de la versión 1.25.0. Consulte ¿Cómo se habilita BuildKit con docker-compose?- No hay ninguna interfaz directa para administrar la caché en este momento. Se purga cuando realiza un
docker system prune -a.
Con suerte, estas características se convertirán en Docker para compilar y BuildKit se convertirá en el predeterminado. Si / cuando eso suceda, intentaré actualizar esta respuesta.