Всем привет. Есть докер-компоуз с сервисами. Стоит задача запустить их все, кроме одного. Потом уже в нужный момент дозапустить этот оставшийся контейнер. Не подскажите как можно это сделать?

А какая причина его тормозить?

Докер-композ не умеет в логику, потому или его в скрипт оборачивать, где явно такие сервисы запускаешь, а потом такой

Всем привет. Есть докер-компоуз с сервисами. Стоит задача запустить их все, кроме одного. Потом уже в нужный момент дозапустить этот оставшийся контейнер. Не подскажите как можно это сделать?

можно в команде запуска программы в этом контейнере прописть sleep 10

Либо в entrypoint клнтейнеру ожидание добавить

Всем привет. Есть докер-компоуз с сервисами. Стоит задача запустить их все, кроме одного. Потом уже в нужный момент дозапустить этот оставшийся контейнер. Не подскажите как можно это сделать?

не нужно

в компоузе для этого сервиса:`cmd: ['./run.sh']`. а в там уже sleep 10; exec gunicorn --foo-bar

ставьте restart on error

и ставьте пробовать 5 раз например

с интервалом в 30 секунд

я так понимаю проблема что бекенд стартует раньше базы

ещё можно настроить depends_on

улучшит ситуацию, но мне лично не помогло

потому что депенд он не дожидается пока команда в контейнере полностью запуститься

я везде слипы кидаю если очень нужно

Докер поднимается для тестов в CI и один из сервисов интерферирует с частью тестов.Поэтому нужно поднять часть сервисов - прогнать тесты, доподнимать и прогнать оставшиеся тесты. Все это из баш-скрипта запускается, так что видимо придется удалить проблемные сервисы из докер-компоуза и дозапускать их отдельно уже в нужный момент.

Или на основе записей в твоём домене например, тогда nginx не нужен вообще

Да вообще nginx нахер не нужен. Traefik и полетели

можно подлечить логику приложения

чтобы при старте пытался N секунд подключаться

такой способ сам докер советует

потому что депенд он не дожидается пока команда в контейнере полностью запуститься

Глупость

Докер поднимается для тестов в CI и один из сервисов интерферирует с частью тестов.Поэтому нужно поднять часть сервисов - прогнать тесты, доподнимать и прогнать оставшиеся тесты. Все это из баш-скрипта запускается, так что видимо придется удалить проблемные сервисы из докер-компоуза и дозапускать их отдельно уже в нужный момент.

так ты это как-то странно делаешь

Глупость

не глупость, зависит от того как контейнер реализован

Докер поднимается для тестов в CI и один из сервисов интерферирует с частью тестов.Поэтому нужно поднять часть сервисов - прогнать тесты, доподнимать и прогнать оставшиеся тесты. Все это из баш-скрипта запускается, так что видимо придется удалить проблемные сервисы из докер-компоуза и дозапускать их отдельно уже в нужный момент.

можно кинуть проблемный сервис в отдельный компоуз файл и указывать его когда он нужен

Расскажу. Делай depends_on: healthy и расставь хелсчек нормально

тесты - одно, развертывание приложения - другое

бывают приложения после старта приложения какую то важную логику стартуют (например миграции)

либо создать для тестов отдельный компоуз без него

Расскажу. Делай depends_on: healthy и расставь хелсчек нормально

Вообще бодрый способ

Но это сильно хрупкая логика - раз. Два - работает только во второй версии формата докер-компоуза (не третьей)

бывают приложения после старта приложения какую то важную логику стартуют (например миграции)

обычно это каким-нибудь ансиблом разрешают по человечачьи

бывают приложения после старта приложения какую то важную логику стартуют (например миграции)

Ну, и очевидно хелсчек подымать только после выполнения миграций

Ну, и очевидно хелсчек подымать только после выполнения миграций

+

обычно это каким-нибудь ансиблом разрешают по человечачьи

Ну, да, либо можно башем заебашить

ну или хоть в баш оборачивают, не надо пытаться из докер-композа логику получить)

у меня сейчас в тупую рестартит приложуху 5 раз каждые 30 секунд

если нет - выливка фейлится

Это тупо же утилита, которая docker run облегчает

можно кинуть проблемный сервис в отдельный компоуз файл и указывать его когда он нужен

Да, приходила в голову такая мысль. Просто думал, есть какие-нибудь ручки или хаки для такой ситуации. Спасибо.

Не надо из нее несвойственные задачи трясти

Да, приходила в голову такая мысль. Просто думал, есть какие-нибудь ручки или хаки для такой ситуации. Спасибо.

Смотри

Да, приходила в голову такая мысль. Просто думал, есть какие-нибудь ручки или хаки для такой ситуации. Спасибо.

не, логику уноси отдельно

Можно сделать вообще по красоте. Оберни все докеры в системд юниты. И делай любую логику старта

Можно сделать вообще по красоте. Оберни все докеры в системд юниты. И делай любую логику старта

сложнопереносимо

сложнопереносимо

Куда?

написать плейбук или башскрипт куда проще как по мне

Куда?

на другой сервер например, на 100 других серверов

Докер-компоуз ты в кубер тоже не затащишь

на другой сервер например, на 100 других серверов

Та пофиг. Докер не на системд бейзд дистрибутиве? Шутишь, да?

почему в кубер, просто развернуть приложение на 10 инстансах в aws например

просто делаешь скрипт/плейбук, складываешь вместе с кодом и юзаешь как надо

почему в кубер, просто развернуть приложение на 10 инстансах в aws например

Не вижу проблем с системд юнитами

просто делаешь скрипт/плейбук, складываешь вместе с кодом и юзаешь как надо

Плейбук для доставки конфигурации на целевые машины

а зачем они

есть же сварм

есть же сварм

Сворм говно

Сварм умер

ну лучше чем системд юниты )

Давай так. Отношение к докеру может быть разное

Мы его используем для двух вещей

Быстрая разработка и изоляция сервисов

И микросервисы (кубы, etc)

Первое - абсолютно не противоречит запуску на стендэлоун нодах

Вот представь себе гипотетический случай, что мой докер сервис потребляет файлы из нфс шары

Т.е. она сделана уже системд маунтом и нужно обеспечить старт сервиса только после маунта

Ваши предложения? Мигрировать все в s3?

так у докер драйвер есть

для нфс

Не вижу проблем с системд юнитами

Неудобно когда например нужно дать твой код другому разработчику, так в ридми пишешь - стартуешь some.sh , а с юнитом ему придётся себе ещё и юнит добавлять

Неудобно когда например нужно дать твой код другому разработчику, так в ридми пишешь - стартуешь some.sh , а с юнитом ему придётся себе ещё и юнит добавлять

Ну, переносимость Шелл скриптов вещь такая. У кого-то и бага может не быть

Например, эльпайн

У кого-то альпайн на машине стоит?)

Или мы столкнулись, что окружения на mac & linux по-разному фурыкают. В маке очень не хватает xargs -r

У кого-то альпайн на машине стоит?)

Это больше про ci/cd

не, я про ситуацию с локальной разработкой

В случае CI/CD вся эта логика уходит туда

Я тебе привел пример

Xargs

Скрипты ломаются

Только вот тех же юнитов на маке вроде как вообще нет

Там же наследник фряхи

В общем скрипт для локальной разработки, просто последовательный запуск сервисов через docker-compose

А в случае CI/CD эта фигня не нужна

Только вот тех же юнитов на маке вроде как вообще нет

К сожалению, у всего свои ограничения ?

В общем скрипт для локальной разработки, просто последовательный запуск сервисов через docker-compose

200% со слипами в нужных местах

ага

это точно работает везде

Но нам проще было makefile сделать, чтобы в нем же блоки для сборки контейнеров и запуска тестов описать

даже в powershell работает, если кто вдруг на винде сидит

У нас тесты только в гитлабе

А если кому прямо припрет, то может и локально ручками запустить

вот хороший пример применения миграций с хэлсчеками https://gist.github.com/pantsel/73d949774bd8e917bfd3d9745d71febf

вот хороший пример применения миграций с хэлсчеками https://gist.github.com/pantsel/73d949774bd8e917bfd3d9745d71febf

Пример плохой

Фактически хелсчеки в нем не используются для зависимости сервисов

Директива links вроде как obsolete

Что ещё покритиковать....