docker run --pull=always, missing и never: разница режимов

Что происходит при режиме missing по умолчанию

При --pull=missing daemon сначала ищет image в локальном cache. Если reference найден, Docker использует его без обязательной проверки registry; если image отсутствует, CLI инициирует pull. Это удобно для разработки и локальных образов: повторный docker run не требует сети и не затирает локально собранный image одноимённым pull. Но с mutable тегом есть очевидный риск: наличие локального latest не означает, что это тот же digest, который сейчас опубликован в registry. Поэтому missing подходит, когда воспроизводимость обеспечена immutable digest/tagging или когда вы сознательно хотите использовать локальный cache. Для окружений, где каждый запуск должен сначала проверить registry, выбирают always. Для полностью офлайн или жёстко контролируемого cache — never.

Совет: Если важна воспроизводимость, лучше закреплять image digest; pull policy и immutable reference решают разные части задачи.

Сравнение always, missing и never

• missing. только если image нет локально. используется. разработка, локальные builds, cache
• always. pull инициируется перед запуском. может быть обновлён содержимым registry. получить актуальный registry image по тегу
• never. не используется для pull. обязателен. офлайн, заранее прогретый cache, запрет скрытых загрузок

Почему --pull=always не делает mutable tag безопасным релизным механизмом

always полезен, когда вы действительно хотите каждый раз тянуть reference из registry, но он не превращает latest в фиксированную версию. Два запуска в разное время могут получить разные digests под одним тегом. Если для rollback и аудита нужно знать точный артефакт, закрепляйте digest или неизменяемый version tag и храните его в deployment config. Кроме того, always может мешать локальной проверке образа: Docker документация предупреждает, что pull способен заменить одноимённый cached image содержимым registry. Поэтому перед локальным тестом image, который ещё не push-нут, missing обычно естественнее. В CI полезно разделить шаги: явно pull/build, вывести digest, а затем запускать контейнер из ожидаемого reference. Тогда сетевое поведение и происхождение image не скрыты внутри одной команды.

Предупреждение: Не используйте always как замену pin по digest: это «возьми актуальное по имени», а не «возьми проверенный артефакт».

Как выбрать policy для своего сценария

1. Для локально собранного image, который ещё не опубликован, используйте missing или явный уникальный local tag, чтобы случайный pull не заменил содержимое.
2. Для запуска по mutable registry tag, когда нужна именно текущая версия этого тега, используйте --pull=always и фиксируйте фактически полученный digest в логах/деплое.
3. Для изолированной сети или заранее прогретого cache используйте --pull=never. Отсутствующий image тогда вызовет явную ошибку вместо неожиданной сетевой попытки.
4. Для production-релиза по возможности замените latest на version tag или digest. После этого policy становится операционным выбором, а не способом угадывать версию.
5. Проверьте поведение на recreate: policy применяется при создании нового контейнера; уже работающий контейнер не меняет image сам из-за изменения тега в registry.

Важно: Если --pull=never дал No such image, это ожидаемое поведение: policy запрещает Docker скачать отсутствующий image.

Типичные ошибки в CI и на сервере

Первая ошибка — предполагать, что missing проверяет свежесть image в registry. Он проверяет прежде всего наличие локального image. Вторая — использовать always для локального тега, совпадающего с удалённым: можно протестировать не тот артефакт, который только что собрали. Третья — считать never режимом «использовать старую версию»: на самом деле он лишь запрещает pull и требует наличия reference в cache; какая именно версия там лежит, зависит от вашего процесса доставки image. Четвёртая — менять тег в registry и ждать, что существующий контейнер обновится автоматически. Контейнер уже связан с image, из которого был создан; нужен новый create/run или orchestration workflow. Разделяйте политику загрузки, версионирование и lifecycle контейнеров — тогда поведение становится предсказуемым.

Как сочетать pull policy с version tag и digest

Надёжный deployment обычно использует два уровня контроля. Первый — reference: version tag вроде app:1.8.3 или digest sha256:.., который определяет, какой артефакт ожидается. Второй — pull policy, который определяет, должен ли Docker обращаться к registry перед create. Если reference закреплён digest, --pull=always может подтвердить наличие/получить именно этот контент, но не переключит вас на другой digest под тем же именем. Если reference mutable, always намеренно допускает изменение содержимого между запусками. Для rollback сохраняйте фактический digest успешного релиза и не полагайтесь только на latest. В офлайн-среде --pull=never работает хорошо только вместе с отдельным процессом предварительной доставки image и проверкой digest. Иначе сервер может иметь непредсказуемый cache. В локальной разработке missing удобен, но стоит давать собственным builds уникальные теги, чтобы случайно не пересечься с registry-именем. Такое разделение делает поведение понятным без скрытых предположений о «свежести» тега.

Проверка перед production: какой digest реально будет запущен

Перед релизом полезно отделить вопрос “можно ли скачать image” от вопроса “какой именно image мы запускаем”. Если используете mutable tag, сначала выполните явный pull или run с выбранной policy, затем зафиксируйте digest через inspect и сохраните его рядом с версией релиза. При rollback используйте сохранённый digest или неизменяемый version tag, а не предположение, что latest всё ещё указывает на прежний слой. В air-gapped среде режим never имеет смысл только вместе с контролируемой предварительной доставкой образов; иначе два сервера с разным локальным cache могут запустить разные артефакты под одинаковым тегом. В разработке missing удобен, но локальные builds лучше помечать уникальным тегом, чтобы одно имя не означало одновременно локальный и registry image. В CI также полезно падать раньше, если ожидаемый digest не совпал. Так pull policy остаётся понятной сетевой политикой, а воспроизводимость обеспечивается отдельно через reference и проверку digest.

Что учитывать

always полезен, когда вы действительно хотите каждый раз тянуть reference из registry, но он не превращает latest в фиксированную версию. Два запуска в разное время могут получить разные digests под одним тегом. Если для rollback и аудита нужно знать точный артефакт, закрепляйте digest или неизменяемый version tag и храните его в deployment config. Кроме того, always может мешать локальной проверке образа: Docker документация предупреждает, что pull способен заменить одноимённый cached image…

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. docker container run). Пример и формулировки — редакция N1RO на 2026-09-22.

• docker container run