Коли щось не працює в Compose-оточенні, є стандартний порядок діагностики.
1. Стан сервісів:
docker compose ps -a
Колонки STATUS (Up, Exited (1), Restarting) і (healthy)/(unhealthy) одразу показують, який сервіс проблемний. Exited (137) - зазвичай вбито через нестачу пам'яті, Exited (1) - помилка застосунку.
2. Логи:
docker compose logs app # усі логи сервісу
docker compose logs -f --tail=100 app # останні 100 рядків і далі в реальному часі
docker compose logs --since 10m # усі сервіси за 10 хвилин
Видно лише те, що процес пише в stdout/stderr. Якщо Laravel пише в storage/logs/laravel.log, у docker compose logs цього не буде - для контейнерів краще LOG_CHANNEL=stderr.
3. Вхід у контейнер:
docker compose exec app sh
# усередині: перевірити файли, змінні, з'єднання
env | grep DB_
nc -zv postgres 5432
php artisan about
Якщо контейнер одразу падає і exec неможливий - запустити той самий образ з іншою командою:
docker compose run --rm --entrypoint sh app
4. Конфігурація й деталі:
docker compose config # що Compose реально застосовує
docker inspect $(docker compose ps -q app) # мережі, томи, змінні, healthcheck, причина зупинки
docker compose top # процеси в контейнерах
docker stats # пам'ять і CPU в реальному часі
Типові причини проблем і що перевірити:
- «Connection refused» до бази - використано
localhostзамість імені сервісу (DB_HOST=postgres), база ще не готова (healthcheck), сервіси в різних мережах; - зміни коду не видно - немає bind mount, кеш конфігурації Laravel (
php artisan optimize:clear), OPcache без перевірки часу змін; - права на файли - UID у контейнері не збігається з користувачем на хості;
- порт зайнятий - інший процес на хості вже слухає той самий порт;
- старий образ - після зміни
Dockerfileпотрібенdocker compose up --build.
Docker Desktop має графічний інтерфейс для логів, терміналу й файлів контейнера - зручно для швидкого огляду.