Docker скачивает новое изображение для якобы кешированного дайджеста - PullRequest
Новая
       105

Docker скачивает новое изображение для якобы кешированного дайджеста

2 голосов
/ 03 мая 2020

Мой Dockerfile имеет этот первый шаг: 

FROM python:3.6.10@sha256:6cd232ed00e729b4d4d3aa57c1764dddfab70f616042b7f36536e2c3d70c4c11

Цель этого - , чтобы "заблокировать" или "закрепить" версию изображения .

Некоторое время docker build правильно использовал кэшированную версию: 

Step 1/2 : FROM python:3.6.10@sha256:6cd232ed00e729b4d4d3aa57c1764dddfab70f616042b7f36536e2c3d70c4c11
 ---> 114ae8bdb954

Но через некоторое время он решил "скачать более новый образ": 

Step 1/2 : FROM python:3.6.10@sha256:6cd232ed00e729b4d4d3aa57c1764dddfab70f616042b7f36536e2c3d70c4c11
sha256:6cd232ed00e729b4d4d3aa57c1764dddfab70f616042b7f36536e2c3d70c4c11: Pulling from library/python
7e2b2a5af8f6: Pulling fs layer
09b6f03ffac4: Pulling fs layer
dc3f0c679f0f: Pulling fs layer
fd4b47407fc3: Pulling fs layer
bb7b28578995: Pulling fs layer
6ebea4a9a306: Pulling fs layer
22a2327cd1ca: Pulling fs layer
bfbf91c84bbe: Pulling fs layer
f6b29b259c5c: Pulling fs layer
09b6f03ffac4: Verifying Checksum
09b6f03ffac4: Download complete
dc3f0c679f0f: Download complete
7e2b2a5af8f6: Verifying Checksum
7e2b2a5af8f6: Download complete
6ebea4a9a306: Verifying Checksum
6ebea4a9a306: Download complete
fd4b47407fc3: Verifying Checksum
fd4b47407fc3: Download complete
bfbf91c84bbe: Verifying Checksum
bfbf91c84bbe: Download complete
f6b29b259c5c: Verifying Checksum
f6b29b259c5c: Download complete
22a2327cd1ca: Verifying Checksum
22a2327cd1ca: Download complete
bb7b28578995: Verifying Checksum
bb7b28578995: Download complete
7e2b2a5af8f6: Pull complete
09b6f03ffac4: Pull complete
dc3f0c679f0f: Pull complete
fd4b47407fc3: Pull complete
bb7b28578995: Pull complete
6ebea4a9a306: Pull complete
22a2327cd1ca: Pull complete
bfbf91c84bbe: Pull complete
f6b29b259c5c: Pull complete
Digest: sha256:6cd232ed00e729b4d4d3aa57c1764dddfab70f616042b7f36536e2c3d70c4c11
Status: Downloaded newer image for python@sha256:6cd232ed00e729b4d4d3aa57c1764dddfab70f616042b7f36536e2c3d70c4c11
 ---> 114ae8bdb954

, хотя окончательный ha sh этого шага идентичен: 

 ---> 114ae8bdb954

Как я понимаю, дайджесты (sha256:...) являются неизменяемыми.
Так все же они изменчивы?
Или это было кэшированная версия как-то удалена?
Что происходит и как это исправить?

Ответы [ 2 ]

2 голосов
/ 10 мая 2020

Учитывая, что это не происходит при каждом запуске, и, скорее всего, этого не произойдет, если вы тестируете локально, проблема не в вашем файле Dockerfile или FROM. Docker не очищает кеш автоматически, поэтому вы захотите выяснить, какие внешние процессы удаляют кеш. Поскольку вы выполняете свои сборки в Jenkins с плагином kubernetes, проблема заключается в том, что этот плагин очищает агенты сборки после истечения времени ожидания. Из документации вы можете увидеть различные настройки для настройки этого компоновщика :

  • podRetention Управляет поведением хранения подчиненных модулей. Может быть «never ()», «onFailure ()», «always ()» или «default ()» - если пустым будет значение по умолчанию для удаления модуля после прохождения activeDeadlineSeconds.
  • activeDeadlineSeconds Если для podRetention установлено значение never () или onFailure (), модуль удаляется после истечения этого срока.
  • idleMinutes Позволяет модулю остаются активными для повторного использования до тех пор, пока не пройдет настроенное количество минут с момента выполнения последнего шага для него.

Один из способов обхода агентов эфемерной сборки - использовать параметр --cache-from в docker build команда. При использовании classi c build (против buildkit) вам сначала нужно получить это изображение локально. Это изображение будет из предыдущей сборки, и вы можете использовать несколько изображений для своего кэша, что особенно полезно для многоэтапных сборок, так как вам нужно будет извлекать кэш для каждого этапа. Этот флаг говорит docker доверять изображению, извлеченному из реестра, поскольку обычно доверяют только локально построенным изображениям (существует риск, что кто-то может внедрить вредоносное изображение, которое утверждает, что оно выполняет шаги в популярном образе, но включает в себя вредоносное ПО в архиве этого слой). * * тысяча двадцать пять

1 голос
/ 09 мая 2020

Существует два вида дайджестов: дайджест манифеста изображения в реестре и дайджест конфигурации JSON локального образа, который также содержит дайджест содержимого изображения.

Первый дайджест: python:3.6.10@sha256:6cd232ed00e729b4d4d3aa57c1764dddfab70f616042b7f36536e2c3d70c4c11 Дайджест манифеста в Docker Hub в качестве ссылки.

Дайджесты не являются изменяемыми.

Если две разные вещи дают одно и то же значение дайджеста, то функция ha sh (в данном случае используется sha256) будет нарушена и больше не сможет использоваться. См. Столкновение.

В вашем случае по какой-то причине он больше не находил кэшированное изображение. Он снова загрузил то же изображение.

Полученный дайджест в конце (---> 114ae8bdb954) является дайджестом для итоговой конфигурации для этого изображения (ID изображения).

Вы можете подтвердить, что правильный манифест был скачано: 

docker inspect 114ae8bdb954

Включено: 

"RepoDigests": [
            "python@sha256:6cd232ed00e729b4d4d3aa57c1764dddfab70f616042b7f36536e2c3d70c4c11"
        ],

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

Редактирование о кэшировании: если это сделано в сценарии docker -in- docker - он будет перестраивать этот образ всегда снова, если что-то изменится перед созданием сцены в родительском Docker.

Дополнительная информация об идентификаторе изображения: https://windsock.io/explaining-docker-image-ids/

...