Настройка настройки использования кэш из реестра на каждом этапе сборки



У меня есть два сервера с docker и один сервер с моим личным реестром.

Я построил Dockerfile на первой машине; затем я отправил образ в реестр.

Можно ли сразу построить Dockerfile на второй машине, используя кэш из моего реестра? Если нет, то есть ли способ ускорить создание "почти" тех же Dockerfiles без написания собственного кэша?

Он попытался настроить --registry-mirror, но это не помогло.

118   2  

2 ответов:

Для docker > 1.10 я нашел кое-что по этому вопросу: https://github.com/docker/docker/issues/20316#issuecomment-221289631

Учитывая этот Dockerfile

FROM busybox
RUN mkdir this-is-a-test
RUN echo "hello world"

Бегите docker build -t caching-test .

Тогда мы можем видеть слои, содержащие изображение с docker history caching-test

3e4a484f0e67        About an hour ago   /bin/sh -c echo "Hello world!"                  0 B                 
6258cdec0c4b        About an hour ago   /bin/sh -c mkdir this-is-a-test                 0 B                 
47bcc53f74dc        9 weeks ago         /bin/sh -c #(nop) CMD ["sh"]                    0 B                 
<missing>           9 weeks ago         /bin/sh -c #(nop) ADD file:47ca6e777c36a4cfff   1.113 MB  

Изменение для сохранения / загрузки в 1.11 сохраняет связь между родительским и дочерним слоями, но только тогда, когда они сохраняются через docker save together. Мы можем видеть родителя окончательного тестового изображения по бег docker inspect test | grep Parent.

$ docker inspect caching-test | grep Parent
"Parent": "sha256:6258cdec0c4bef5e5627f301b541555883e6c4b385d0798a7763cb191168ce09", 

Это второй сверху слой из нашего вывода истории докеров.

Чтобы воссоздать кэш с помощью save and load, необходимо сохранить все изображения и слои, на которые ссылаются как на родительские. На практике это обычно означает, что вам нужно сохранить каждый слой, а также изображение из одной и той же команды.

docker save caching-test 6258cdec0c4b busybox > caching-test.tar -- обратите внимание, что мы также можем дать команде save имена слоев вместо идентификаторов.

Давайте очистим все а затем перезагрузите изображение из файла tar. docker rmi $(docker images -q). Подтвердите, что никаких изображений не существует.

Затем запустите docker load -i caching-test.tar. Если вы посмотрите на изображения, то увидите busybox, а затем caching-test. Запуск docker history caching-test покажет вам точно такой же результат, как и при первоначальном построении образа. Это происходит потому, что отношения родитель/потомок были сохранены через save и load. Вы даже можете запустить docker inspect caching-test | grep Parent и увидеть тот же идентификатор, что и родительский слой.

И запуск перестроения того же Dockerfile покажет вы, что кэш используется.

Sending build context to Docker daemon 5.391 MB
Step 1 : FROM busybox
 ---> 47bcc53f74dc
Step 2 : RUN mkdir this-is-a-test
 ---> Using cache
 ---> 6258cdec0c4b
Step 3 : RUN echo "hello world"
 ---> Using cache
 ---> 3e4a484f0e67
Successfully built 3e4a484f0e67

EDIT: ниже это работает только перед docker 1.10

На второй машине вы можете docker pull theimagefromthefirstdockerfileontheregistry Перед постройкой новой.

Таким образом, вы уверены, что каждый слой присутствует на второй машине.

Docker-engine не запрашивает реестр каждый раз, когда слой строится (он даже не знает об этом), это было бы слишком медленно/тяжело, поэтому я не думаю, что есть другой способ.

Примечание: проблема 20316 ("вытягивание кэша сборки") была закрыта, потому чтоPR 26839 ("реализация кэша сборки на основе массива истории") была объединена.

Это позволяет, например, указать в --cache-from Образ из предыдущей сборки CI.

Добавляет возможность указывать изображения, используемые в качестве источника кэша при сборке. Эти образы не обязательно должны иметь локальную родительскую цепочку и могут быть извлечены из других реестров. Пользователь должен убедиться, что использует только надежные образы. в качестве источников.

Использование:

docker pull myimage:v1.0
docker build --cache-from myimage:v1.0 -t myimage:v1.1 .

См фиксацию 7944480, для докер 1.13 (январь 2017).

Как прокомментировал javipolo:

В случае, если кто-то сходит с ума от повторного использования слоев, как это сделал я, "трюк" состоит в том, чтобы передать --cache-from изображение, которое вы восстанавливаете (и уже вытащили его), а также изображение, которое он использует в качестве основы в FROM.

Пример:
Dockerfile для изображения custom-gource:0.1

FROM base_image:2.2.1
RUN apt-get update && apt-get install gource
COPY myscript.sh /myscript.sh

Для того, чтобы перестроить в другом хосте, не делая apt-get снова, вам нужно:

docker pull custom-gource:0.1
docker build --cache-from=base_image:2.2.1,custom-gource:0.1 . -t custom-gource:0.2

Это может показаться слишком очевидным, но я долго боролся с этим, пока не понял, что вам тоже нужно включить базовое изображение

    Ничего не найдено.

Добавить ответ:
Отменить.