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

Question

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

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

Возможно ли построить Dockerfile на втором компьютере, используя кеш из моего реестра? Если нет, есть ли способ ускорить создание «почти» одинаковых файлов Dockerfiles без написания моего собственного кеша?

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

Answer 1

для докер> 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 .

Тогда мы можем увидеть слои, содержащие изображение с кэшированием истории докер -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 inspect test | grep Parent.

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

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

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

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

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

Затем запустить docker load -i caching-test.tar. Если вы посмотрите на изображения, вы увидите busybox, а затем caching-test. Запуск docker history caching-test покажет вам тот же результат, что и при первоначальном построении изображения. Это связано с тем, что отношения между родителями и дочерними элементами сохранялись с помощью сохранения и загрузки. Вы даже можете запустить 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: Ниже это работает только Перед докер 1.10

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

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

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

Answer 2

Примечание: issue 20316 ("Pulling build cache") был закрыт, потому что PR 26839 ("Implement build cache based on history array") был объединен.

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

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

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

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

См merge commit 7944480, для docker 1.13 (January 2017).