Compose: Схема именования по умолчанию для контейнеров, созданных Compose

К сожалению, нет, извините.

То же самое и здесь. Эта функция слага должна быть необязательной. Насколько сложно передать флаг в команде up или build, чтобы отключить ее?

Я согласен - это должно быть необязательно. Некоторые программы, использующие Docker Compose, теперь запускаются только после перехода на версию 1.22.

Я согласен, это не обязательно. Нам вообще не нужна эта функция slug, и многие сценарии bash используют старый формат именования.

То же самое для нас, мы должны оставаться на 1.22, поскольку мы используем функцию «тома из» и полагаемся на старую схему именования. Пожалуйста, сделайте это дополнительной функцией в 1.24.

Эта функция затрудняет обращение к контейнерам после того, как они были подняты.

Я не понимаю смысла этого изменения. В настоящее время ни docker, ни compose не предлагают никаких сервисов обнаружения. Итак, если я хочу получить имя хоста из контейнера, что мне делать? Свернуть мое собственное обнаружение сервисов?

Кстати, каковы преимущества этого изменения? Неужели стоит ломать обратную совместимость?

Изменение имени _slug по умолчанию - правильный подход, но отсутствие способа отключить его с помощью переменной среды или параметра командной строки нарушает многие существующие рабочие процессы. Считайте, что это запрос функции, чтобы добавить какой-то флаг, чтобы вернуть поведение именования <= 1.22.0 docker-compose.

Извините, но "external_links" сейчас нельзя использовать. Я должен знать имя контейнера, чтобы связать его.
+1 за то, что сделал это необязательным

@ shin - это новое поведение полностью разрушает многое. До этого случайного slug можно было адресовать контейнер, запущенный из одного файла docker-compose внутри другого файла, например

services:
  app:
    image: app
    external_links:
      - "other-project_other-app_1:other-app"
networks:
  default:
    external:
      name: other-project_default

Вот и все. Теперь это вообще не сработает.

Как хоть эта вещь не необязательная?

Думаю, еще один шаг к смерти докеров.

Итак, есть обходной путь. Параметр container_name используется как есть, а slug не используется. По крайней мере, это помогает.

@ shin- пожалуйста, не считайте это отчетом об ошибке, что slug не используется с container_name . Оставьте как есть. Я буквально вешаюсь здесь.

О, парень! https://github.com/ansible/ansible/issues/47978

Хотя я понимаю, почему это изменение стоит за этим изменением, оно сильно мешает, тем более, что нет льготного периода, который хотя бы дал разработчикам время для корректировки своего сценария. Многие сценарии были написаны с учетом этого соглашения об именах, которое существовало буквально вечно. По сути, это изменение делает docker-compose 1.23 несовместимым с любыми другими docker-compose.

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

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

Обратно несовместимое изменение - это когда вы ломаете то, на что действительно полагается ваша пользовательская база. И неважно, какие были гарантии, ведь это все-таки Apache 2.0 и весь проект provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND . Ваши пользователи решают, на что они полагаются. И вы (вся команда) должны начать учиться узнавать, кто использует ваш проект, почему и как.

Во-вторых, вы должны узнать, как внести такие изменения в свою пользовательскую базу. Этот «случайный суффикс» определенно нарушает то, как ваши пользователи используют external_links и volumes_from . Таким образом, предупреждение об устаревании в случае отсутствия явного набора container_name или когда это выглядит так, было бы очень полезно. Пожалуйста, считайте эти документы знакомыми с тем, "что делают другие":

• https://www.python.org/dev/peps/pep-0004/
• http://api.mongodb.com/python/current/compatibility-policy.html
• https://docs.openstack.org/python-novaclient/pike/reference/deprecation-policy.html
• https://docs.djangoproject.com/en/dev/internals/release-process/#deprecation -policy

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

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

В-пятых, еще раз, мы все здесь ваши коллеги и друзья, а не враги, и мы действительно стараемся вам во всем этом помочь. И поскольку мы ваши друзья, исход из стека докеров будет болезненным, но в том смысле, что происходит сейчас, это прощание вовсе не выглядит нереалистичным.

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

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

Я пытался использовать директиву docker-compose container_name но это не повлияло на GitLab.
Но похоже, что на моей последней версии docker-compose на Mac Os Mojave он работает. Не уверен, что происходит :)

Мой файл .gitlabci.yml загружает последнее изображение из tmaier (должно быть 1.23.1).

Привет всем, несколько общих комментариев, которые, я надеюсь, решат некоторые из выраженных здесь опасений:

• Я определенно понимаю, что это ломает некоторые скрипты. В наших примечаниях к выпуску, начиная с 1.23.0-rc1, это сказано в самом начале. Это очень похоже на ситуацию типа «сдирания повязки», когда кратковременная боль помогает нам двигаться вперед, имея более здоровую основу.
• Преимущества текущего решения многочисленны и частично выражены в этой давней проблеме: # 1516 - и проблема с docker-compose run частности, упоминалась здесь несколько раз: # 4688 # 4549 # 5240
• Обнаружение службы не должно быть проблемой, поскольку ее следует обрабатывать с использованием имен служб (а не имен контейнеров) и сетевых псевдонимов, которые статичны в связанной с ними сети. Вы можете прочитать сетевые документы для более подробной информации об этом, в частности
• Я считаю, что это затрудняет использование volumes_from и external_links в проектах Compose. Учтите, что даже до этого изменения не было гарантии, что Compose будет соблюдать "ожидаемый" формат для данного имени контейнера (см., Например, # 6155 или префикс, упомянутый в # 3415), что делает его ошибочным решением, подверженным запуску в неясные проблемы в долгосрочной перспективе.
  
  
  
  • Рекомендуемый способ разрешить взаимодействие контейнеров из разных проектов состоит в том, чтобы они совместно использовали сеть external и использовали псевдонимы другой службы. Аналогичным образом, volumes_from в проектах должны использовать именованные тома external .
  
  
• Меня интересуют предложения о том, как лучше сообщить об этом изменении. Для справки: изменение было упомянуто в наших примечаниях к выпуску и доступно для тестирования с версии 1.23.0-rc1, которая была выпущена 26 сентября. Версия 1.23.0 GA была выпущена более месяца спустя, и, зная, что изменение будет спорным, мы помещаем это как большое предупреждение в начало журнала изменений. Если я мог бы сделать что-то еще, чтобы сделать это изменение видимым, я буду рад выслушать и сделать это в следующий раз, когда мы рассмотрим такое рискованное изменение, как это.
  
  
  
  • С другой стороны, если общий вывод здесь такой: «никогда не вносите критических изменений или позвольте мне отказаться от них на неопределенный срок», я уверен, что большинство из вас понимают, что это не здоровый и разумный способ о поддержке программного проекта размера Compose, который уже преодолевает множество трудностей, чтобы поддерживать обратную совместимость с широким спектром версий Docker Engine, форматов файлов Compose и устаревших идиом.
  
  

Сообщите мне, если что-то здесь не рассматривается. Я понимаю, что для многих из вас это серьезный «лежачий полицейский», и нервозность может вспыхнуть, когда мы имеем дело с непредвиденными обстоятельствами. Выделите время, необходимое для обновления, и пока закрепите свою версию Compose. С радостью отвечу на такие вопросы, как "Как сделать XYZ без предсказуемых имен?" до тех пор, в этой теме или на Slack. И, пожалуйста, будьте внимательны к тому, как вы взаимодействуете с другими на этих форумах, дважды проверьте правильность информации, которой вы делитесь (я уже видел, как там упоминались или перенаправлялись несколько тем, которые не имели ничего общего с этим изменением , что создает ненужное чувство тревоги и не помогает людям с проблемой, которые попадают сюда неправильно), и не мешает разговору. Спасибо за ваше время и терпение.

Что касается коммуникационной части, я ожидаю, что подобное изменение будет сообщено и объяснено через какой-то канал связи заранее, в основном так, как вы только что сделали это здесь, в этой ветке, объяснив, почему и что делать сейчас, но сделав это раньше все последствия.

@ shin- Вы не читали мой последний комментарий и ссылки, которые я предоставил, не так ли?

Последний из вас выглядит добрым, но чувствует то же самое.

Меня интересуют предложения о том, как лучше сообщить об этом изменении.

TL; DR

• Представьте новый version из docker-compose.yml
• Добавьте DeprecationWarning для external_links со ссылкой на документ, который описывает обновление и предоставляет образец решения для тех, кто хочет выполнить миграцию.
• Поддержите старое поведение для всех версий формата файла compose до новой.

Для справки: изменение упоминалось в наших примечаниях к выпуску.

Журнал изменений предназначен для участников. Пользователи его не читают. Пользователь устанавливает docker-compose и молится, что он все еще работает после вчерашнего дня.

С другой стороны, если общий вывод здесь такой: «никогда не вносите критических изменений или позвольте мне отказаться от них на неопределенный срок», я уверен, что большинство из вас понимают, что это не здоровый и разумный способ о поддержке программного проекта размера Compose, который уже преодолевает множество трудностей, чтобы поддерживать обратную совместимость с широким спектром версий Docker Engine, форматов файлов Compose и устаревших идиом.

У меня для тебя хорошая новость. Вы уже гарантировали, что «никогда не вносите критических изменений или позвольте мне отказаться от всех изменений на неопределенный срок». И еще, у вас есть для этого функция. Это version в файле docker-compose.yml . Итак, подумайте о том, чтобы как можно скорее отменить это изменение и ввести его для следующего номера version .

С радостью отвечу на такие вопросы, как "Как сделать XYZ без предсказуемых имен?" до тех пор, в этой теме или на Slack.

Пожалуйста, предоставьте решение для external_links и внешних томов без определения container_name (как мы видим, это не всегда работает) в другом docker-compose.yml в этом потоке.

Это популярный способ использования вашего проекта пользователями. Большинство ваших пользователей используют docker-compose для локальной разработки. Часто в разработке находится несколько взаимосвязанных проектов. В таком случае обычной практикой является направление нескольких файлов docker-compose в одну и ту же сеть и определение external_links для служб из разных проектов, чтобы иметь возможность связываться друг с другом на машине разработчика.

не мешайте разговору

@ shin: Все разговоры, которые я читал до сих пор с участием вас, сорваны из-за того, что вы ничего не делаете для решения проблем людей.

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

PS: Извините за очередной "оффтоп" комментарий. Не стесняйтесь заблокировать эту проблему, поскольку вас тоже используют.

Пожалуйста, предоставьте решение для external_links и внешних томов без определенного container_name (как мы видим, это не всегда работает) в другом docker-compose.yml в этом потоке.

Уже сделал, пожалуйста, обратитесь к моему предыдущему комментарию:

Рекомендуемый способ разрешить взаимодействие контейнеров из разных проектов - использовать общую сеть external и использовать псевдонимы другой службы. Точно так же volumes_from в проектах вместо этого следует использовать именованные тома external .

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

Честно говоря, @ shin-

Меня интересуют предложения о том, как лучше сообщить об этом изменении

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

Я здесь и хочу обсудить

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

PS. Отметьте это как оффтоп, продолжайте, покажите нам, как вы уважаете наше мнение. Больно видеть так много голосов за разные мнения?

Уже сделал, пожалуйста, обратитесь к моему предыдущему комментарию:

Я не вижу там рабочего образца решения, извините.

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

Извини, если тебе так хочется. Пожалуйста, рассмотрите возможность поддержки старого поведения для текущих версий файлов docker compose и представьте новую версию формата, которая будет вести себя по-новому. Это единственный вариант, который должен обеспечить хорошее решение для вашей пользовательской базы.

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

• https://github.com/docker/compose/issues/6316#issuecomment -438564025
• https://github.com/docker/compose/issues/6316#issuecomment -438934935

По поводу сообщений: мы получили обновление через Docker для Mac, и оно не показало никаких журналов изменений, указывающих на это изменение, поэтому потребовалось некоторое время, чтобы выяснить, почему изменились переменные среды.

Как только я узнал об этом, я воспользовался этим как возможностью обновить нашу конфигурацию с v1 до v3 и связать, используя имена служб вместо переменных среды, и это действительно сделало вещи намного чище 👍

FWIW, обратная совместимость для выполнения в контейнере, созданном командой compose:

docker container exec -it $(docker container ls -f name=expected -q) cmd

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

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

docker container exec -it $(docker container ls -f name=expected -q) cmd

Однако это не имеет ничего общего с docker-compose.

@lig Это работает с изменением имени expected созданного docker-compose. Этого обходного пути не существовало бы, если бы не изменение схемы именования.

@joebowbeer основная проблема после этого изменения линковкой между файлами docker-compose. Я вижу, есть способ найти контейнер, запущенный docker-compose через docker cmd. Но это небольшая помощь по теме :(

@ shin - Я думаю, мы все еще ждем объяснения, почему нам нужен docker composer для генерации имен контейнеров роевой линии.

Для меня совершенно очевидно, что никому в здравом уме не нужно использовать композитор для производственных целей. Compose - это мощный проект для локального тестирования. Я не вижу привлекательности в получении перка / функциональности docker swarm для инструмента, который широко используется только для локальных тестов. Если бы нам нужно было имя типа swarm для контейнеров, мы бы использовали swarm. Правильно?

Второй большой вопрос: почему это не было включено в качестве опции через аргумент? Я не вижу ни на одном из моих форумов и сообществ людей, которые хотели бы, чтобы такое поведение использовалось по умолчанию. Так что нам, вероятно, следует ввести его как новый аргумент: docker-compose up --slug . Просто, элегантно и не сломает ни одного скрипта.

  * On the flipside, if the general takeaway here is "don't make any breaking change ever, or let me opt out of all of them indefinitely", I'm sure most of you realize that it's not a healthy, reasonable way to go about maintaining a software project the size of Compose, which already jumps through a lot of hoops to maintain backward-compatibility with a wide array of Docker Engine versions, Compose file formats, and deprecated idioms.

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

Docker-compose, похоже, не имеет концепции основных версий, но я не вижу, как временная опция «отключить этот» (из командной строки или в файле создания) ограничена одним или двумя выпусками (1.23 и возможно, 1,24) будет составлять «бесконечно».

Учитывая, что это, похоже, связано с автоматическими обновлениями для пользователей, отличных от Linux, многие люди были застигнуты врасплох, и вместо того, чтобы оставить оставшуюся часть квартала до «запускать с этим флагом командной строки, пока мы обновляем наши сценарии» у нас есть целая куча разработчиков, которым приходится вручную понижать версию и / или отказываться от того, что они делают для обновления скриптов.

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

* Introduce the new `version` of the `docker-compose.yml` 
* Add `DeprecationWarning` for `external_links` with a link to a document which describes the update and provides a sample solution for those willing to migrate.
* Support the old behavior for all compose file format versions prior the new one.

Слишком много смысла ... понятия не имею, почему это не так.

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

@ shin - совершенно очевидно, что здесь нет никакого обсуждения, поскольку вы не учитываете представленные рациональные предложения. К тому же, если кто-то хулиганит - а вы - этим критическим изменением вы эффективно запугиваете многочисленных разработчиков по всему миру.

Многие люди (возможно, я и еще кто-то) не используют композицию для режима роя. Я указываю более низкую версию для своих файлов компоновки из-за проблем, которые у меня были в прошлом, когда предполагалось, что файл компоновки используется для определения сервисов для роя. Я полагал, что указанная мной версия была привязана к результатам, полученным на моем узле докера, и, заблокировав версию на каком-то низком уровне, я смогу получить согласованные результаты и по-прежнему принимать обновления для составления, чтобы оставаться совместимой с версией докера. Я бегу. Очевидно, я не могу ожидать здесь правильного управления версиями.

Можем ли мы докеризовать docker-compose, чтобы убедиться, что они внезапно не сломают наши вещи?

Я думаю, что лучшим решением было бы ввести новую опцию конфигурации в файл docker-compose.yml, где можно было бы отключить добавление части slug к именам контейнеров.

s / отключено / включено /. По крайней мере, в существующих версиях файлов Compose.

Это поведение необходимо связать с номером версии файла создания. Независимо от того, было ли это поведение «задано», оно довольно широко используется и, следовательно, является обратно несовместимым изменением. В любом случае, зачем обновлять спецификацию на этом этапе, если то, что делает файл набора, не будет работать таким же образом при обновлении моего двоичного файла? Устаревшая спецификация файла для компоновки (конечно, с большим количеством предупреждений, когда запускается docker-compose ), а затем удаление ее, определенно будет моей ошибкой, что все мои вещи больше не работают, но я ожидаю, что я прочту ваш релиз заметки для программы, которая имеет право выводить мне предупреждающие сообщения мне в лицо?

Внесение подобных изменений кажется довольно хорошей мотивацией для версионирования поведения спецификации в дополнение к ее формату: вы можете отказаться от допущений кода других людей с предупреждением. Я думаю, что количество внешних проблем, назвавших этот вопрос, говорит о том, насколько это удивило многих людей. Приятно видеть, как устаревшее поведение ломается, чтобы код не усложнялся, но подобные изменения нельзя применить сразу. Могу ли я ожидать, что другие предположения о составлении имен контейнеров нарушатся? Всегда ли имя службы будет в имени контейнера или его можно удалить, как предсказуемые имена?

Это действительно напоминает мне о том, когда согласованное именование сетевых устройств получило широкое распространение в Linux (но это противоположность именования ... idk). Много кода было жестко запрограммировано для ethN (и до сих пор в некоторых неожиданных местах), и это практически не изменилось. Существует, однако, способ вернуть старое поведение на Systemd систем (и на других системах, но она может изменяться), добавив net.ifnames=0 в аргументы ядра.

(Извините за напыщенную речь, но я не думаю, что моя первая была очень конструктивной.)

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

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

Изменить: см. # 6365 для получения дополнительной информации

Вау, какая ужасная перемена. 👎

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

Я тоже столкнулся с этой проблемой и хотел бы выразить свою рекомендацию относительно будущих обратно несовместимых изменений. У нас тоже есть сценарии, основанные на формате project_service_index, и многие люди используют эти сценарии на Mac. В идеальном мире мы могли бы контролировать версию Docker для Mac, которую используют люди, но пока люди обновляются, когда появляется диалоговое окно автоматического обновления.

Мои проблемы и рекомендации:

1) В диалоговом окне обновления не было никаких указаний на это существенное изменение, поэтому у нас не было очевидных предупреждений об этом изменении. В идеале мы бы проверяли все примечания к выпуску для каждого обновления, но на данный момент мы этого не делаем. Поэтому мы были бы очень признательны, если бы что-то подобное было явно вызвано в диалоговом окне обновления.

2) Из-за 1) явного предупреждения не было. Было бы здорово, если бы подобное изменение было внесено в предыдущее обновление. Например, при обновлении до последнего будет сказано что-то вроде «схема именования контейнеров изменится в следующей версии, пожалуйста, обновите свои скрипты».

3) Я понимаю, что после прочтения этой темы схема именования, которую мы используем, не гарантируется, и я понимаю, что есть более эффективные способы обращения к контейнерам. Тем не менее, у всех нас загружена рабочая жизнь, и нам необходимо планировать свои задачи, поэтому, как сопровождающий наши скрипты, я не могу сразу преобразовать наше использование имен контейнеров в нечто лучшее. Я счастлив использовать рекомендуемые передовые практики, но мне нужно время, чтобы перенести наш код. Поэтому было бы здорово иметь стратегию устаревания для такого изменения.

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

Люди не всегда используют программное обеспечение в точности так, как оно было задумано, и ответственность за их исправление лежит на этих людях, если их предположения терпят неудачу. Однако несколько простых сообщений могут помочь нам подготовиться к будущим изменениям и побудить нас перейти на новейшие передовые методы.

Если вы ранее зависели от docker container exec -it project_php_1 bash , вы больше не можете его использовать.

Вы должны использовать docker ps чтобы найти идентификатор службы.

Однако вы не можете использовать docker ps -q --filter=name=project_php потому что это будет соответствовать службам с именами project_php и project_php_xdebug или чему-либо еще, что соответствует project_php .

Ранее читаемый docker container exec -it project_php_1 bash теперь должен стать следующим:

docker container exec -it \
    $(docker ps -q \
        --filter label=com.docker.compose.project=project \
        --filter label=com.docker.compose.service=php) \
    bash

Это было плохо продуманным изменением.

@jtreminio FWIW, из проекта еще можно сделать docker-compose exec php

Спасибо всем, кто нашел время, чтобы поделиться своими мыслями об изменении. Мы согласны с тем, что это было плохо обработано и немного чрезмерно с нашей стороны, и это было частично отменено в Compose 1.23.2 (мы сохраняем случайные суффиксы для контейнеров, созданных docker-compose run , что позволяет нам обрабатывать их более изящно : # 4688 # 4549 # 5240, как и было задумано изначально).

Сообщите мне, если есть какие-либо нерешенные вопросы, которые необходимо решить.

Есть ли какой-либо план добавить параметр командной строки, чтобы отключить это --no-slug или, что более предпочтительно, --slug чтобы по умолчанию работать так же, как раньше.

1.23.2 вернуться к прежнему состоянию.

Он был отменен только для docker-compose up но не для docker-compose run

Спасибо за быстрое решение этого вопроса !!

28 ноября 2018 г. в 20:09 Джоффри Ф. [email protected] написал:

Спасибо всем, кто нашел время, чтобы поделиться своими мыслями об изменении. Мы согласны с тем, что это было плохо обработано и немного чрезмерно с нашей стороны, и это было частично отменено в Compose 1.23.2 (мы сохраняем случайные суффиксы для контейнеров, созданных при выполнении docker-compose run, что позволяет нам обрабатывать их более изящно: # 4688 # 4549 # 5240, как и предполагалось изначально).

Сообщите мне, если есть какие-либо нерешенные вопросы, которые необходимо решить.

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

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

https://github.com/docker/compose/issues/6316#issuecomment -442666873

изменено с <project>_<service>_<index> на <project>_<service>_<index>_<slug>

Это ошибка, а не функция.
Благодаря!
Подумайте о доступных сценариях, которые работают с ansible_connection=docker ... 😔 !!
следует ли явно указывать container_name ? или мы продолжим обновлять наш инвентарь случайными <slug> !!.
Действительно очень плохо!