Docker Compose Startup Timeline Simulator
Построить граф зависимостей нескольких compose-файлов и посчитать реальное время старта с учётом healthcheck и pre_start.
Как это работает
У вас пять сервисов, три из них с healthcheck на 10 секунд, два с pre_start шагами, и весь этот зоопарк связан через depends_on с условием service_healthy. Вопрос "сколько реально займёт полный docker compose up от нуля до всех зелёных" не решается взглядом на файл — depends_on задаёт только порядок, а реальное время зависит от произведения interval, retries и того, сколько шагов pre_start выполняется последовательно перед каждым сервисом. Docker Compose Startup Timeline Simulator online строит граф зависимостей по одному или нескольким compose-файлам (base плюс override) и честно считает итоговое время запуска стека, а не гадает на глаз.
Спрашивать про это нейросеть — соблазнительная идея, только вот в реальный compose-файл обычно вписаны боевые пароли к базе, внутренние адреса сервисов и переменные окружения с токенами доступа, а вставлять всё это в чат стороннего API ради разового расчёта таймлайна — практика, за которую в компании со сколько-нибудь серьёзным compliance по паролям от прод-базы по головке не погладят. Плюс сам расчёт — это не эвристика, а точная арифметика по формуле накопления времени healthcheck (start_period плюс interval умножить на retries до первого успеха), и языковая модель тут с одинаковой уверенностью выдаёт как правильный ответ, так и правдоподобно звучащую отсебятину — сходство с правильным числом не гарантия правильности.
Алгоритм строит топологическую сортировку по depends_on, учитывает условия service_started, service_healthy и service_completed_successfully по отдельности (они дают принципиально разное время ожидания), суммирует последовательные шаги pre_start перед стартом каждого сервиса, и на выходе рисует таймлайн: во сколько секунд какой сервис реально стартует, а не просто список "кто от кого зависит".
Частые вопросы
Как учитывается condition service_healthy в расчёте времени?
Инструмент берёт значения start_period, interval, timeout и retries из healthcheck зависимого сервиса и считает минимальное время до первого успешного прохождения проверки: start_period плюс interval, умноженный на количество попыток, которое потребуется до первого успеха при благоприятном сценарии.
Разница между service_started и service_healthy в расчёте таймлайна принципиальна?
Да, огромная — service_started означает буквально момент запуска процесса контейнера, обычно доли секунды, а service_healthy ждёт полноценного прохождения healthcheck, что может занимать десятки секунд, путать эти два условия — частая причина недооценки реального времени старта стека.
Учитываются ли шаги pre_start в общем времени?
Да, шаги pre_start выполняются строго последовательно перед стартом основного контейнера сервиса, инструмент суммирует их оценочное время выполнения в общий таймлайн этого конкретного сервиса.
Что если в графе зависимостей есть цикл?
Инструмент обнаружит цикл при попытке топологической сортировки и явно сообщит об этом, вместо того чтобы зависнуть в бесконечном ожидании несуществующего порядка — цикл в depends_on это реальная ошибка конфигурации, которую Docker Compose тоже не запустит.
Можно ли посчитать таймлайн сразу для base и override файла вместе?
Да, инструмент принимает несколько файлов и мержит их структуру перед построением графа, аналогично тому, как это делает сам Docker Compose при использовании нескольких -f флагов.