Я розумію, на це питання вже є кілька популярних відповідей. Але є більш новий спосіб кешування файлів для менеджерів пакетів. Я думаю, що це може стати гарною відповіддю в майбутньому, коли BuildKit стане більш стандартним.
Станом на Docker 18.09 існує експериментальна підтримка BuildKit . BuildKit додає підтримку деяких нових функцій в Dockerfile, включаючи експериментальну підтримку для монтажу зовнішніх томів на RUNетапи. Це дозволяє нам створювати кеші для таких речей$HOME/.cache/pip/ .
Ми використаємо такий requirements.txtприклад:
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
Типовий приклад Python Dockerfileможе виглядати так:
FROM python:3.7
WORKDIR /usr/src/app
COPY requirements.txt /usr/src/app/
RUN pip install -r requirements.txt
COPY . /usr/src/app
З увімкненим BuildKit за допомогою DOCKER_BUILDKITзмінної середовища ми можемо створити не кешований pipкрок приблизно за 65 секунд:
$ 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
Тепер додамо експериментальний заголовок і змінимо RUNкрок для кешування пакетів 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
Ідіть далі і зробіть іншу конструкцію зараз. Це повинно зайняти стільки ж часу. На цей раз це кешування пакетів Python у новому кріпленні кешу:
$ 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
Близько 60 секунд. Подібно до нашої першої збірки.
Внесіть невелику зміну до requirements.txt(наприклад, додавши новий рядок між двома пакетами), щоб примусити вимкнути кеш і запустити знову:
$ 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
Всього близько 16 секунд!
Ми отримуємо це прискорення, оскільки ми більше не завантажуємо всі пакети Python. Їх кешував менеджер пакунків ( pipв даному випадку) і зберігав у кріпленні обсягу кешу. Кріплення гучності надається кроку запуску, щоб pipможна було повторно використовувати вже завантажені пакети. Це відбувається поза будь-якого кешування шарів Docker .
Виграші повинні бути набагато кращими на більших requirements.txt .
Примітки:
- Це експериментальний синтаксис Dockerfile і його слід розглядати як такий. Ви, можливо, не хочете будувати з цим на виробництві наразі.
Матеріали BuildKit не працюють під Docker Compose або іншими інструментами, які безпосередньо використовують Docker API на даний момент. Зараз це підтримується в Docker Compose станом на 1.25.0. Див. Як увімкнути BuildKit за допомогою docker-compose?- На даний момент немає жодного прямого інтерфейсу для кешованого кешу. Він очищається, коли ви робите
docker system prune -a.
Сподіваємось, ці функції перетворять його в Docker для побудови, а BuildKit стане стандартним. Якщо / коли це станеться, я спробую оновити цю відповідь.