Что такое ENTRYPOINT в Dockerfile?

Question

Что такое ENTRYPOINT в Dockerfile?

Тип вопроса: Docker Вероятность: 24% Категория: Devops Инженер

Ответ

ENTRYPOINT — это инструкция Dockerfile, которая определяет исполняемую команду, всегда запускаемую при старте контейнера. Её основное назначение — сделать контейнер «исполняемым», как будто это бинарный файл.

Из моего опыта, ключевые отличия от CMD:

ENTRYPOINT задает фиксированную базовую команду.
Аргументы, переданные в docker run <image> <args>, добавляются в конец команды ENTRYPOINT.
CMD же задает аргументы по умолчанию для ENTRYPOINT или саму команду, если ENTRYPOINT не указан.

Практическое применение: Я использую ENTRYPOINT для wrapper-скриптов, которые выполняют предварительную настройку перед запуском основного приложения. Например, для подстановки переменных окружения в конфиги.

# Пример из практики: контейнер с приложением на Python
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY src/ .
COPY docker-entrypoint.sh .
RUN chmod +x docker-entrypoint.sh

# Основная логика инициализации вынесена в скрипт
ENTRYPOINT ["./docker-entrypoint.sh"]
# CMD задает аргументы по умолчанию для скрипта
CMD ["gunicorn", "app:app", "-b", "0.0.0.0:8000"]

Сценарии использования:

Исполняемый контейнер: ENTRYPOINT ["curl"]. Тогда docker run my-curl -I https://google.com выполнит curl -I https://google.com.
Запуск с фиксированными опциями: Гарантирует, что определенные флаги (например, --config) всегда будут переданы приложению.
Инициализация: Как в примере выше, для подготовки среды (ожидание БД, применение миграций).

Важно: ENTRYPOINT можно переопределить флагом --entrypoint в docker run, но на практике это делается редко.

Ответ 18+ 🔞

А, ENTRYPOINT! Ну это же, ёпта, самая соль, когда тебе надо сделать из контейнера не просто мешок с софтом, а прям исполняемую хрень, как бинарник. Представь, ты не запускаешь ОС в миниатюре, а запускаешь одну конкретную команду, и всё на этом.

Если по-простому, и чем он от CMD отличается:

ENTRYPOINT — это как будто ты зашиваешь в контейнер железную команду, его суть. Без неё он — манда с ушами.
Всё, что ты наберёшь после имени образа в docker run, прилепится в конец этой железной команды, как аргументы.
CMD же — это просто дефолтные аргументы на подхвате для ENTRYPOINT. А если ENTRYPOINT не задан, то CMD сам становится командой. Но доверия к такому подходу — ебать ноль, потому что его легче перебить.

Где это реально вкатывает: Я его юзаю, когда нужен вот этот самый враппер-скрипт. Ну знаешь, когда перед тем как основная прога стартанёт, надо ещё пол-операционки настроить: конфиги подшаманить, до базы допинговаться, миграции накатить — в общем, всю эту ебанько-инициализацию сделать.

# Вот реальный пример, чтоб не пиздеть. Питонячий контейнер.
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY src/ .
COPY docker-entrypoint.sh .
RUN chmod +x docker-entrypoint.sh

# Вся магия подготовки — тут, в скрипте. Это наше всё.
ENTRYPOINT ["./docker-entrypoint.sh"]
# А это просто дефолтные аргументы для скрипта, на случай если юзер ничего не указал.
CMD ["gunicorn", "app:app", "-b", "0.0.0.0:8000"]

Где это втыкают в реальной жизни:

Контейнер-утилита: Сделал образ с ENTRYPOINT ["curl"] — и всё, теперь docker run my-curl -I https://ya.ru выполнит ровно curl -I https://ya.ru. Удобно, ни хуя себе.
Жёсткие требования: Чтобы какие-нибудь обязательные флаги (типа --config=/etc/app/config.yaml) всегда летели с командой, даже если юзер — распиздяй и забыл.
Сценарий инициализации: Как раз тот случай со скриптом выше. Чтоб контейнер перед работой не бздел, а сделал всё как надо.

Важный момент на посошок: Его, конечно, можно перебить через docker run --entrypoint, но это уже из разряда «вилкой в глаз или в жопу раз». В нормальной жизни так не делают, только когда совсем припёрло.