Что произойдет при запуске ENTRYPOINT без CMD?

Взаимодействие ENTRYPOINT и CMD в Docker

При запуске контейнера, если в Dockerfile определен только ENTRYPOINT, а CMD отсутствует, контейнер будет исполнять команду, указанную в ENTRYPOINT, без каких-либо аргументов по умолчанию. Это фундаментальное поведение, вытекающее из ролей этих инструкций в Docker.

Роли инструкций и их совместная работа

• ENTRYPOINT определяет исполняемую программу, которая будет запущена при старте контейнера. Её можно рассматривать как "неизменяемую" часть команды.
• CMD задаёт аргументы по умолчанию для этой программы. Эти аргументы могут быть легко переопределены пользователем при запуске контейнера через docker run.

Стандартная модель их взаимодействия выглядит так:

# Dockerfile
ENTRYPOINT ["executable", "param1", "param2"] # Базовая команда
CMD ["param3", "param4"]                       # Аргументы по умолчанию

При запуске контейнера без дополнительных аргументов выполнится: executable param1 param2 param3 param4. Если же пользователь укажет свои аргументы, например, docker run <image> arg5 arg6, то CMD будет полностью проигнорирован, и выполнится: executable param1 param2 arg5 arg6.

Сценарий: Только ENTRYPOINT

Когда CMD не объявлен, эта модель упрощается. Контейнер запустит команду из ENTRYPOINT в том виде, в котором она записана.

Пример Dockerfile:

FROM alpine:latest
ENTRYPOINT ["echo", "Hello from ENTRYPOINT"]

Сборка и запуск:

docker build -t entrypoint-only .
docker run entrypoint-only

Вывод: Hello from ENTRYPOINT

Ключевые последствия:

1. Нет аргументов по умолчанию: Пользователь не может просто добавить свои аргументы, чтобы они стали параметрами для команды в ENTRYPOINT. Например, docker run entrypoint-only World не сработает ожидаемым образом.
2. Переопределение ENTRYPOINT: Чтобы изменить поведение, пользователь должен явно переопределить ENTRYPOINT с помощью флага --entrypoint. Например:

   docker run --entrypoint sh entrypoint-only -c "echo Overridden"
   

3. Жёсткая конфигурация: Такой контейнер становится менее гибким. Он всегда выполняет одну и ту же команду с одними и теми же параметрами, что может быть полезно для создания специализированных, "одноцелевых" утилит или сервисов с фиксированным поведением (например, контейнер, который только копирует файлы или только делает ping).

Сравнение с другими сценариями

Для полноты картины рассмотрим иные комбинации:

• Только CMD: Команда из CMD может быть полностью переопределена аргументами в docker run. Это делает образ максимально гибким, но позволяет пользователю легко "сломать" ожидаемое поведение.
• Обе инструкции (рекомендуемый паттерн): Наиболее распространённый и гибкий подход. ENTRYPOINT задаёт стабильную основу (например, ["java", "-jar"]), а CMD предоставляет изменяемый аргумент (например, ["app.jar"]). Пользователь может как запустить контейнер с настройками по умолчанию, так и легко их изменить: docker run <image> custom-app.jar.

Практические рекомендации

• Используйте exec-форму (например, ENTRYPOINT ["executable", "param"]) вместо shell-формы (ENTRYPOINT executable param). Exec-форма обеспечивает, что ваш исполняемый файл получит сигналы ОС (например, SIGTERM при docker stop) и станет процессом с PID 1 внутри контейнера.
• Комбинация ENTRYPOINT + CMD — это лучшая практика для создания универсальных, production-готовых образов. Она сочетает предсказуемость (базовая команда фиксирована) с гибкостью (аргументы можно менять).
• Только ENTRYPOINT имеет право на жизнь в нишевых случаях, когда контейнер представляет собой законченную, неизменяемую утилиту.

Вывод: Запуск контейнера с только ENTRYPOINT приведёт к выполнению жёстко зашитой команды. Это лишает пользователя возможности гибко управлять аргументами запуска через CMD, что снижает универсальность образа, но может быть сознательным архитектурным решением для создания специализированных инструментов.