Как прописывается процесс, который будет работать внутри Docker Container

Процесс внутри Docker-контейнера: принципы и практика

Процесс внутри Docker-контейнера описывается через Dockerfile с помощью инструкции CMD или ENTRYPOINT, которые определяют команду запуска. Контейнер живёт, пока работает его главный процесс (PID 1), поэтому его корректная настройка критически важна. Вот ключевые аспекты.

Основные инструкции для определения процесса

В Dockerfile используются две основные инструкции:

1. CMD — предоставляет аргументы по умолчанию для выполняемого процесса. Её можно переопределить при запуске контейнера.
2. ENTRYPOINT — задаёт фиксированную команду, к которой CMD добавляет аргументы. Часто используется совместно.

Пример базового Dockerfile для Python-приложения:

FROM python:3.9-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "app:app"]

Формы записи CMD и ENTRYPOINT

Инструкции можно записывать в shell-форме или exec-форме. Рекомендуется exec-форма, так как она обеспечивает правильную обработку сигналов (например, SIGTERM при docker stop).

• Shell-форма: CMD python app.py — выполняется через /bin/sh -c, процесс получает PID не 1, что мешает передаче сигналов.
• Exec-форма: CMD ["python", "app.py"] — процесс запускается напрямую, становится PID 1.

Пример с ENTRYPOINT и CMD:

ENTRYPOINT ["python"]
CMD ["app.py"]

При запуске docker run myimage выполнится python app.py, а docker run myimage test.py выполнит python test.py.

Особенности PID 1 и обработка сигналов

Процесс с PID 1 внутри контейнера требует особого внимания:

• Он не реагирует на стандартные сигналы (SIGTERM) по умолчанию, если не содержит обработчика.
• Для корректного завершения можно использовать init-системы (tini, dumb-init) или встроенную опцию Docker --init.

Пример с tini в Dockerfile:

# Установка tini как init-системы
RUN apt-get update && apt-get install -y tini
ENTRYPOINT ["/usr/bin/tini", "--"]
CMD ["python", "app.py"]

Или при запуске: docker run --init myimage.

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

• Минимализм: Используйте легковесные базовые образы (Alpine, slim-версии) и запускайте один процесс на контейнер для соблюдения принципов микросервисной архитектуры.
• Логирование: Направляйте логи процесса в stdout/stderr, чтобы Docker мог их собирать через docker logs.
• Здоровье: Добавляйте HEALTHCHECK для мониторинга работоспособности процесса.

Пример с HEALTHCHECK:

HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD curl -f http://localhost:8000/health || exit 1

• Переменные окружения: Используйте ENV для конфигурации процесса, избегая хардкода.

Пример продвинутого сценария

Сложное приложение может требовать предзапуска миграций БД. Используйте скрипт-обёртку:

entrypoint.sh:

#!/bin/bash
set -e

# Выполнение миграций
python manage.py migrate

# Запуск основного процесса
exec "$@"

Dockerfile:

COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "app:app"]

Отладка и мониторинг

• Для отладки запущенного процесса используйте docker exec -it <container> bash.
• Мониторинг ресурсов: docker stats.
• Проверка логов: docker logs -f <container>.

Правильная настройка процесса в контейнере — фундамент для стабильной работы приложений в Docker. Она влияет на оркестрацию, масштабирование и отказоустойчивость в средах Kubernetes или Docker Swarm.