Compose: docker-compose up не загружает последнее изображение, если оно существует локально

Есть ли причина, по которой docker-compose pull && docker-compose up нецелесообразно?

Я думаю, что большинство пунктов за / против совпадают с теми, которые обсуждались в вопросе о добавлении --pull к docker run . Они варьируются от ux и согласованности до простоты написания сценариев / рабочего процесса и интеграции роя (из любопытства, что docker-compose pull делает со роем?).
Я не думаю, что это серьезная проблема, но есть что подумать. Пользователи того же типа, которые хотели использовать эту функцию в другом месте, скорее всего, также оценят ее здесь.

Я пытаюсь выполнить сборку docker-compose, но она не обновляет образ, указанный в Dockerfile, за исключением случаев, когда вы используете _-- pull_.

Вы также можете создавать контейнеры во время запуска с помощью _up --build_. Но новейшие образы тянуть не будут. Можно ли ожидать sthg вроде "docker-compose up --build --pull" (или аналогичного)? Возможно, имеет смысл поместить его в YML, поскольку не все сборки нужно обновлять (см. Локальные изображения).

Вместо (или в дополнение к) добавления --pull в cli, как насчет добавления чего-либо в определение службы в файле docker-compose?, Например

version: '2'

services:

  postgres:
    image: postgres
    container_name: postgres
    pull: true
    ports:
     - '5432:5432'

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

Я пришел сюда в поисках этой функции, потому что мы используем ее в нашем производственном кластере Kubernetes. Там тегом является imagePullPolicy, и для него может быть установлено значение «IfNotPresent», «Всегда» или «Никогда». Было бы неплохо что-то подобное для среды создания.

В нашем случае нам необходимо каждый день перестраивать базовый образ, чтобы обеспечить обновление последних зависимостей для приложений. Docker compose up для получения последнего образа с тем же тегом - приятная функция. Почему нет !

Есть новости об этом?

Привет,

Есть новости по этому поводу?

+1

+1

Как я упоминал ранее, docker-compose pull && docker-compose up функционально идентичны. Нет веских причин для добавления еще одного флага.

Представьте, что в git нет pull потому что git fetch && git merge origin/master функционально идентичен.

Добавление тега pull: true может быть полезно, например, если некоторые изображения, которые вы используете в своем файле создания, находятся в вашем кеше. docker-compose pull pull _все_ изображения в вашем файле компоновки, и это извлечение не удастся, если эти изображения находятся в вашем кэше, но не в репозитории.

+1

Один сценарий, в котором docker-compose pull && docker-compose up становится непрактичным, - это когда вы используете несколько файлов docker-compose. Вы можете легко получить такую ​​команду, как docker-compose -f docker-compose.test.yml pull && docker-compose -f docker-compose.test.yml up .

У нас есть сценарий, в котором мы разрабатываем локально, и нам нужно получить только некоторые изображения с удаленного компьютера. Один (или несколько) разработанных на местном уровне должен остаться нетронутым. В этом случае мы обязаны создавать / извлекать образы вручную перед запуском docker-compose up.
pull: true было бы полезно.

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

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

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

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

Будем рады, если вы добавите эту функцию в новую версию.

@ shin - Я думаю, что @blockloop на примере git показал, насколько удобна / полезна опция pull. Честно говоря, надеюсь, что для таких вещей не нужно форкнуть какой-либо проект.

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

pull: IfNotPresent было бы неплохо. Таким образом, можно было бы использовать резервные варианты, такие как
1) использовать локальное изображение
2) тянуть, если не местный
3) строить, если не умеет тянуть

@ shin - ты все время спрашиваешь, почему метод && не помогает, и моя причина в следующем. Я использую его для изображения "приложения" для тестирования (Puppet PDK / Onceover). Файл набора является частью репозитория шаблона, поэтому, когда марионеточный разработчик (на самом деле, люди, работающие с оператором) должен создать новый модуль, они разветвляют это репо. Дженкинс запускает образ для проверки слияния в этом репозитории модуля (внутри у нас есть плагин jenkins, который обрабатывает обновление для заданий). Теперь люди, которые используют это, не будут экспертами по докерам, и необходимость сказать им выполнить && является дополнительным шаг, который они могут (и, вероятно, будут) облажаться. Я не понимаю, почему это будет сложно или какие неудобства это создаст, но это рассуждение кажется достойным поводом добавить его. Это помогает нам, разработчикам, отправлять вещи, требующие меньше указаний и шагов.

суть в том ... чтобы защитить от лени

Вот лучшая причина: && синхронно. Но в docker-compose встроена отличная поддержка параллельного исполнителя, который оптимизирует этот материал. docker-compose up --pull --build может начать создание образа и запустить его, как только он будет извлечен, вместо того, чтобы ждать, пока будут извлечены все изображения, и только затем начать сборку

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

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

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

Думаю, здесь обсуждаются два предложения:

1 - Следует ли добавить это как параметр командной строки? Собственно опубликованный выпуск.
2 - Следует ли добавить эту опцию в файл YML.

Я определенно согласен с последним, хотя @shin на самом деле не комментировал это. Отказаться от этого с тем же аргументом, что он функционально идентичен, было бы бессвязно. Все в файле YML функционально идентично командной строке.

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

@orodbhen не нужно спорить. Здесь нас никто не слушает.

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

@ shin-, повторно откройте или заблокируйте этот выпуск. Он был открыт почти два года, получая постоянные комментарии (как умные, так и развлекательные), десятки участников и сотни голосов.
Однако кажется очевидным, что команда compose не заинтересована в реализации этой функции. Так что давайте не будем терять чье-то время и давать ложные надежды на то, что проблема будет восстановлена, если это не так.

Пожалуйста, воздержитесь от ненормативной лексики.

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

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

@lig Не

В зависимости от ваших потребностей, разветвление может оказаться излишним. В моем конкретном случае я обнаружил, что Compose не очень хорошо подходит для написания сценариев, если только это не очень простой сценарий. Использование Docker Python API и моего собственного файла YAML для сохранения настроек более универсально и часто проще.

@ bdharrington7 - но вы должны поддерживать свою вилку и держать ее установленной на всех машинах, которые вы используете (что редко возможно). Предостережение: Docker Compose популярен, другие скажут: «Кому какое дело?»

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

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

«Мы должны уважать ответ @shin- по этому поводу и полагать, что есть веские причины не выполнять его».

просто не удовлетворит людей. Сообщество должно видеть «веские причины».

Дело в том, что стук кулаков и попрошайничество редко приводят к
в получении желаемого, много чего происходило в этой ветке.
В ветке также упоминалось множество хороших примеров использования,
но если вы на самом деле не платите за программное обеспечение, нет никаких обязательств
от сопровождающих, чтобы что-то с этим сделать и не объяснять почему. я
просто давая @ shin- и компанию возможность сомневаться в этом.
В субботу, 24 марта 2018 г., в 5:39 Грег Пэйкс [email protected] написал:

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

К сожалению, это всегда будет приводить к подобным проблемам с некоторыми
неудовлетворенность. Я думаю, что главная проблема здесь в том, что, похоже, нет
были правильным аргументом в пользу того, почему это плохая идея. В
аргумент "Мы должны уважать ответ @ shin- http: /// shin- по этому
и считаю, что есть веские причины не реализовывать его. "просто не
собирается удовлетворить людей. Сообщество должно видеть «веские причины».

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/compose/issues/3574#issuecomment-375805478 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AEV8Q9RseMxYS8KGyD9E2BK0pZv7OJpuks5thWt7gaJpZM4IyPQh
.

Дело в том, что стук кулаков и попрошайничество редко приводят к получению желаемого.

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

В ветке также упоминалось множество хороших примеров использования.

Я вижу один случай, который, по сути, сводится к тому, что «вместо этого вы можете выполнить эти две команды». Но явно люди этого не хотят. Так что вовлеките их и объясните, почему это хорошая работа.

Сопровождающие не обязаны что-либо делать с этим или объяснять причины, по которым

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

Какой продукт здесь бесплатный? Если я использую docker-compose.exe и запускаю docker EE, не означает ли это, что я действительно плачу за продукт?

ИМХО --build надо тянуть; нет необходимости в каком-либо другом флаге или конфигурации. если вы не хотите, чтобы он тянул, укажите версию изображения.

@ ET-CS: версии изображений - это только теги, и они все еще могут быть изменены на другой хэш

хороший момент @lifeofguenter, спасибо. может составить проверку, изменилось ли изображение на другой хэш, и потянуть в этом случае тоже?

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

Я ожидал, что --build доведет все до последней версии.

Итак, вот хороший вариант использования:

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

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

@agnjunio Звучит очень неудачно, извините. Однако, если человек забыл запустить docker-compose pull , я не уверен, почему он забыл использовать гипотетический флаг --pull менее вероятен?

@ shin - Извините, я забыл упомянуть важную вещь: решение в моем случае - иметь тег pull: always внутри yaml, возможно, внутри image: options

@ ET-CS с https://github.com/docker/compose/issues/3574#issuecomment -382451356:

Я ожидал, что --build доведет все до последней версии.

ИМХО - build должен тянуть; нет необходимости в каком-либо другом флаге или конфигурации. если вы не хотите, чтобы он тянул, укажите версию изображения.

AFAIK, который заблокировал бы вариант использования со сборкой с использованием FROM, который является результатом сборки depends_on .

version: "3.4"
services:
  some-base-image:
    image: our/base-image
    build:
      context: ./base
  # This Dockerfile has FROM our/base-image
  coolthing:
    depends_on:
    - some-base-image
    build:
      context: ./coolthing

Я за флаг, предложенный в https://github.com/docker/compose/issues/3574#issuecomment -252861859 и https://github.com/docker/compose/issues/3574#issuecomment -279460839

@solsson
Я не уверен, что понимаю, почему и что он блокирует в этом варианте использования.
пожалуйста, поделитесь дополнительной информацией об этом, если сможете.

@ shin - Разница здесь в том, что если я запустил docker-compose up --help я бы получил описательный способ использования изображения: latest, вместо этого в настоящее время мне приходится искать в документе или в Google, который приводит меня к этот поток, и мне нужно прочитать все комментарии, чтобы понять, что docker-compose up не делает то, что мне нужно / хочу, поэтому теперь мне нужно запустить две команды.

@agnjunio Звучит очень неудачно, извините. Однако, если человек забыл запустить docker-compose pull, я не уверен, почему он забыл использовать гипотетический флаг --pull с меньшей вероятностью?

Сердечно

Одна из основных причин, по которой мы используем docker-compose, - это возможность поместить файл docker-compose.yaml в репозиторий и получить воспроизводимый результат, когда разработчик извлекает репозиторий и запускает docker-compose up [service] .

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

Имея возможность разместить:

services:
  codegen:
    image: myimage:latest
    pull: Always

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

Дело не в том, что «функциональность уже существует, чтобы сделать это с помощью этих команд», это в лучшем пользовательском опыте.

Представьте, что когда кто-то предлагает добавить --stop к docker-compose rm , ответом было "что не так с docker-compose stop myapp && docker-compose rm myapp , или если кто-то запросил реализацию docker-compose down они просто спросили, почему docker-compose stop myapp && docker-compose rm -v myapp && docker-compose images -q myapp | xargs docker rmi ... непрактично?

Эта тема была поднята 2 года назад, и я все еще думал, что добавление флага в docker-compose.yml - лучший способ. В моем случае у нас около 37 сервисов в рое, и обновить 4-5 изображений из этого количества непросто. На данный момент я только что создал оболочку, которая может отслеживать изменения из репозитория и извлекать конкретное изображение перед воссозданием службы, если она была обновлена.

Еще один момент здесь заключается в том, что docker-compose up имеет параметр --quiet-pull . Когда я впервые пытался выяснить, включает ли up вытягивание, я предполагал, что это так, основываясь на его наличии. Причина в том, что неиспользование --quiet-pull приводит к подробному извлечению.

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

Может, нам стоит просто выполнить fork docker-compose и обновить его самостоятельно.

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

Я столкнулся с той же проблемой и черт возьми, тут куча нытиков. Это БЕСПЛАТНОЕ программное обеспечение с открытым исходным кодом. Дайте обслуживающему персоналу отдохнуть. Я уверен, что у них есть гораздо более важные дела, чем это. Если кому-то это так нужно, почему бы вам не открыть пиар? Если код чистый с минимальным риском, я не понимаю, почему они его не примут.

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

Тот факт, что эта «закрытая» проблема оставалась столь активной, говорит о том, что она не решалась должным образом.

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

Некоторые указали здесь, что это проект с открытым исходным кодом и (по крайней мере, большинство из нас) не платит клиентам. Однако стоит также отметить, что отправка отчетов о проблемах требует значительных временных затрат, особенно если вы участвуете в решении проблемы.

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

Программное обеспечение на самом деле не «БЕСПЛАТНО» в смысле «бесплатного пива». поскольку мы все пытаемся участвовать в его улучшении. Наличие людей, желающих протестировать ваше программное обеспечение и предоставить отзывы, является ценным ресурсом. Те, кто обладает необходимыми навыками программирования, даже готовы внести свой вклад в код, но им нужно какое-то указание на то, что их вклад приветствуется, прежде чем тратить на это время.

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

@ shin- Почему было реализовано "--build"? Это отличается от сборки docker-compose && docker-compose up? Просто пытаюсь понять философское различие между --build (которое было добавлено) и --pull (которое было сочтено избыточным). Понимание мыслительного процесса может помочь мне вспомнить, как все работает. И если проблема будет открыта, я с радостью отправлю PR. @everybodyelse ... неужели это "дух открытого исходного кода", который, если вам что-то не нравится, вы делаете форк? Я думал, что дух открытого исходного кода звучит так: «если вам что-то не нравится, вы: а) помогаете вносить свой вклад в требования, если это то, что вам нужно, б) помогайте вносить свой вклад в код, если можете», и что вы разветвлялись только в том случае, если ваши требования были очень очевидно, что только вы выиграете от этого. т.е. я думал, что мы больше всего выигрываем, когда делимся друг с другом, но я счастлив получить здесь образование.

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

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

Я ищу политику вытягивания изображений kubernetes в docker compose, было бы здорово, если бы можно было использовать «вытягивание».

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

Вы можете не согласиться со мной, но я разочарован тем, что вы прибегли к ad hominems, @Wenzil. Наше сообщество обычно придерживается более высоких стандартов.

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

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

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

Этот. И это не просто docker-compose. Docker-stack, docker-machine и docker-cli похожи.

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

Блокировка, поскольку это все время откладывается. Переоценим в зависимости от судьбы https://github.com/docker/cli/pull/1498

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