Сборка завершилась с exit code 100: диагностика APT в Dockerfile
Автор: Казачкин Даниил Михайлович · Обновлено
Строка did not complete successfully: exit code: 100 завершает отчёт о неудачной команде внутри сборки. Она не объясняет причину сама по себе. Если завершился apt-get, код 100 означает его ошибку; если выполнялась другая программа, сначала выясните её семантику. Научимся читать первую содержательную ошибку и воспроизведём неверное имя пакета.
Найти команду, которая вернула код
Запустите сборку с понятным текстовым выводом:
docker build --progress=plain -t yk-apt-example .Смотрите строку Dockerfile перед отказом и сообщения выше итоговой сводки. Unable to locate package, ошибка TLS, неверная подпись репозитория, DNS и отсутствие места требуют разных действий. Перезапуск с --no-cache может повторить проблему, но не заменяет объяснение. Код возврата APT.
Намеренно неверный Dockerfile
В новой пустой папке сохраните:
FROM debian:bookworm-slim
RUN apt-get update \
&& apt-get install -y --no-install-recommends yk-package-that-does-not-existПосле успешного получения индексов install не найдёт выдуманный пакет. Ожидается ненулевой результат и сообщение об имени, а не готовый образ. Если сеть недоступна и падает update, вы получили другую неисправность: не записывайте её как успешное воспроизведение случая отсутствующего пакета.
Исправленный вариант для реального пакета:
FROM debian:bookworm-slim
RUN apt-get update \
&& apt-get install -y --no-install-recommends ca-certificates \
&& rm -rf /var/lib/apt/lists/*Update и install находятся в одном RUN, чтобы старый закешированный индекс не отделялся от установки. Очистка lists уменьшает слой, но означает, что следующий install потребует нового update. -y здесь допустим в контролируемой сборке; на живом сервере сначала просматривают изменения. Dockerfile best practices.
Диагностическая развилка
| Первое сообщение | Следующая проверка |
|---|---|
| Unable to locate package | Имя пакета, успешность update, suite/component и архитектура |
| Temporary failure resolving | DNS/сеть среды BuildKit, proxy организации |
| Certificate verification failed | Время, доверенные CA, корпоративный TLS proxy |
| NO_PUBKEY или подпись недействительна | Официальный ключ/источник репозитория и срок действия |
| No space left on device | Диск, inode и расположение кеша builder |
| Version not found | Наличие зафиксированной версии в выбранном repository |
Не отключайте проверку подписи или TLS ради зелёной сборки. Это меняет проверяемость источника пакетов, а не устраняет устаревший ключ или неверную настройку proxy. Для проблемы зеркала уточните адрес и статус официального repository; случайная замена домена может дать другой состав пакетов.
Почему старый пример перестал работать
Тег базового образа может обновиться, пакет исчезнуть из текущего зеркала, а старый дистрибутив перейти в архив. Для стабильного артефакта фиксируют подходящий digest и управляют источниками зависимостей, но это требует регулярного обновления безопасности. Полная неизменность не появляется от одного --no-cache: этот параметр лишь запрещает повторное использование части результатов сборки.
Контрольная задача
Сохраните два отчёта: ошибку выдуманного пакета и успешную установку ca-certificates. Для каждого выпишите последнюю команду, первый диагностический текст и итоговый код. Объясните, почему число 100 не позволяет выбрать между DNS, подписью и именем пакета. Если ваш реальный RUN запускает script, раскройте его шаги и найдите программу-источник кода. Это переносит диагностику с общей строки Docker на конкретный слой сборки.