Compose: Depends_on в версии 3

depends_on все еще существует в v3, но зависимости проверки работоспособности (и, как следствие, расширенный синтаксис) не будут перенесены.

HTH

Но я написал docker-compose v3, и я пытаюсь развернуть его в swarm, но depends_on не работает, поскольку контейнер не запускается в том виде, в котором они должны быть запущены.

Вы используете docker-compose или docker stack deploy ?

Я использую развертывание стека докеров
и я пытаюсь развернуть его на рое из 7 машин

Что было бы эквивалентом в docker-compose v3 для достижения чего-то вроде зависимостей проверки работоспособности? Если вы собираетесь отказаться от этой функции в версии 3, ее никогда не следует использовать, или, по крайней мере, для этого должен быть путь миграции.

Каковы намерения ввести его в новую версию docker-compose v2.1, а затем отказаться от нее для v3? В настоящее время я настраиваю разные файлы compose для наших приложений, но я не хочу использовать функции, которые теряются в следующей версии и, следовательно, предотвращают обновление до более новой версии файла docker-compose.

На данный момент вы должны предполагать, что новый синтаксис depends_on не будет перенесен на версию 3, поскольку в настоящее время мы не планируем это делать.

Я знаю, что это не тот ответ, которого хотят многие люди, но я надеюсь, что это поможет, по крайней мере, внести некоторую ясность.

Могу я спросить, почему этого нет в планах? Полагаю, это было бы очень полезно.

Это дает ясность, но не объясняет. Не могли бы вы объяснить, почему? А об альтернативах (если они есть)?
Зависимость_on дает нам действительно простой способ зависеть от службы, а не обрабатывать ее внутри контейнера (что может означать обертывание стороннего изображения некоторым сценарием ожидания и необходимость его поддержки).

@ shin - зачем тогда вообще это реализовали в 2.1? Если люди будут использовать его и будут зависеть от него, они никогда не смогут обновиться. При всем уважении, это кажется очень плохим планированием со стороны ваших парней.

Так что же поддерживается depends_on синтаксис для v3? https://docs.docker.com/compose/compose-file/#version -3 не упоминает depends_on, и когда я использую docker-compose v1.10 для развертывания приложения, ни v2, ни v2.1 ароматыree_on не работают для я в файле v3 compose ...

@mustafaakin

Могу я спросить, почему этого нет в планах? Полагаю, это было бы очень полезно.

@hsmade

Не могли бы вы объяснить, почему? А об альтернативах (если они есть)?

С https://github.com/docker/docker/issues/30404#issuecomment -274825244

depends_on не работает при использовании с docker stack deploy . При выходе из строя службы режима Swarm перезапускаются, поэтому нет причин откладывать их запуск. Даже если они потерпят неудачу несколько раз, они в конечном итоге выздоровеют.

@brettmc

Итак, какой синтаксис зависит от версии 3?

При использовании docker-compose поддерживаемый синтаксис для v3 - это синтаксис списка (аналогичный синтаксису, используемому для 2.0). Если вы используете docker stack deploy , зависимости не будут соблюдаться (обоснование см. Выше)

Формат версии 3 - это первый шаг на пути от внешнего инструмента docker-compose к интегрированному решению docker stack . Текущая реализация имеет свои особенности, над которыми мы работаем. Поддержка формата версии 3 в docker-compose призвана помочь в этом переходе. С момента появления fig / Compose в Docker многое изменилось и улучшилось, а это означает, что многие вещи, которые раньше имели смысл, теперь устарели. docker stack - это новый старт с использованием новых концепций и избавления от некоторых из наиболее громоздких синтаксисов и концепций, от volumes_from до depends_on .
Если у вас есть особые опасения по поводу некоторых из этих изменений, сообщите о них в репозитории docker / docker, где они активно повторяются.
Если вы еще не готовы перейти на службы Docker и docker stack , не стесняйтесь продолжать использовать формат v2. Хотя разумно предположить, что проект в какой-то момент закроется, об этом будет объявлено заранее. И после этого код останется доступным и с открытым исходным кодом.

Благодарю. Теперь это имеет смысл.

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

ИМХО это не лучший подход. Не все службы могут должным образом обнаруживать, что другие службы, от которых они зависят, не готовы, они пытаются много раз, а затем терпят неудачу, поэтому контейнер может умереть позже. Нам все еще нужно ввести сценарии оболочки точки входа, что не очень хорошо. Зависимость Healthy-Check была очень приятной, но она просто не поддерживает режим роя.

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

Всем привет!
Означает ли это, что если, например, у меня есть служба, которая запускается и завершает свою работу очень быстро (и должна запускаться только один раз по замыслу), она будет запускаться снова и снова и снова ... многократно?

@ Marvel77 По умолчанию да, но вы можете переопределить это поведение с помощью раздела deploy.restart_policy : https://docs.docker.com/compose/compose-file/#restartpolicy

@ shin- Большое спасибо!

@mustafaakin На самом деле, лучшая практика (IMHO) - иметь отказоустойчивое соединение с сервисами, от которых вы зависите. Например, если вы используете базу данных, вы можете отложить запуск до тех пор, пока она не ответит. Но как справиться с перезапуском базы данных? Ваше приложение должно уметь восстанавливаться после этого, и тогда вам также не нужно зависеть от «depends_on».
В известном смысле отказ от поддержки - это хорошо. Эти удобства делают нас ленивыми.

@hsmade Но почти все init (upstart, systemd) зависят от отношений. Так что дело не в лени, а в том, что имеет смысл. Демон SSHD не запустится, пока ваше сетевое устройство не будет готово. У меня нет контроля над всеми имеющимися у меня системами, да, я могу сделать свои системы отказоустойчивыми. Но предположим, что A зависит от B. Для инициализации A требуется время, это не очень детерминировано. Итак, как вы можете написать политику перезапуска на B? перезапустить навсегда? Что делать, если вы этого не хотите?

Это более серьезная проблема, чем Compose, Compose просто запускает их. Swarm - это то, что заставляет их бегать, поэтому я думаю, что Swarm должен справиться с этой зависимостью от отношений со здоровьем.

@mustafaakin Я не думаю, что вы можете сравнить выполнение микросервисов в контейнерной среде с классическими системами инициализации. В этом нет никакого смысла. Я думаю, что идея микросервисов заключается в том, что они являются самодостаточными минимальными объектами. У них есть очень четкое определение своего API и т. Д. Они не должны предполагать какой-либо статус своего внешнего мира. Да, потребуется база данных, но нет, вы не можете предполагать, что она там есть. Как я пытался сказать, осознание того, что ваша зависимость существует при запуске, - это наименьшая из ваших проблем, более важно справиться с ней, когда она уйдет, а также должна решить первую.

Но опять же, это мои мысли по этому поводу, и я могу ошибаться;)

Да, это не имеет смысла для микросервисов, но не все является микросервисом, я запускаю Hadoop в контейнере. Докер предназначен не только для микросервисов. Как я уже сказал, это отлично подходит для сред, которые я контролирую, но для вещей, которые я не контролирую, требуется обертывание точки входа служб. Это было просто решено с помощью depends_on с healtcheck, я просто думаю, что было бы здорово иметь его и в Swarm. Сознательный перезапуск - выбор ленивого человека.

Ребята,

Я думаю, что существует своего рода неправильное представление об «отказоустойчивости» и о «первоначальной инициализации».
Согласитесь, что для первого подхода такой подход звучит неплохо, но второй - настоящая боль.
Я бы предположил, что не только мне, но и обычно нужно запускать службы в определенном порядке, поскольку они более или менее зависят друг от друга.

Постоянные перезапуски на этапе инициализации и ожидание запуска сервисов в определенный момент в правильном порядке сами по себе похожи на кошмар - нельзя планировать «простои» для процесса запуска, если случится худшее. Не только худшее, но иногда бывает, например, время «обслуживания», когда что-то нужно изменить, и никто не сможет предсказать, сколько времени потребуется системе для фактического запуска, потому что различные службы перезапускаются рой снова и снова. снова ждем надлежащего порядка.
Я пытался и ждал, чтобы увидеть, как он будет работать с 7 контейнерами, и в течение 20 минут _swarm_ все еще не понял этого, и вся служба все еще не работала.
Таким образом, невозможно даже указать, сколько времени потребуется, чтобы вернуть и восстановить всю инфраструктуру, поскольку действительно неизвестно, сколько времени займет _ первоначальный запуск_.
Для меня это звучит абсурдно.

Я не думаю, что смогу войти в «производство» без такой предсказуемости, даже если это должно происходить редко (полное падение) - лучше никогда не случиться.
Но если это все еще произойдет, я буду на месте и мне будет предложено восстановить как можно скорее, и именно в это время и под давлением я бы не имел абсолютно никакого представления, сколько времени мои контейнеры будут запускаться только потому, что они продолжают перезапускаться во время _startup._

@ozlatkov Это действительно должно быть размещено в системе

@ shin- Спасибо! Я переместил его в docker / docker tracker:

https://github.com/docker/docker/issues/31333

Я думаю, это действительно плохо, что команда Docker предполагает, что используется Docker Swarm. Compose - это полностью функциональный автономный инструмент.

Однако мы часто используем Docker Compose в наших конвейерах тестирования, и такое фундаментальное УДАЛЕНИЕ функций (без предоставления работоспособной альтернативы) действительно имеет драматические негативные последствия для ваших пользователей.

В настоящее время я просматриваю очень уродливый пиар от членов моей команды, когда они пытаются придумать всевозможные обходные пути для этого (поскольку мы сильно полагаемся на эту функциональность), в том числе оставаться на Compose 2.X на всю вечность.

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

Пожалуйста, пересмотрите возможность переноса всего этого в Docker Compose 3.

Очень признателен.

Уже в сотый раз: нет причин использовать формат v3, если вы не собираетесь использовать сервисы Swarm.

Означает ли это, что команда обязуется поддерживать форматы 2.X для тех, кто использует compose в качестве автономного инструмента разработки?

Собственно мой вопрос: привержена ли команда Compose вечной поддержке формата v2?

Мы не можем стандартизировать Docker Compose, если для формата v2 запланировано прекращение поддержки в любое время.

Я чувствую, что это заставляет все контейнеры использовать шаблон init container , удаляет политику перезапуска докера и создает хакерский подход к порядку запуска. Следует ли предполагать, что> = v3 compose будет двигаться в этом направлении, чтобы сосредоточиться на стеках и создании пакетов приложений? И если это так, не могли бы вы указать мне, как поддерживать порядок запуска в стеке докеров? Есть ли здесь подход wait-for-it.sh или dockerize ?

Что такое декларативный эквивалент docker-compose.yml для стека?

Привет, ребята, что лучше всего, если я собираюсь использовать стек докеров и избавиться от docker-compose?

Это , как представляется, решение, но имеющий вид Hacky сценариев для инициализации контейнеров не звучит как хорошая практика. Имеет ли это?

Благодарю.

@mustafaakin Спасибо за отрицательный голос! Очень полезно ❤️

@VinceOPS Я не уверен насчет «лучших практик», но я использовал проверки работоспособности и restart: always поэтому он просто циклически работает, пока не

@hutchic Но, как упоминалось в вышеупомянутом разговоре, у него не может быть конечной даты, что-то вроде циклического перезапуска при сбое.

Почему команда докеров удаляет эту функцию в версии 3 и отказывается добавлять ее?

@ tianhao-au см. обсуждение на https://github.com/moby/moby/issues/31333 (и https://github.com/moby/moby/issues/31333#issuecomment-409143581)

Для создания я также оставил предложение в https://github.com/moby/moby/issues/31333#issuecomment -333265696 (есть x-depends_on )

Это изменение функции буквально является причиной того, что я больше не использую docker-compose. Если я использую docker в производственной среде и docker-compose локально для среды разработки, мне теперь необходимо, чтобы мои докеры-контейнеры вели себя радикально иначе в dev, чем в производственной среде. В производстве я полагаюсь на систему оркестровки, чтобы гарантировать работоспособность и порядок моих развертываний. В мире разработчиков эта оркестровка выполнялась с помощью docker-compose. Сейчас я пишу кучу испорченных скриптов, чтобы проверить работоспособность вещей, чтобы организовать работу моей системы. Если я собираюсь это сделать, почему бы просто не написать немного голанга для управления моими докерами и покончить с этим. Немного загорелось уронили. Просто мой 2p

Попытка использовать последнюю версию docker-compose, чтобы сделать вещи более перспективными, и наткнулась на эту проблему. Это печально.