Как определить, что контейнер Docker готов принимать подключения?

Ну вот смотри, тут такая тема, блядь, интересная. Готовность контейнера — это не просто он запустился и уже пиздато. Это надо проверить, что он реально готов работать, а не просто процесс висит, как мёртвый груз. В продакшене я на это кладу болт с риском для карьеры, поэтому полагаюсь на health checks и проверку портов. Ёпта, без этого никуда.

1. Health Check прямо в Dockerfile: Тут всё просто, как три копейки. Задаёшь HEALTHCHECK на этапе сборки, и дальше Docker сам, сука, будет мониторить статус, как надзиратель за зеком.

FROM nginx:alpine
# Проверяет, отвечает ли Nginx на HTTP-запрос
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 
  CMD wget --quiet --tries=1 --spider http://localhost/ || exit 1

Запустил контейнер — и потом можешь тыкать команду, чтобы понять, что с ним:

docker inspect --format='{{.State.Health.Status}}' <container_name>
# Выдаст "starting", "healthy" или, что хуже всего, "unhealthy"

Если unhealthy — значит, контейнер нихрена не работает, хоть и запущен. Ядрёна вошь!

2. Использование wait-for-it или dockerize в entrypoint: А вот это, блядь, для случаев, когда твоё приложение зависит от других сервисов. Например, ждёт, пока база данных проснётся и перестанет тупить. Тут без скриптов — просто писец.

# Использование wait-for-it.sh
COPY wait-for-it.sh /wait-for-it.sh
RUN chmod +x /wait-for-it.sh
CMD ["/wait-for-it.sh", "db:5432", "--", "python", "app.py"]

Этот скрипт будет терпеливо, блядь, ждать, пока порт 5432 на хосте db не станет доступен, и только потом запустит твоё приложение. А то без этого начнётся пиздопроебибна: приложение падает, потому что база ещё спит.

3. Проверка в оркестраторах (Docker Compose/Kubernetes): Тут уже всё по-взрослому. В docker-compose.yml можно прописать healthcheck и зависимости между сервисами через depends_on. Это чтобы один контейнер не стартовал, пока другой не будет полностью здоров.

services:
  app:
    build: .
    depends_on:
      db:
        condition: service_healthy
  db:
    image: postgres
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5

Видишь? Сервис app будет ждать, пока db не станет healthy. Без этого — волнение ебать, всё полетит к чертям собачьим.

4. Прямая проверка порта: Ну а для простых, ебать, случаев, когда тебе надо в скрипте проверить, открылся ли порт, можно использовать nc (netcat) или вот такую хитрожопую bash-магию с /dev/tcp/.

# Проверка доступности порта 8080 в течение 60 секунд
timeout 60 bash -c 'until echo > /dev/tcp/localhost/8080; do sleep 2; done'

Эта команда будет пытаться дохуя раз подключиться к порту, пока не получится или не выйдет таймаут. Удобно и просто, как палка.

И главный принцип, который ты должен запомнить, как Отче наш: готовность приложения (application readiness) — это не просто процесс запустился. Это подтверждение, что он реально может обслуживать запросы, а не просто сидит и бздит. Иначе будет тебе, чувак, не хиросима, а настоящий нигерсраки в продакшене.