Какой вариант использования? Большинство предложенных вариантов использования, которые я видел, были антипаттернами.

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

ooops, теперь я вижу "что-то" случилось с проблемой №2105, так как комментариев больше нет ...
Возможно, я дал неверную ссылку ...

поэтому я считаю действительно полезным скопировать некоторые файлы конфигурации / инициализации в контейнер. Например, некоторые файлы * .sql для контейнеров db, некоторое содержимое html / js / css для контейнеров apache / nginx или даже файл jar для контейнера java. Это сделает его доступным / запускаемым «глобально» не только на машине, на которой он был создан, как в случае монтируемых томов. В основном это будет комбинация файлов, локальных для хоста, и файлов, содержащихся в контейнере. Фактически любой контейнер можно считать бесполезным без какой-либо настройки или инициализации.

это правильная ссылка: https://github.com/docker/compose/issues/1664

+1

Это сделает его доступным / запускаемым "глобально" не только на машине, на которой он был создан, как в случае монтирования тома (ов).

Проблема в том, что это невероятно недальновидно (отсюда и термин «антишаблон»), так как вынуждает вас повторять операцию каждый раз, когда нужно воссоздавать контейнеры. Не говоря уже о том, что он очень плохо масштабируется (а если у вас 10 контейнеров? 20? 100?)

Фактическое решение вашей проблемы - включить эти необходимые файлы в вашу сборку (Dockerfile) и перестроить, когда потребуется обновление.

конечно, если он состоит из всего "общего" контента в контейнере, масштабирование 10-20-100-контейнеров будет намного проще. Все, что вам нужно, это вытащить его из репозитория и смонтировать (да, в этом случае смонтировать) только конфигурацию для конкретного узла. Более того, вам не нужно запускать docker-compose на каждом узле.
Конечно, мы можем использовать docker-compose в сочетании с build: & Dockerfile, однако все становится немного сложнее, и конфигурация yaml в docker-compose намного более «элегантна»: o)

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

Связанная проблема: # 1532

Обновить

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

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

Я не могу использовать том rw, потому что файловая система доступна только для чтения.
Я не могу использовать ro volume, потому что эффект будет тот же.

Было бы здорово делать записи, которые сохраняются только при запуске контейнера. Я могу сделать оболочку (https://stackoverflow.com/questions/36362233/can-a-dockerfile-extend-another-one) только для файлов COPY , но сделав это в компоновке, аналогично volume , было бы лучше

Пример использования: одновременный запуск нескольких контейнеров докеров из .gitlab-ci.yml, которые необходимо записать в каталог репозитория git.

Если процесс внутри контейнера завершается ошибкой или если задание ci отменяется до того, как контейнер очистится после себя, оставшиеся файлы не могут быть удалены с помощью gitlab-runner из-за отсутствия разрешений. Теперь я мог бы скопировать файлы в контейнере из тома в другой каталог, но это было бы антипаттерном, не так ли?

Это отличается от volumes: - ./folder_on_host/ :/folder_in_container/ ?
Я могу копировать файлы с хоста в контейнер (эквивалент COPY) таким образом в моем файле создания

@harpratap, вы правы, но недостаток в том, что / folder_in_container не должен существовать или должен быть пустым, иначе он будет перезаписан. Если у вас есть сценарий bash в качестве точки входа, вы можете обойти это, установив символическую ссылку на свои файлы в изначально предназначенный каталог после создания тома в / some_empty_location

+1 за наличие функции КОПИРОВАНИЯ. Наш вариант использования - быстрое создание локальных сред разработки и копирование конфигураций для настроек разработчика.

+1 за КОПИЮ. Это действительно было бы полезной функцией.

Пример использования: в режиме роя у меня есть служба, использующая образ mysql. Мне нужно скопировать мой скрипт инициализации в /docker-entrypoint-initdb.d/, чтобы MySQL мог их выполнить.

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

+1 за КОПИРОВАНИЕ / ДОБАВЛЕНИЕ,

Пример использования:
Fluentd требует, чтобы файлы конфигурации были перемещены в контейнер во время выполнения. Эти файлы конфигурации создаются во время выполнения нашим движком Jenkins, и без КОПИРОВАНИЯ / ДОБАВЛЕНИЯ в докере компоновка просто не выполняется.

+1 за КОПИЮ

Предположим, у кого-то есть общий файл конфигурации на нескольких машинах докеров, с их файлами Docker в соответствующих подкаталогах в каталоге docker-compose. Как скопировать эту общую конфигурацию в каждый образ? Я не могу создать символическую ссылку на ../ из контекста Dockerfile без получения COPY failed: Forbidden path outside the build context

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

Я буду рад, если кто-нибудь, конечно, может предложить чистый обходной путь.

Было бы неплохо иметь функцию !!

Пожалуйста, не комментируйте просто +1 - это пустая трата времени. Если у вас есть дополнительная информация, пожалуйста, сделайте это; в противном случае просто поставьте отметку "Нравится" за исходный выпуск.

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

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

Я думаю, что в данном случае то, что вы делаете, на самом деле является правильным.

Проблема, которая здесь возникла, была больше похожа на предположение, что файл mongo.conf использовался совместно тремя образами докеров, которые организованы одним файлом для создания докеров. Как вы гарантируете, что он одинаков во всех подкаталогах сборки докеров?

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

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

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

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

Надеюсь, я правильно истолковал ваш комментарий, и что мой ответ полезен.

@jpz - я как-то удалил свой оригинальный комментарий - ой - извините! Спасибо - да, это полезно.

Мой первоначальный комментарий был примерно таким:

Мой вариант использования заключается в том, что я хочу объявить службу с помощью mongo без необходимости создавать свое собственное изображение, просто чтобы скопировать файл конфигурации, например /etc/mongod.conf .

ОБНОВЛЕНИЕ: я использовал volumes . Год или два назад - я думал, что пробовал это с неудачным опытом ... но вроде нормально.

+1 за КОПИЮ

Я кратко изложил это. Предполагается, что служба создания докеров называется phpfpm , однако вы можете изменить это значение по своему усмотрению. не стесняйтесь изменять.
https://gist.github.com/markoshust/15efb29aa5eebf8adae402af18b2e674

Здравствуйте, я хотел бы знать, как продвигается эта проблема. Теперь я использую Windows 10 Home с docker-toolbox. В основном это ошибка, когда я пытаюсь связать файл монтирования как том в контейнер. Было бы неплохо иметь возможности КОПИРОВАНИЯ в docker-compose

КОПИРОВАНИЕ / ДОБАВЛЕНИЕ определенно будет желанной функцией.

Пример использования: запуск экземпляра Graylog в Docker для целей разработки. Для автоматического запуска ввода необходимо поместить спецификацию JSON в / usr / share / graylog / data / contentpacks.
С функцией КОПИРОВАТЬ / ДОБАВИТЬ сделать это так же просто, как одну строку в YML.

Чтобы он заработал сейчас (16 октября 2018 г.), необходимо подключить том к этой точке И скопировать исходное содержимое этой папки на постоянный том. Что довольно неудобно.

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

docker cp "${seed_file}" $(docker-compose ps -q devtools):/tmp/seed_file

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

Было бы разумнее сделать:

docker-compose cp "${seed_file}" devtools:/tmp/seed_file

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

1) похоже, это дубликат № 3593
2) я согласен с @ shin- в том, что разработанные варианты использования следуют анти-шаблону
3) но завершение команды Docker cp имеет смысл, имо

@funkyfuture Если вы считаете, что эти варианты использования следуют антипаттерну, предложите решение, которое не соответствует.

А как насчет k8s-like "data section" ?
Например:

services:
  service1:
    image: image.name
    data:
      filename1.ini: |
        [foo]
        var1=val1
        [bar]
        var2=val2
      filename2.yml: |
        foo:
          bar: val1

или, возможно, то же самое, но для раздела volumes:

volumes:
  service_config:
    data:
      filename1.ini: |
        [foo]
        var1=val1
        [bar]
        var2=val2

services:
  service1:
    image: image.name
    volumes:
      - service_config:/service/config

@ shin-

Проблема в том, что это невероятно недальновидно (отсюда и термин «антишаблон»), так как вынуждает вас повторять операцию каждый раз, когда нужно воссоздавать контейнеры. Не говоря уже о том, что он очень плохо масштабируется (а если у вас 10 контейнеров? 20? 100?)

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

Здесь я ищу способ скопировать мой файл конфигурации в контейнер, который я только что получил от dockerhub. У меня нет доступа к исходному файлу Docker, и было бы очень удобно иметь эту функцию (вместо того, чтобы пытаться построить еще один слой поверх, который работал бы, но неудобно, я не хочу перестраивать, когда что-то меняю).

Пример использования:

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

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

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

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

@tvedtorama -

Пример использования:

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

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

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

@ c0ze -

А как насчет k8s-like "data section" ?
Например:

...

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

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

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

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

Я предполагаю, что дискуссия заключается в том, насколько навязчивым может быть docker-compose? Достаточно ли это распространенный вариант использования, чтобы оправдать такую ​​автоматизацию? Если это не так, то мы, по-видимому, обременяем механизмы передачи переменных среды обязанностями по внедрению секретов извне из единого источника правды поздно (например, во время выполнения). Я надеюсь, что мои точки зрения здесь достаточно последовательны.

Для меня это не имеет большого значения, но я думаю, что этот вариант использования стоит обсудить.

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

Здравствуйте, мой вариант использования: я использую настройку Docker-compose Prometheus с открытым исходным кодом (репо поддерживается другими людьми). У него есть конфиги, которые монтируются в контейнеры. ПРОБЛЕМА: Я не могу выполнить docker-compose up на удаленной машине (например, aws docker-machine или внутри средства запуска CI / CD), потому что он не может правильно монтировать конфигурации. В этом случае я бы хотел скопировать / встроить их. Для данных RW есть объемы, для RO -?

Другой вариант - иметь объемы обратного осмоса с возможностью установки исходных данных.

Текущее решение: подключитесь к хосту докеров через ssh, клонируйте / обновите репозиторий и запустите docker-compose up. Это работает для ручного случая, но это боль для автоматизации :(

+1

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

1. Вытяните образ докера базы данных из extern.
2. Скопируйте и извлеките ZIP в работающий образ.
3. Выполните db-restore внутри тома.
4. Удалить дамп базы данных.

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

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

это все еще проблема?
У меня есть приложение django с очень длинным файлом настроек. Для меня было бы намного проще создать образ докера и скопировать один файл конфигурации в каждый контейнер.
Передача всех настроек как ENV для меня является антипаттерном. Занимает много кода, сложен в обслуживании и может быть решен с помощью одной команды копирования.

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

@ shin-

Проблема в том, что это невероятно недальновидно (отсюда и термин «антишаблон»), так как вынуждает вас повторять операцию каждый раз, когда нужно воссоздавать контейнеры. Не говоря уже о том, что он очень плохо масштабируется (а если у вас 10 контейнеров? 20? 100?)

Как работает docker-compose exec с несколькими контейнерами?

    --index=index     index of the container if there are multiple
                      instances of a service [default: 1]

Разве мы не должны попытаться добиться того же поведения с cp ?

IMHO exec столь же эфемерен, как cp . Но я всегда считаю это командами «разработки», ведь среды разработки должны быть эфемерными, не так ли?

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

Важно не то, что делает ваша программа, а то, что с ней делает пользователь.

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

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

Я думаю, вам следует тщательно взвешивать свои слова, говоря такие вещи ...

1. Мне действительно не нужна лекция о том, что мне разрешено говорить или писать. Мне очень жаль, что "недальновидность" вас обидела. По-прежнему можно сказать, что эти вещи изначально принадлежат Dockerfile.
2. Я больше не сопровождаю. Пожалуйста, прекратите @ -ing мне то, что я больше не контролирую.

1. Должен сказать, что я здесь на стороне crazycodr ... Отказ от совершенно корректных реальных вариантов использования как «антипаттерна», без предоставления полезных практических и реалистичных альтернатив - это недружелюбный подход разработчика и, честно говоря, даже немного грубый.
2. Сопровождающий или нет, но если вы принимали участие в обсуждении на github, вам в основном приходится жить с людьми, комментирующими ваши комментарии. Вот как это работает. Смирись с этим...

Вернем это. Честный технический вопрос здесь. Со стеком докеров у нас есть опция «конфиги». Это встроенная функция докера, но она предназначена для служб, а не для контейнеров. Какова возможность заставить что-то подобное работать на уровне контейнера, а не на уровне обслуживания? Как стек докеров реализует подготовку конфигурации? Можно ли воспроизвести эту реализацию специально для docker-compose?

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

Другой простой вариант использования - это проверка домена в Google. Если вы используете изображение wordpress, вы не можете добавить файл, который будет проверять Google. Для этого вам нужно создать совершенно новый образ.

Кроме того, эти комментарии о том, что вещи «антипаттерны», не имеют смысла, пахнут элитарностью.

РЕДАКТИРОВАТЬ: да, читайте дальше, слава богу, он больше не поддерживает

Итак, вы говорите мне, что если я хочу скопировать крошечный файл конфигурации в предварительно созданный образ (скажем, nginx или mariadb ), мне теперь нужно управлять настройкой сборки собственного образа и дублировать используемое дисковое пространство (исходный образ и настроенный образ)?

Это должно быть особенностью.

дублировать используемое дисковое пространство

вы не используете Docker.

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

Мне нравится, как вы придираетесь к одной вещи из того, что он сказал, а это самая незначительная вещь во всем этом.

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

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

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

Это просто элитарность. Многие комментарии здесь были по поводу того, насколько нелепы аргументы в пользу отказа от этого, и все они игнорируются.

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

Да, @robclancy , пожалуйста, оставьте это гражданским FFS. Мне нужна эта функция, но если все, что вы собираетесь делать, это болтать дерьмом с сопровождающими, выйдите на Reddit, пожалуйста. Более раннее исправление

в конце концов, это прошлые усилия @shin- с docker-py, которые позволили бы вам реализовать альтернативу docker-compose.

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

Если кто-то представит PR, будет ли это действительно рассмотрено? Или это то, что команда docker-compose решила не принимать? Вы бы рассмотрели что-то вроде добавления раздела конфигурации, совместимого с конфигурациями стека докеров ?

Это сошло с рельсов ... "анти-шаблон" без объяснения превращает "анти-шаблон" в очень широкое определение, с которым невозможно спорить. Также нет четкого направления, на какой стороне сидит «антипаттерн»; docker или docker-compose.

Четкое определение антипаттерновых ответов было бы фантастическим и очень ценно.

Сообщество будет продолжать расти, поэтому должен существовать установленный набор определений.

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

Сегодня я должен использовать

docker cp $(docker-compose -f docker-compose.development.ci.yml ps -q test):/app/tests_output ./tests_output

Это отличается от volumes: - ./folder_on_host/ :/folder_in_container/ ?
Я могу копировать файлы с хоста в контейнер (эквивалент COPY) таким образом в моем файле создания

Я пытаюсь сделать то же самое. У меня есть папка с файлом csv, и я хотел бы передать ее в logstash.
Как мне это сделать. или какая папка в контейнере?
на данный момент у меня есть что-то такое:
./path/to/storage:/usr/share/logstash/ data: ro

Любые предложения были бы полезны

@ shin- Этому билету уже 1,5 года. Когда 160 человек говорят вам, что вы неправы, вы, вероятно, ошибаетесь.

Что еще нужно, чтобы убедить вас, что это нужно реализовать?

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

@ shin- Этому билету уже 1,5 года. Когда 160 человек говорят вам, что вы неправы, вы, вероятно, ошибаетесь.

😆 🤣 💯 🥇 😲 😮

Также,

Я больше не сопровождаю. Пожалуйста, прекратите @ -ing мне то, что я больше не контролирую.

@sfuerte Есть небольшой проект Kubernetes, который уже заменил Docker-Compose. Интересно, случилось бы это, если бы отношение к отзывам пользователей было более позитивным.

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

Эта функция полностью будет pro-pattern . Это должно сработать. Разница в том, что, хотя я и сделал эту глупость, в этом выпуске есть много комментариев, демонстрирующих преимущества этого способа, которые явно являются обычными вариантами использования. И нет ни одного экземпляра anti-pattern .

@ shin - вы попали в этот список, потому что вы начали эту чушь антипаттернов без реальной основы. Так что перестань плакать о том, что ты причинил.

k получайте удовольствие

Мой случай:

• Во время «разработки» я хочу, чтобы мой исходный код был построен как «том», чтобы он автоматически обновлялся во время разработки.
• Когда приложение готово к выпуску и мне нужно «развернуть», я хочу скопировать скопированные файлы, а не тома.

Я думаю, что самый простой способ решить эту проблему - создать 1 файл для разработки и 1 файл для производства.

Проблема здесь в том, что я могу указать «тома» в файле докера, но не могу указать «копию» в файле докера?

Есть ли кто-нибудь в таком же деле, как и я? Я что-то упускаю?

@ shin- это антипаттерн? как бы вы подошли к решению этой проблемы?

@hems , в идеальном мире вы хотите, чтобы ваше приложение развертывалось как автономный образ докера. Поэтому, если вы пишете приложение, исходный код, который вы собираетесь развернуть, вероятно, должен быть частью Dockerfile , поэтому изображение содержит все ваше приложение. Итак, в Dockerfile , если вы хотите, чтобы ваш источник находился в / var / www, вы бы поместили

COPY my-app-src /var/www

Ваш источник не зависит от среды, поэтому он просто принадлежит образу докера. Легко.

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

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

COPY my-app-src /var/www

вот что я говорю: при разработке я хочу использовать свой файл docker-compose для монтирования ОБЪЕМОВ в образы, а во время производственной сборки я хочу КОПИРОВАТЬ файлы в изображения, поэтому я думаю, что мы должны иметь возможность КОПИРОВАТЬ и монтировать ОБЪЕМЫ используя файл docker-compose, поэтому у меня может быть 1 файл compose для dev и 1 для производственной сборки.

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

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

Файлы Compose используются для описания того, как набор служб развертывается и взаимодействует. Формат Compose используется не только для одного движка (например: docker-compose ), но также для оркестрованных сред, таких как Swarm и Kubernetes. Цель формата Compose - упростить написание приложения и его локальное тестирование, а затем развертывание в оркестрованной среде с небольшими изменениями или без них. Эта цель ограничивает то, что мы можем изменить в формате из-за фундаментальных различий, таких как то, как каждая среда обрабатывает тома и хранилище данных.

Подобное разделение обязанностей между Dockerfile и Compose файлом дает нам хорошее разделение проблем: что находится в каждом образе контейнера (Dockerfile), как службы развертываются и взаимодействуют (Compose file).

Теперь я рассмотрю каждое исключение из того, что вы храните в изображении. Что касается секретов, вы не хотите, чтобы они были встроены в изображения, так как они могут быть украдены, и потому что они могут измениться со временем. Для этого используются Docker Secrets . Они работают немного по-разному в зависимости от того, в какой среде вы развертываете, но, по сути, идея состоит в том, что вы можете хранить учетные данные в файле, который будет монтироваться только для чтения в каталог tmpfs в контейнере во время выполнения. Обратите внимание, что этот каталог всегда будет /run/secrets/ а файл будет именем секрета. Секреты поддерживаются в Swarm, только движке ( docker-compose ) и Kubernetes.

Для файлов конфигурации или данных начальной загрузки существует Docker Configs . Они работают аналогично секретам, но могут быть установлены где угодно. Они поддерживаются Swarm и Kubernetes, но не docker-compose . Я считаю, что нам следует добавить поддержку для них, и это поможет в некоторых случаях использования, перечисленных в этом выпуске.

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

Таким образом, я могу ответить на пару вопросов:

• Добавим ли мы поле copy в формат Compose? Нет, я не думаю, что мы будем, потому что это не имеет смысла в оркестрованной среде.
• Добавим ли мы поддержку configs к docker-compose ? Да, думаю, надо.
• Мы добавим docker-compose cp ? Может, я еще не уверен в этом. По сути, это был бы псевдоним для docker container cp .

Учитывая это, здесь можно использовать несколько инструментов:

• Многоступенчатые сборки, которые позволяют условно добавлять файлы к изображению с помощью целей.
• Секреты, которые позволяют передавать учетные данные в службу во время выполнения.
• Конфигурации, которые позволяют передавать информацию о конфигурации в службу во время выполнения.

Я _ думаю_, что эти инструменты решают все проблемы, поднятые в этой теме.

Эта нить довольно сильно нагревается. Пожалуйста, помните, что за каждым дескриптором GitHub стоит настоящий живой человек и что он, вероятно, старается изо всех сил (даже если его разочарование проявляется). Мы все увлечены Compose и хотим, чтобы проект продолжал развиваться.

Мы добавим docker-compose cp ? Может, я еще не уверен в этом.

я бы нашел это полезным удобством, например docker-compose exec .

@ chris-crone Замечательный ответ, спасибо!

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

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

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

Я сомневаюсь в этом, поскольку подозреваю, что большинство здесь не использует Swarm, и, черт возьми, этого требует функциональность config .

Да, в настоящее время требуется Swarm, но из комментария @chris-crone ...

Они поддерживаются Swarm и Kubernetes, но не docker-compose. Я считаю, что нам следует добавить поддержку для них, и это поможет в некоторых случаях использования, перечисленных в этом выпуске.

... Я читаю, что это можно реализовать в docker-compose (без Swarm)

Цель формата Compose - упростить написание приложения и его локальное тестирование, а затем развертывание в оркестрованной среде с небольшими изменениями или без них.

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

Swarm и config на самом деле не подходят для некоторых из перечисленных вариантов использования. «Разделение проблем» также не применимо, поскольку compose уже делает то, что вы можете делать в докере, но упрощает его. Обертка - это не разделение ... мы просто просим вас немного расширить ее ...

https://github.com/docker/compose/issues/6643

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

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

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

Думаю, все это понимают! Вопрос в том, делает ли docker-compose
разработчик нашел время, чтобы зачитать случаи и понять потребности? Есть
здесь нет антипаттернов теоретически, просто разработчики, которые нуждаются и хотели бы
быть уважаемым.

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

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

Важно не то, что делает ваше программное обеспечение, а то, что делают ваши пользователи.
с этим имеет значение

Приветствую и счастливой преемственности!
ᐧ

В четверг, 6 июня 2019 г., в 10:55, jadon1979 [email protected] написал:

Цель формата Compose - упростить написание приложения.
и протестируйте его локально, а затем разверните в оркестрованной среде с
мало или совсем нет изменений.

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

Swarm и config на самом деле не ответят на несколько вариантов использования
перечисленные. «Разделение интересов» также не применимо, поскольку уже составлено
делает то, что вы можете делать в докере, но упрощает его. Обертка не
разделение ... мы просто просим вас продлить его еще немного ...

6643 https://github.com/docker/compose/issues/6643

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

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/compose/issues/5523?email_source=notifications&email_token=ABBR3OMQH62242SM4QN5Y7TPZEQP7A5CNFSM4EKAVONKYY3PNVWWK3TUL52HS4DFVREXWORDP2KVMVQ5
или отключить поток
https://github.com/notifications/unsubscribe-auth/ABBR3OMOZFZ47L6ITHPF2TDPZEQP7ANCNFSM4EKAVONA
.

Я хочу развернуть среду Docker Tomcat для запуска моего приложения из .war, который не называется ROOT.war . Для этого мне нужно скопировать его в каталог Tomcat webapps и переименовать в ROOT, чтобы он работал на текущих портах 8005/9. Все остальное не удается из-за проблем с повторным связыванием на портах с ошибками о «незаконном доступе». Это эфемерные тестовые сборки, поэтому они не могут быть помещены в Dockerfile. Вот почему я хочу его в docker-compose

@washtubs

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

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

@washtubs @funkyfuture

... Я читаю, что это можно реализовать в docker-compose (без Swarm)

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

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

Вам нужен контейнер, который создается один раз (желательно официально) и настраивается для конкретного варианта использования в момент использования, то есть docker-compose.

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

Dockerfile фактически предотвращает обычную отладку и уборку, которые были бы доступны, если бы вы использовали скрипт сборки или что-то, действительно предназначенное для сборки, например ... диспетчер пакетов или make.

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

И никакая "поддержка конфигов" его совсем не режет, навязывая структуру там, где она просто не нужна.

Основная проблема заключается в том, что если вы привязываете mount, чтобы сказать / etc / nginx, он должен быть rw, чтобы разрешить запуск скриптов, регулирующих конфигурации (также известный как envsubst). И это затем вносит изменения во входную конфигурацию (которая должна оставаться неизменной) ... Вы не получите гораздо большего антипаттерна, чем контейнер, записывающий всю свою конфигурацию, поэтому опция для копирования файлов в контейнер во время повторного создания является необходимой решение.

Другими словами, это каталог монтирования привязки rw в контейнере, но ro на хосте. Серьезно, это убьет вас, если вы позволите это?

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

Вам нужен контейнер, который создается один раз (желательно официально) и настраивается для конкретного варианта использования в момент использования, то есть docker-compose.

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

Dockerfile фактически предотвращает обычную отладку и уборку, которые были бы доступны, если бы вы использовали скрипт сборки или что-то, действительно предназначенное для сборки, например ... диспетчер пакетов или make.

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

И никакая "поддержка конфигов" его совсем не режет, навязывая структуру там, где она просто не нужна.

Основная проблема заключается в том, что если вы привязываете mount, чтобы сказать / etc / nginx, он должен быть rw, чтобы разрешить запуск скриптов, регулирующих конфигурации (также известный как envsubst). И это затем вносит изменения во входную конфигурацию (которая должна оставаться неизменной) ... Вы не получите гораздо большего антипаттерна, чем контейнер, записывающий всю свою конфигурацию, поэтому опция для копирования файлов в контейнер во время повторного создания является необходимой решение.

Другими словами, это каталог монтирования привязки rw в контейнере, но ro на хосте. Серьезно, это убьет вас, если вы позволите это?

Что-то вроде этого:

``

если файл перезаписать

если каталог, то перезаписать / добавить содержимое пункта назначения

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

источник: файл : разрешение: владелец : группа

svc:
копия:
- './source/filename:/path/ filename: ro : www-data'
- './source/dir:/path/ dir: ro : www-data'

# или же
svc:
копия:
- источник: './source/file'
пункт назначения: '/ пункт назначения'
разрешение: ro
владелец: владелец
группа: группа
- источник: './source/directory'
пункт назначения: '/ пункт назначения'
разрешение: ro
владелец: владелец
группа: группа

Пример использования: у нас есть неорганизованное контейнерное решение, в котором есть файлы docker-compose нашего приложения, включая. SSL-сертификаты и т. Д. Внутри Git-репозитория и перенос его на виртуальную машину. Затем мы запускаем службу и хотим переместить, например, сертификаты SSL, файлы конфигурации и т. Д. В том контейнера. В настоящее время это невозможно без прилагаемого Dockerfile с функцией COPY. Мы не хотим возиться с файлами внутри клонированного репозитория git. Если приложение будет изменять файлы, нам придется каждый раз очищать репо.

@MartinMajewski, затем вы можете смонтировать каталог с сертификатами в качестве тома и указать его в конфигурации вашего приложения.

Вариант использования (и сразу вопрос с инструкциями):
У меня есть изображение postgres с одной переменной среды, которая должна быть установлена ​​при запуске: POSTGRES_PASSWORD . Я хочу установить его через Docker Secret. Что мне нужно сделать, это просто поместить свой собственный entrypoint.sh который будет экспортировать прикрепленный секрет в env var запущенного контейнера. Мне нужно как-то добавить эту точку входа в мой контейнер при запуске. Без двухстрочного Dockerbuild - не могу. Копирование одного-единственного файла - сделать нельзя.

PS postgres - это пример. Предположим, он не поддерживает переменные _FILE env.

Проблема внутреннего отслеживания https://docker.atlassian.net/browse/COMPOSE-89

Пример использования: Караф
Используя базовый образ karaf, который я не хочу перестраивать каждый раз, когда я создаю свой проект, я хочу иметь возможность быстро развернуть свое приложение и перестраивать контейнер для каждой сборки. Однако мне нужно скопировать _features.xml_ и _jar_ в каталог развертывания при запуске контейнера.

До сих пор мое решение заключалось в использовании образа karaf в качестве базового образа в еще одном файле Dockerfile (полагаясь на overlayfs - в котором в конечном итоге заканчиваются наложения, что приводит к ручному удалению изображения) и avast / gradle-docker-compose-plugin. Хотя команды инициализации, безусловно, могут быть переданы как переменная среды, содержимое файла features.xml не может. Он должен храниться в виде файла в определенном месте в контейнере. Прямо сейчас я могу использовать для этого только привязку тома. Как мне поместить данные в этот том на удаленной машине? Мне нужно еще больше логики в моем скрипте сборки (например, org.hidetake.groovy.ssh, который также усложняет скрипт сборки секретным паролем / логикой ключа). Если бы был доступен cp docker-compose, я мог бы просто добавить необходимую команду копирования в docker-compose.yml. avast / gradle-docker-compose-plugin будет обрабатывать сборку контейнера и копирование файлов из моих выходных данных сборки непосредственно в контейнер без какой-либо дополнительной логики доступа к удаленной файловой системе.

Этот Dockerfile добавлен в мою часть скрипта сборки docker-compose.yml. Во всяком случае, это антипаттерн, потому что он просто добавляет оверлеи к восходящему образу докера с каждой сборкой (до тех пор, пока мне не придется вручную удалять образ, что значительно замедляет сборку).

FROM myregistry:443/docker/image/karaf-el7:latest

COPY karafinitcommands /usr/local/karaf/etc/

COPY features.xml \
     *.jar \
     /usr/local/karaf/deploy/

Мне неприятно, что docker cp отлично работает для копирования во время выполнения, но docker-compose не имеет эквивалентного механизма.

Я думал, что идея состоит в том, чтобы привязать монтируемый локальный каталог к ​​/ usr / local / karaf / deploy и поместить туда ваши файлы. Я бы не ожидал, что мне придется перестраивать образ или использовать файл докера, чтобы получить это.

Я думал, что идея состоит в том, чтобы привязать монтируемый локальный каталог к ​​/ usr / local / karaf / deploy и поместить туда ваши файлы. Я бы не ожидал, что мне придется перестраивать образ или использовать файл докера, чтобы получить это.

Это, безусловно, достижимо. Перечитайте и обратите внимание, что это чисто проблема удобства: контейнер перестраивается с помощью сборки gradle, следующий логический шаг: как переместить новые файлы сборки в «локальный каталог», смонтированный в / usr / local / karaf / deploy? В моем случае «локальный каталог» более точно является «каталогом хоста», где хост является удаленным хостом. Поэтому мне нужно добавить rsync или что-то еще в свой сценарий сборки, чтобы получить файлы и убедиться, что старые заменены, а лишние удалены. В этом не было бы необходимости, если бы был доступен cp docker-compose. Я мог бы использовать свой существующий клиент-докер для подключения демона докера, которое я настроил для переадресации портов.

Тома Docker можно удалять с каждой сборкой. Привязать монтируемые тома нельзя. Они будут повторно заполнены, только если они пусты (механизм защиты от постоянства). Конечно, для очистки привязки на удаленном компьютере требуются определенные разрешения и логика доступа, которых можно было бы избежать с помощью команды docker-compose cp.

Опять же, копирование в среду выполнения может быть достигнуто с помощью docker cp. Это расстраивает.

Ах, хорошо, я слишком привык к своей собственной настройке. Я использую http://github.com/keithy/groan сценарий bash, который самостоятельно развертывает отдельные части на удаленных серверах, а затем мы вызываем докер.

Пример использования: сборка облака google и артефакты сборки

Необходим артефакт: веб-клиент (автоматически сгенерированный) реагирует на привязки graphql. Вам нужен запущенный сервер для создания файлов, необходимых для компиляции клиента. В образе клиента есть инструменты для создания привязок по адресу сервера. Итак, вы запускаете образ сервера в фоновом режиме, и теперь вам нужно запустить клиентский контейнер, указывающий на сервер. Как теперь получить сгенерированные файлы из контейнера в каталог хоста "рабочей области"? Монтирование каталогов запрещено, так как вы уже находитесь в смонтированном каталоге в контейнере докеров. Возможность docker-compose cp облегчила бы дополнительный болезненный шаг получения идентификатора контейнера.

Использование $(docker-compose ps -q SERVICE) для нацеливания на правильный контейнер позволяет использовать простой docker cli для таких операций, ориентированных на контейнер. Введение новой команды наверняка упростило бы ее для тех немногих случаев использования, которые ее просят, но это не обязательно. Я думаю, что чтобы избежать дублирования кода между compose и docker CLI, эту проблему следует закрыть.

Существует открытая проблема, при которой кеш сборки между compose и простым docker отличается из-за используемой версии docker daemon compose, а это означает, что вам нужно использовать чистую compose, чтобы не нарушать кеши в средах CI (https: // github .com / docker / compose / issues / 883), поэтому до тех пор, пока эти проблемы не будут решены, смешивание простых команд докеров с командами компоновки приведет к поломке кешей. Конфигурация compose определяет все виды встроенной конфигурации, избавляя от необходимости вручную указывать дублирующую конфигурацию с помощью простых команд docker .

Использование $(docker-compose ps -q SERVICE) для нацеливания на правильный контейнер позволяет использовать простой docker cli для таких операций, ориентированных на контейнер. Введение новой команды наверняка упростило бы ее для тех немногих случаев использования, которые ее просят, но это не обязательно. Я думаю, что чтобы избежать дублирования кода между compose и docker CLI, эту проблему следует закрыть.

Это намного глубже, чем «Несколько упомянутых случаев использования», потому что эти сценарии довольно распространены, а изменение, построение образа, повторное изменение, построение образа и т. Д. - это временные стихи, позволяющие справиться с этими вещами с помощью docker-compose. Аргумент «вы можете сделать это в docker cli, просто сделайте это там» в значительной степени сводит на нет множество других вещей, которые были добавлены в docker-compose.

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

@dionjwa # 883 действительно нужно изучить (если все еще актуально), поскольку docker-compose должен быть согласован с docker CLI.

@ jadon1979 Я не пытаюсь заблокировать этот запрос функции, просто заметил, что он был открыт более 1 года назад, и ни один из основных разработчиков не считал это достаточно важным, чтобы ввести новую команду, ни один участник не предложил PR для Это.
Я просто говорю, что в соответствии с отзывами об этом запросе функции и отсутствием усилий по разработке, чтобы предложить «лучший способ», предлагаемый обходной путь для использования комбинации docker-compose и docker cli, которую вы можете легко использовать в качестве псевдонима в ваша среда, чтобы сохранить ее простой в использовании, является разумным решением.
Теперь, если кто-то откроет PR, чтобы предложить новую команду cp я буду рад ее просмотреть.

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

В понедельник, 18 ноября 2019 г., в 17:31 Nicolas De loof [email protected]
написал:

@dionjwa https://github.com/dionjwa # 883
https://github.com/docker/compose/issues/883 действительно должен быть
исследовано (если все еще актуально), поскольку docker-compose должен быть согласован с
docker CLI.

@ jadon1979 https://github.com/jadon1979 Я не пытаюсь блокировать это
запрос функции, только что заметил, что он был открыт более года назад, и
ни один из основных разработчиков не считал это достаточно важным, чтобы
ввести новую команду, ни один из участников не предлагал для нее PR.
Я просто говорю, что, согласно отзывам на этот запрос функции,
и отсутствие усилий по разработке, чтобы предложить "лучший способ", предлагаемый
обходной путь для использования комбинации docker-compose и docker cli, которую вы
может легко использовать псевдоним в вашей среде, чтобы его было легко использовать, это
разумный обходной путь.
Теперь, если кто-то откроет PR, чтобы предложить новую команду cp, я был бы счастлив
просмотрите это.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/compose/issues/5523?email_source=notifications&email_token=AAGRIF2NS64IYANNVTGFTULQUL3TZA5CNFSM4EKAVONKYY3PNVWWK3TUL52HS4DFVREXG43VMVORWW63VMVBWWW6L03DFVREXG43VMVBWWW6
или отписаться
https://github.com/notifications/unsubscribe-auth/AAGRIFY7CULCUS3TDDTTHZLQUL3TZANCNFSM4EKAVONA
.

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

Я инженер DevOps и в значительной степени полагаюсь на контейнеры как на альтернативу аду зависимостей от агентов сборки с нуля. Когда моя система CI тестирует репо, она начинается со сборки из Dockerfile в том же репозитории и выполнения всех проверок ( bundle exec rspec , npm test и т. Д.) _Внутри контейнера_. Если есть артефакты сборки, созданные в виде документации или результатов тестирования, я просто копирую их из контейнера с помощью docker cp .

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

Рассмотрим эту конфигурацию: docker-compose-minimal.yml

version: "3"
services:
  artifact-generator:
    image: busybox

Я собираюсь создать контейнер, запустить команду в этом контейнере, получить идентификатор контейнера и попытаться извлечь файл с помощью docker cp

$ # Prepare the images and (stopped) containers.  In this case there is only one.
$ docker-compose --file docker-compose-minimal.yml up --no-start
Creating network "docker-compose-cp-test_default" with the default driver
Creating docker-compose-cp-test_artifact-generator_1 ... done
$ # Determine the ID of the container we will want to extract the file from
$ docker-compose --file docker-compose-minimal.yml ps -q artifact-generator
050753da4b0a4007d2bd3514a3b56a08235921880a2274dd6fa0ee1ed315ff88
$ # Generate the artifact in the container
$ docker-compose --file docker-compose-minimal.yml run artifact-generator touch hello.txt
$ # Check that container ID again, just to be sure
$ docker-compose --file docker-compose-minimal.yml ps -q artifact-generator
050753da4b0a4007d2bd3514a3b56a08235921880a2274dd6fa0ee1ed315ff88
$ # OK, that looks like the only answer we're going to get.  Can we use that to copy files?
$ docker cp $(docker-compose --file docker-compose-minimal.yml ps -q artifact-generator):hello.txt ./hello-artifact.txt
Error: No such container:path: 050753da4b0a4007d2bd3514a3b56a08235921880a2274dd6fa0ee1ed315ff88:hello.txt
$ # Nope.  Let's take a look at why this is
$ docker container ls -a
CONTAINER ID        IMAGE                        COMMAND                   CREATED              STATUS                          PORTS               NAMES
9e2cb5d38ba0        busybox                      "touch hello.txt"         About a minute ago   Exited (0) About a minute ago                       docker-compose-cp-test_artifact-generator_run_dd548ee686eb
050753da4b0a        busybox                      "sh"                      2 minutes ago        Created                                             docker-compose-cp-test_artifact-generator_1

Как видите, docker-compose ps действительно не знает обновленного идентификатора контейнера. Это прискорбно. Это было бы не так уж плохо, если бы у меня был способ узнать, что run_dd548ee686eb каким-то образом связано с выполненным мной docker-compose run , но я не вижу способа добиться этого.

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

$ docker-compose --file docker-compose-minimal.yml run --name blarg artifact-generator touch hello.txt
$ docker cp blarg:hello.txt ./hello-artifact.txt
$ ls 
docker-compose-minimal.yml  hello-artifact.txt

Успех! ...своего рода

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

Как минимум, я хотел бы каким-то образом узнать идентификатор контейнера, полученный в результате команды docker-compose run .

@ndeloof

Использование $ (docker-compose ps -q SERVICE) для выбора нужного контейнера позволяет использовать простой docker cli для таких операций, ориентированных на контейнер.

Неверно, см. Демонстрацию в предыдущем комментарии.

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

Пт, 13 декабря 2019 г., 11:40 Ян, [email protected] написал:

@ndeloof https://github.com/ndeloof

Использование $ (docker-compose ps -q SERVICE) для нацеливания на правильный контейнер
позволяют использовать простой docker cli для таких ориентированных на контейнер
операции.

Неверно, см. Демонстрацию в предыдущем комментарии.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/compose/issues/5523?email_source=notifications&email_token=AAGRIF2NFPTKY3QKRIXQ5RTQYONHLA5CNFSM4EKAVONKYY3PNVWWK3TUL52HS4DFVREXG63LVMVQS4DFVREXG63LVMVQQ6
или отписаться
https://github.com/notifications/unsubscribe-auth/AAGRIF3S4UHF5NG3VKYXJB3QYONHLANCNFSM4EKAVONA
.

Кого мы можем упомянуть, чтобы связаться с сопровождающими? Этот вопрос бессмыслен, пока с нами не заговорят. Это может быть просто: «это невозможно из-за текущей архитектуры программного обеспечения», как бы то ни было. Но оставлять такие проблемы инертными - это не то, чего вы хотели бы видеть в таком популярном решении, как Docker ...

Наше развертывание создает образ Docker с помощью bazel, загружает его в наш реестр Docker, а затем использует ресурсы Terraform docker_container с разделами upload для копирования файлов конфигурации в контейнер. Мне нужно перенести этот процесс развертывания, чтобы использовать docker-compose вместо Terraform. Я удивлен, что docker-compose не предоставляет функции для настройки каждого контейнера.

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

tbf docker-compose не совсем сопоставим с k8s и не рекомендуется для производственного использования. Он предназначен для разработки и быстрого тестирования. docker swarm - это то, что можно сравнить с k8s, и хотя он также очень упрощен, у него есть такие функции, как конфигурации и секреты.

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

Во вторник, 3 марта 2020 г., в 12:56 Дэвид Милум [email protected]
написал:

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

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/compose/issues/5523?email_source=notifications&email_token=AAGRIFZTKGRWMZZ5H6DG3FDRFUSEJA5CNFSM4EKAVONKYY3PNVWWK3TUL52HS4DFVREXG63LVMV402HS4DFVREXG63LVMVMV40
или отписаться
https://github.com/notifications/unsubscribe-auth/AAGRIF4NTQQSR2QQWPJT6PLRFUSEJANCNFSM4EKAVONA
.

Еще один «антипаттерн»:

Я использую docker-compose для оркестровки контейнеров во время локальной разработки и k8s для производства.

По собственному совету Докера я реализовал сценарий wait-for-it.sh для управления порядком запуска / завершения службы.

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

Вместо этого я хотел бы сохранить одну копию сценария wait-for-it в каталоге верхнего уровня, который docker-compose затем копирует в каждый контейнер при локальном запуске, поскольку в противном случае такие проблемы решаются в k8s, это означает, что я не хочу, чтобы эти проблемы загрязняли Dockerfile моих услуг.

Как однажды написал Эмерсон: «Глупая последовательность - это хобгоблин маленьких умов, которых обожают маленькие государственные мужи, философы и богословы».

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

@Phylodome, разве нельзя использовать проверки состояния контейнера и docker-compose depends_on ? Вот как я обеспечиваю здоровые зависимости запуска контейнера.

Насколько я понимаю, wait-for-it.sh - это действительно взлом, так как сами ваши сервисы должны быть устойчивыми к приходящим и уходящим зависимостям. Стартап - это лишь частный случай.

@ianfixes Означает ли «ваши сервисы» сами сервисы docker-compose или «наши» сервисы, например, сервисы, написанные нами, которые используют docker-compose? Я не знаю, пишете ли вы в роли «пользователя» или разработчика docker-compose.

Означает ли "ваши службы" сами службы docker-compose или "наши" службы, как в службах, написанных нами, которые используют docker-compose?

Сервисы, которые вы создаете как разработчик, должны быть устойчивыми. Это согласно этим документам: https://docs.docker.com/compose/startup-order/

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

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

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

И далее упоминаются различные сценарии ожидания.

Я мог многое сделать. Но поскольку это только для локальной разработки, и поскольку у меня есть другие стратегии для обработки проверок производственных сервисов в k8s, я бы предпочел самую простую и наименее навязчивую локальную реализацию, а не общие советы от людей, которые не знают подробностей того, почему я '' я бы хотел это сделать (например, проблемы с монтированием тома для выполнения разработки пользовательского интерфейса через сервер разработки Webpack).

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

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

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

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

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

Кроме того, извиняющееся газлайтинг ваших пользователей - плохой вид.

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

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

Мой обходной путь может заключаться в создании этого файла через Dockerfile контейнера Go или просто в создании файла .env для этого контейнера. Но все же, каждый раз, когда я добавляю новую переменную env, мне нужно будет обновить ее, возможно, в двух местах. Хороший вариант использования здесь. Или я мог бы просто использовать сценарий оболочки для cp файла для меня ...

+1 за функцию КОПИРОВАТЬ

мы уже достигли этого в Kubernetes с помощью бортовых машин, и есть МНОГО вариантов использования. Это НЕ антипаттерн, это всего лишь одна из функций, удерживающих docker-compose.

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

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

Проблема в том, что это невероятно недальновидно (отсюда и термин «антишаблон»), так как вынуждает вас повторять операцию каждый раз, когда нужно воссоздавать контейнеры. Не говоря уже о том, что он очень плохо масштабируется (а если у вас 10 контейнеров? 20? 100?)

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

PS Мой вариант использования; Я хочу добавить конфиг в контейнер Nginx в проекте без Dockerfiles.

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

@ chris-crone относительно вашего комментария ...

Для файлов конфигурации или данных начальной загрузки существует Docker Configs. Они работают аналогично секретам, но могут быть установлены где угодно. Они поддерживаются Swarm и Kubernetes, но не docker-compose. Я считаю, что нам следует добавить поддержку для них, и это поможет в некоторых случаях использования, перечисленных в этом выпуске.

Заинтересован ли docker-compose в реализации поддержки паритета с конфигами роя?

Если для этого есть билет (или если мне нужно сделать такой, который тоже подходит), я хотел бы подписаться на него и отказаться от подписки на этот мусорный огонь. Лично я бы закрыл это и дал ссылку на это, но это только я.

@harpratap, вы правы, но недостаток в том, что / folder_in_container не должен существовать или должен быть пустым, иначе он будет перезаписан. Если у вас есть сценарий bash в качестве точки входа, вы можете обойти это, установив символическую ссылку на свои файлы в изначально предназначенный каталог после создания тома в / some_empty_location

+1 за наличие функции КОПИРОВАНИЯ. Наш вариант использования - быстрое создание локальных сред разработки и копирование конфигураций для настроек разработчика.

Точно. Мы не все масштабируемся одинаково. Моя компания использует SALT для создания необходимых файлов .conf для различных приложений. Одна сборка - с основами - затем docker-compose для создания отдельных экземпляров на основе их уникальных частей: MAC-адреса, IP, порта, лицензий, модулей и т. Д. Это МОЖНО сделать из командной строки - но намного проще и меньше подвержены ошибкам из-за docker-compose.

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

Следовательно, мне нужно запустить 2 docker-compose - 1, чтобы запустить службы для создания сертификатов, а затем еще один, чтобы создать службы и запустить тесты. Грязный.

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

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

Мой вариант использования: в дополнение к конфигам у меня есть несколько библиотек (RPM), которые мне нужно установить в 5 из моих контейнеров приложений Rails (Debian). Различные версии Ruby / Rails, поэтому я не могу использовать один и тот же базовый образ, поэтому я должен иметь возможность хранить файлы в одном месте и копировать их в контейнер при сборке, потому что я не хочу загружать 1,5 ГБ данных при строительстве.

@gauravmanchanda

Мой вариант использования: в дополнение к конфигам у меня есть несколько библиотек (RPM), которые мне нужно установить в 5 из моих контейнеров приложений Rails (Debian). Различные версии Ruby / Rails, поэтому я не могу использовать один и тот же базовый образ, поэтому я должен иметь возможность хранить файлы в одном месте и копировать их в контейнер при сборке, потому что я не хочу загружать 1,5 ГБ данных при строительстве.

Вы смотрели для этого многоступенчатые сборки ? Думаю, это было бы более надежное решение.

Многоступенчатые сборки позволяют использовать один и тот же Dockerfile для нескольких образов. Это позволяет вам разложить их на множители и включать в каждое изображение только те части, которые вам нужны.

Хорошим примером является тот, который мы используем для создания Docker Compose . Он строится с использованием Debian или Alpine, но позволяет нам учитывать общий код.

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

С помощью docker для этого можно использовать флаг --copy-service. Есть ли альтернативы, которые мы можем использовать с docker-compose?

Привет @megaeater ,

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

Это интересный вариант использования; несколько вопросов: запускаются ли эти симуляторы (или их части) в производственной среде (то есть: не на машине разработчика или CI)? Если код открыт (или аналогичная система), не могли бы вы связать меня с ним, чтобы я мог посмотреть?

Было бы также интересно узнать, почему вам нужна копия вместо монтирования привязки или тома для этих файлов?

Вы действительно предлагаете создать около дюжины почти одинаковых изображений только потому, что один файл отличается? Это не имеет смысла, ИМО.

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

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

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

Спасибо за комментарий @ chris-crone

Мы не запускаем докер в продакшене, это только для целей разработки. Проблема с использованием тома (если я правильно понимаю) заключается в том, что симулятор (сторонний) имеет этот сценарий запуска, который удаляет файл при запуске. Выполнение скрипта останавливается, если удаление не удалось, поэтому нам нужно будет смонтировать его как rw. И если удаление файла разрешено, нам потребуется механизм для создания временного каталога для хранения этих файлов, чтобы оригиналы не удалялись. Поэтому нам понадобятся какие-то посторонние скрипты, чтобы увеличить композицию поверх docker-compose.

@ chris-crone Спасибо за ссылки. Я посмотрю, сработает ли это для нас 👍

Привет, @ chris-crone, я пробовал использовать многоступенчатые сборки, и это помогло нам сохранить библиотеки / конфигурацию только в одном месте и скопировать их, но теперь есть проблемы с игнорированием .dockerignore , независимо от того, где Я размещаю это.

Он работает, когда я просто использую Docker с новой опцией DOCKER_BUILDKIT , но не работает при использовании docker-compose, пробовал COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build , но все равно не работал. Есть идеи?

Мне было интересно, есть ли возможность указать, где искать .dockerignore в compose, когда я наткнулся на эту проблему https://github.com/docker/compose/issues/6022 , что опять же, был закрыт, участник 1 считает, что это бесполезно.

Если честно, это довольно неприятно !!

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

Например, время запуска tomcat для моего приложения в контейнере составляет около 3 секунд. Добавьте привязку ~ / .bash_history, и это 4s. Добавьте привязку моего приложения, и это обычно около 18-20 секунд. В Linux bind mount работает так же, как в локальной файловой системе, но не в MacOS. Масштабируйте это до 100 раз в день, и это важно.

Это не считая медлительности, которая сохраняется при первом доступе к приложению; пока файлы кода не будут кэшированы. Для меня это означает 3 минуты, включая задержку при подключении к монолитной базе данных Oracle Oracle через Интернет, чтобы изменить небольшую фразу на что-то другое и посмотреть, все ли в порядке. Блин, covid-19, лол.

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

Было бы неплохо, если бы docker-compose тоже был ориентирован на разработку, а не только на производственное развертывание.

Этот вариант использования имеет отношение к обсуждению: https://github.com/docker/compose/issues/3593#issuecomment -637634435

@ Крис Крон

@gauravmanchanda

Мой вариант использования: в дополнение к конфигам у меня есть несколько библиотек (RPM), которые мне нужно установить в 5 из моих контейнеров приложений Rails (Debian). Различные версии Ruby / Rails, поэтому я не могу использовать один и тот же базовый образ, поэтому я должен иметь возможность хранить файлы в одном месте и копировать их в контейнер при сборке, потому что я не хочу загружать 1,5 ГБ данных при строительстве.

Вы смотрели для этого многоступенчатые сборки ? Думаю, это было бы более надежное решение.

Многоступенчатые сборки позволяют использовать один и тот же Dockerfile для нескольких образов. Это позволяет вам разложить их на множители и включать в каждое изображение только те части, которые вам нужны.

Хорошим примером является тот, который мы используем для создания Docker Compose . Он строится с использованием Debian или Alpine, но позволяет нам учитывать общий код.

Многоступенчатые сборки - это круто, но они страдают от своих проблем, например, вы должны запускать все этапы в одном контексте, что не всегда возможно. Кроме того, насколько мне известно, вы не можете легко использовать COPY --from с изображениями, определенными в другом Dockerfile и созданными с помощью docker-compose build (я предполагаю, что вы могли бы сделать это, создав и пометив их вручную).

COPY сам по себе очень ограничен тем, что вы можете импортировать только из контекста сборки. docker cp можно копировать из любого места в любое место, за исключением того, что он не может копировать между изображением и контейнером (вроде как COPY --from ).

Мой собственный вариант использования немного отличается (помимо копирования файлов конфигурации только для чтения, монтирование локальных томов - не лучшая идея при развертывании на другой машине), и я бы сказал, что то, что я делаю прямо сейчас, является антипаттерном ... . У меня потенциально есть несколько разных изображений, которые при сборке генерируют скомпилированные и миниатюрные пакеты ресурсов JS + HTML + (подумайте о небольших приложениях angular), и один сервер nginx, который обслуживает все из них (nb построен из настраиваемого изображения из-за плагинов).

В настоящее время мне нужно скопировать пакеты «развертывания» из образов «сборки» при запуске. В идеале это должно быть сделано либо при создании контейнера, либо при сборке, но последнее потребует создания другого образа поверх «модифицированного nginx».

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

app1/
  src/
    ...
  Dockerfile
app2/
  src/
    ...
  Dockerfile
app3/
  src/
    ...
  Dockerfile
nginx/
  ...
  Dockerfile
docker-compose.yml

Каждый из файлов app{1,2,3}/Dockerfile содержит цель / этап build которая собирает приложение до /usr/src/app/dist . nginx/Dockerfile имеет только один этап и создает образ, похожий на nginx/nginx , но со всеми необходимыми плагинами (без конфигураций).

docker-compose.yml:

version: '3.8'
services:
  app1-build:
    build:
      context: app1/
      target: build
    image: app1-build
    entrypoint: ["/bin/sh", "-c"]
    command:
      - |
        rm -vfr /dist-volume/app1 \
        && cp -vr /usr/src/app/dist /dist-volume/app1 \
        && echo "Publishing successful"
    volumes:
      - 'dist:/dist-volume'

  app2-build:
    build:
      context: app2/
      target: build
    image: app2-build
    entrypoint: ["/bin/sh", "-c"]
    command:
      - |
        rm -vfr /dist-volume/app3 \
        && cp -vr /usr/src/app/dist /dist-volume/app3 \
        && echo "Publishing successful"
    volumes:
      - 'dist:/dist-volume'

  #... same thing for app3-build

  nginx:
    build:
      context: nginx/
    image: my-nginx
    volumes:
      - 'dist:/var/www'
      - # ... (config files etc)

volumes:
  dist:

Это явно не идеально, каждый образ для создания приложений запускается без необходимости и быстро завершается, развернутые образы находятся на общем томе (я предполагаю, что это отрицательно сказывается на производительности, но я пока не смог это проверить). Если copy или copy_from были вариантом docker-compose, то же самое можно было бы записать как:

version: '3.8'
services:
  # assuming the images have default entrypoint and cmd combination that immediately returns with success.
  app1-build:
    build:
      context: app1/
      target: build
    image: app1-build

  #... same thing for app2-build app3-build

  nginx:
    build:
      context: nginx/
    image: my-nginx
    copy:
      - from: app1-build  # as image or service, both have their pros and cons, service would mean an image associated with this service
         source: /usr/src/app/dist
         destination: /var/www/app1
      - from: app2-build
         source: /usr/src/app/dist
         destination: /var/www/app2
      - from: app3-build
         source: /usr/src/app/dist
         destination: /var/www/app3
    volumes:
      - # ... (config files etc)

Мой вариант использования не на этапе сборки или запуска. Я получаю файлы, созданные внутри контейнера или всего контейнера службы, эти контейнеры выполняются на удаленном движке Docker. Пока что я делаю что-то вроде docker-compose ps -qa <service> | xargs -i docker cp {}:<there> <here> . Я просто хочу, чтобы я мог придерживаться уникального docker-compose в моем скрипте.

@ Крис Крон

Было бы также интересно узнать, почему вам нужна копия вместо монтирования привязки или тома для этих файлов?

Вам нравится самобичевание? Если это так, я рекомендую запустить приложение с привязкой на MacOS. 🤣 Подробности см. В моем предыдущем посте.

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

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

Интересно, сможем ли мы каким-то образом заставить Docker и Apple работать вместе над исправлением проблем с производительностью с помощью привязок. По крайней мере, для меня мне больше не нужна опция docker compose cp, потому что я бы использовал bind mounts для разработки. Прямо сейчас, хотя использовать привязанных маунтов просто слишком больно. Я могу переключиться на виртуальную машину с Linux, потому что мой Mac просто байты.

@megaeater

Мы не запускаем докер в продакшене, это только для целей разработки. Проблема с использованием тома (если я правильно понимаю) заключается в том, что симулятор (сторонний) имеет этот сценарий запуска, который удаляет файл при запуске. Выполнение скрипта останавливается, если удаление не удалось, поэтому нам нужно будет смонтировать его как rw. И если удаление файла разрешено, нам потребуется механизм для создания временного каталога для хранения этих файлов, чтобы оригиналы не удалялись. Поэтому нам понадобятся какие-то посторонние скрипты, чтобы увеличить композицию поверх docker-compose.

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

@gauravmanchanda

это помогло нам сохранить библиотеки / конфигурацию только в одном месте и скопировать их, но теперь возникают проблемы с игнорированием .dockerignore , независимо от того, где я его размещаю.
Он работает, когда я просто использую Docker с новой опцией DOCKER_BUILDKIT , но не работает при использовании docker-compose, пробовал COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker-compose build , но все равно не работал. Есть идеи?

Рады, что многоступенчатые сборки помогли! Какую версию Docker и docker-compose вы используете? Я бы попробовал с последней версией и посмотрел, сохраняется ли проблема. Он должен уважать файл .dockerignore.

@Marandil , похоже, docker build не обрабатывает структуру вашего проекта (например, структуру каталогов), что является проблемой. Возможно, вы сможете использовать что-то вроде docker buildx bake (https://github.com/docker/buildx) для решения этого варианта использования. Обратите внимание, что buildx находится в стадии разработки, поэтому он еще не очень стабилен, но он направлен на решение некоторых проблем, с которыми вы сталкиваетесь.

@itscaro , спасибо за ваш вклад! Для создания объектов в контейнерах мы используем docker build для вывода результата из изображения FROM scratch . Это работает только в тех случаях, когда вам нужен вывод одного контейнера.

@TrentonAdams: мы работаем над улучшением производительности файловой системы для Docker Desktop, но это сложно. Основная проблема заключается в переходе границы виртуальной машины. Биты совместного использования файлов были недавно переписаны (вы можете включить новый опыт, используя переключатель «Использовать gRPC FUSE для обмена файлами» в настройках), и это должно решить некоторые из проблем с высокой загрузкой ЦП, с которыми сталкивались люди. У нас есть документация по настройке производительности здесь и здесь .

@ Крис Крон

@Marandil , похоже, docker build не обрабатывает структуру вашего проекта (например, структуру каталогов), что является проблемой. Возможно, вы сможете использовать что-то вроде docker buildx bake (https://github.com/docker/buildx) для решения этого варианта использования. Обратите внимание, что buildx находится в стадии разработки, поэтому он еще не очень стабилен, но он направлен на решение некоторых проблем, с которыми вы сталкиваетесь.

Спасибо, посмотрю в docker buildx bake . Это выглядит многообещающе, но мне не удалось найти ни одной хорошей ссылки или документации по нему, а страницы на docs.docker.com довольно пусты (см. Https://docs.docker.com/engine/reference/commandline/buildx_bake /). Пока что я нашел https://twitter.com/tonistiigi/status/1290379204194758657 со ссылкой на пару примеров (https://github.com/tonistiigi/fsutil/blob/master/docker-bake.hcl, https://github .com / tonistiigi / binfmt / blob / master / docker-bake.hcl), это может быть хорошей отправной точкой, но вряд ли хорошей ссылкой.

@TrentonAdams: мы работаем над улучшением производительности файловой системы для Docker Desktop, но это сложно. Основная проблема заключается в переходе границы виртуальной машины. Биты совместного использования файлов были недавно переписаны (вы можете включить новый опыт, используя переключатель «Использовать gRPC FUSE для обмена файлами» в настройках), и это должно решить некоторые из проблем с высокой загрузкой ЦП, с которыми сталкивались люди. У нас есть документация по настройке производительности здесь и здесь.

@ chris-crone Черт, да, большое спасибо! С новой опцией есть улучшение на 3-4 секунды, а использование "cached" дает мне ту же производительность, что и при работе вне контейнера, поэтому для меня это ОГРОМНО. Я вижу время запуска нашего приложения всего 2800 мс, так что это уже не 11-18 с. УРА! Мне не нужно ничего, кроме кеширования, потому что я все равно каждый раз заново создаю контейнеры.

@ chris-crone Есть ли место, где я должен публиковать информацию о производительности, чтобы помочь с настройкой производительности и отзывы о MacOS? Мне интересно, почему только что запущенный контейнер с монтированием привязки будет медленным, если не использовать cached . Должна быть какая-то странность, когда он постоянно проверяет каждый файл при запуске, если они синхронизированы, даже если он совершенно новый?

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

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

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

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

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

2) Выполнение этого с помощью конфигурации docker-compose volumes yaml означает, что Docker ограничивает исходный код как root:root (полностью убивая мою IDE от внесения изменений, пока я не верну его обратно!)

@ shin- я следую анти-шаблону, выполняя модульные тесты в контейнере? Как бы вы решили эту проблему не-антипаттерном?

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

@soulseekah Разве для этого использования секреты не

Я нашел обходной путь для меня:

1. Создайте Dockerfile с помощью
   COPY a_filename .
2. Создайте образ с помощью Dockerfile
   docker build -t myproject:1.0 .
3. Отредактируйте docker-compose, чтобы использовать только что созданный образ

version: "3.7"
services:
  app:
    image: myproject:1.0
    ports:
      - 3000:3000
    networks:
       - mynetwork
       - internal
    environment:
      MYSQL_HOST: mysql
      MYSQL_USER: root
      MYSQL_PASSWORD: not_so_secret_password # don't do this 
      # https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/
      MYSQL_DB: appdb
    deploy:
      resources:
        limits:
          cpus: '0.75'
          memory: 100M

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

@soulseekah Разве для этого использования секреты не

К сожалению, это требует роя в прошлый раз :(

@soulseekah Разве для этого использования секреты не

К сожалению, это требует роя в прошлый раз :(

@soulseekah Может быть, использовать обходной путь, который я использую (выше вас)?

@ChristophorusReyhan проблема с этой работой указана в комментарии @zoombinis :

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

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

docker-compose up && docker-compose down --rmi local

Но убедитесь, что все изображения, которые вам нужны, имеют настраиваемый тег, а тестовое / фиктивное изображение не