docker commit: сохранить изменения контейнера в новый образ

Зачем образы Docker неизменяемы

Docker-образы состоят из нескольких только для чтения слоёв. При запуске контейнера Docker добавляет тонкий записываемый слой поверх этих слоёв — слой контейнера. Все изменения происходят только в этом верхнем слое. Когда вы удаляете контейнер, изменения в этом слое исчезают, а исходный образ остаётся без изменений.

Преимущества такого подхода:

• Консистентность: каждый контейнер из одного образа ведёт себя одинаково.
• Изолированность: изменения в одном контейнере не влияют на другие.
• Безопасное версионирование: можно помечать образы тегами и быть уверенным в их состоянии.

Важно: такая архитектура ограничивает скорость внесения локальных правок в существующий контейнер. Чтобы сохранить изменения без переписывания Dockerfile, используется docker commit.

Создание нового образа из запущенного контейнера

Команда docker commit делает снимок текущей файловой системы контейнера и создаёт новый образ. Все установленные пакеты, изменённые конфигурации и файлы сохраняются в виде нового слоя. При этом исходный образ остаётся нетронутым.

Это полезно, когда нужно сохранить пользовательскую настройку для дальнейшего использования, внести небольшую правку во время тестирования или быстро поделиться обновлённым образом без пересборки Dockerfile.

Синтаксис команды:

docker commit [OPTIONS] CONTAINER_ID NEW_IMAGE_NAME[:TAG]

• CONTAINER_ID — ID или имя контейнера, который вы хотите зафиксировать.
• NEW_IMAGE_NAME — имя нового образа.
• TAG — опциональный тег (по умолчанию latest).

Примечание: docker commit — это устаревший алиас для docker container commit; обе команды идентичны.

Таблица поддерживаемых опций:

Пошаговый пример: как работает docker commit

Допустим, нужно установить curl в образ Alpine без изменения Dockerfile. Последовательность действий:

1. Запустите контейнер на основе образа:

docker run -it alpine:latest /bin/sh

2. Внутри контейнера выполните установку:

apk update && apk add curl

3. Выйдите из контейнера:

exit

4. Создайте новый образ из контейнера:

docker commit  alpine-with-curl:1.0

5. Проверьте, что образ появился:

docker images

Теперь образ alpine-with-curl:1.0 содержит curl и может запускаться в других средах.

Запуск нового образа и проверка изменений

Чтобы убедиться, что изменения сохранились, запустите контейнер из нового образа и проверьте версию curl:

docker run -it alpine-with-curl:1.0 /bin/sh

Внутри:

curl --version

Если curl установлен, значит коммит сработал и изменения персистентны.

Когда использовать docker commit, а когда Dockerfile

Dockerfile — лучший выбор для надёжных и воспроизводимых сборок. Он подходит для CI/CD и продакшен-сборок, потому что все шаги задокументированы в коде и легко версионируются. Это даёт прозрачность, возможность ревью и отката.

docker commit хорош для:

• Быстрых правок и отладки.
• Экспериментов и прототипов.
• Ситуаций, когда правка Dockerfile займёт слишком много времени.

Ограничения docker commit:

• Изменения не документированы автоматически в виде читаемого сценария сборки.
• Сложнее воспроизвести одну и ту же сборку в другом окружении.
• Не подходит для долгосрочного поддерживаемого образа в продакшене.

Важно: для продакшен-образов всегда отдавайте приоритет Dockerfile.

Когда docker commit терпит неудачу или не подходит

• Сложные зависимости: если вы внесли изменения вручную и забыли установить системные зависимости, образ может работать некорректно при деплое.
• Конфигурация окружения: изменения в runtime-файлах (секреты, временные пути) могут привести к небезопасным образам.
• Автоматизация: в CI/CD пайплайнах использование docker commit ломает воспроизводимость и трассируемость.

Counterexample: если вы отлаживаете баг, зависящий от точной последовательности пакетов и версий, лучше обновить Dockerfile и запустить повторную сборку, чем полагаться на ручной коммит.

Альтернативные подходы

• Редактировать и обновить Dockerfile, затем собрать образ через docker build.
• Использовать volume для хранения изменяемых данных и не включать их в образ.
• Применять конфигурационные инструменты (Ansible, Chef) для подготовки базовых образов.
• Использовать контейнерные слои через многослойные сборки (multi-stage builds) для уменьшения артефактов.

Безопасность и приватность

• Не включайте секреты, ключи или пароли во время коммита. Они попадут в новый образ и историю слоёв.
• Проверяйте метаданные образа: теги и сообщения коммита могут раскрывать чувствительную информацию.
• При необходимости выполните очистку перед коммитом (удалите временные файлы, логи, креденшелы).

Важно: считаются лучшей практикой — хранить секреты вне образа (например, в менеджере секретов или переменных окружения на этапе деплоя).

Мини-методология: быстрый playbook для безопасного коммита

1. В контейнере выполните только необходимые изменения.
2. Удалите временные файлы и секреты.
3. Выйдите из контейнера.
4. Выполните commit с сообщением и автором: docker commit -a "Dev" -m "Fixed X" repo/name:tag.
5. Протестируйте образ локально и в staging-площадке.
6. Задокументируйте изменения в репозитории (README или issue).

Чек-листы по ролям

Разработчик:

• Убедиться, что изменение минимально.
• Удалить креденшелы перед коммитом.
• Добавить понятное сообщение коммита.

Операторы/DevOps:

• Тестировать образ в staging.
• Проверить соответствие политике безопасности.
• Перенести изменения в Dockerfile для постоянной интеграции.

Команда QA:

• Выполнить регрессионное тестирование.
• Проверить конфигурации и логи.

Шаблон команды и примеры сообщений

• Команда: docker commit -a "Name" -m "Что сделано" repo/image:tag
• Хорошее сообщение: “Установлен curl и удалены временные файлы”.
• Плохое сообщение: “коммит” — неинформативно.

Критерии приёмки

• Новый образ запускается и предоставляет ожидаемый функционал.
• В образе отсутствуют секреты и временные файлы.
• Изменения задокументированы и перенесены в Dockerfile при необходимости.

Заключение

docker commit — удобный инструмент для быстрого сохранения состояния контейнера и тестирования исправлений. Он упрощает итерации при отладке и помогает быстро поделиться рабочим окружением. Однако для долгосрочной поддержки, безопасности и автоматизации предпочтительнее использовать Dockerfile и повторяемые сборки.

Краткое резюме:

• Используйте docker commit для прототипов и локальной отладки.
• Не храните секреты в образе.
• Для prod-сборок всегда переносите изменения в Dockerfile и интегрируйте в CI/CD.

Дополнительные ресурсы и команды для изучения: docker build, dockerfile reference, multi-stage builds, инструменты управления секретами.