Compose: Добавить `copy` в конфигурацию yaml

Какая здесь семантика copy ? Копируем ли мы файлы с хоста, с которого запускается docker-compose , в новый запущенный контейнер с помощью docker cp ?

AFAIK нет _no_ текущего способа сделать это:

Видеть:

`` #! bash
$ docker cp -h

Использование: docker cp [ОПЦИИ] КОНТЕЙНЕР: PATH HOSTDIR | -

Скопируйте файлы / папки из PATH на контейнере в HOSTDIR на хосте
выполнение команды. Используйте '-' для записи данных в виде файла tar в STDOUT.

--help = false Использование печати
``

Какая здесь семантика копирования? Копируем ли мы файлы с хоста, с которого запускается docker-compose, во вновь запущенный контейнер с помощью docker cp?

да

AFAIK нет текущего способа сделать это:

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

http://stackoverflow.com/a/24805696/210090

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

Теперь, когда в docker-1.8 добавлена ​​поддержка копирования в контейнер через docker cp а в swarm-0.4.0-rc2 добавлена ​​поддержка docker cp , было бы здорово вернуться к этой проблеме на уровне компоновки. Вот пример использования (который отражает то, что мы фактически делаем в _почти_ производстве сейчас):

Файл docker-compose.yml, который упоминает многие контейнеры с помощью тега изображения, созданного CI (т.е. мы не используем build: в производстве; возможно, теперь мы могли бы это сделать, но в прошлых выпусках это не очень хорошо сочеталось с swarm) для этого всем нужны, например, статические файлы конфигурации HADOoop, которые точно соответствуют среде развертывания. В настоящее время необходимо вручную синхронизировать каталог, в котором находится docker-compose.yml, с точным путем на _each_ целевой машине-докере в рое. Затем добавляется стопка из volume: строк.

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

OTOH (как вкратце упоминалось выше), возможно, нам следует использовать build: . Обратной стороной здесь является то, что нам нужно написать дополнительный файл Docker для каждого типа контейнера развертывания. Один для образов, созданных с помощью CI, и второй для инжектора файла статической конфигурации. copy: в compose, подкрепленный недавними изменениями в docker cp , аккуратно позволит нам избежать всего этого дублирования.

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

У Bedies docker-machine все равно есть docker-machine scp что вы можете сделать с подготовкой машины; а затем вы можете делать хост-тома обычным способом, используя docker или docker-compose

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

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

«У Bedies docker-machine все равно есть docker-machine scp, который вы можете сделать с подготовкой машины; а затем вы можете делать хост-тома обычным способом с помощью docker или docker-compose»
Я сейчас этим занимаюсь. Это больно. Люди, управляющие развертыванием, забывают переместить файлы конфигурации. Если бы он поддерживался в docker-compose yml, это происходило бы всякий раз, когда контейнер создавался заново без ручного шага (ов).

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

«Разве вы не можете развернуть контейнер тома данных на самом узле с помощью самого роя, как вы можете с любой другой стратегией планирования контейнеров?»
Хмм, если я знаю, что мой рой имеет размер 10 узлов; Могу ли я просто масштабировать контейнер тома данных до размера 10 с политикой, запрещающей дублирование на данном узле движка докеров? Проблема (если я что-то не пропустил) заключается в том, что, например, контейнеры, которые должны ссылаться на этот объем данных, не имеют возможности --volume-из контейнера с соответствующим индексом. Ребята, вот уже 2 месяца смотрю на эту проблему. Лучшее, что я мог сделать, - это создать сценарий, использующий docker-machine scp . Но это ручной шаг после редактирования файла конфигурации и до docker-compose up . Также требуется, чтобы можно было записать точный путь на целевых машинах роя в качестве корня docker-compose.yml (т.е. он пахнет серьезным взломом).

Может быть, мои усилия на заводе помогут автоматизировать этот процесс раскрутки докерных машин и роевых кластеров с «правильными» данными, находящимися там, готовыми к использованию? (_ хотя он все еще находится на ранней стадии разработки, и я использую его для объединения docker-machine и docker-compose в одном setp_0.

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

Docker 1.9 добавляет новый api томов, и драйверы томов уже есть. Объемы - действительно правильный способ поддержать это. Не пытайтесь копировать файлы.

Спасибо за предложение! но я не думаю, что сейчас это действительно соответствует дизайну Compose.

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

Что делать, если нужно скопировать только файл конфигурации? (в рой докеров, чтобы volume_from не работал)

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

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

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

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

Кстати, в настоящее время я решаю это, выполнив десятки строк команд sed - http://unix.stackexchange.com/questions/112023/how-can-i-replace-a-string-in-a-files

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

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

Чем больше я копался в Docker, тем больше мне казалось, что многие из этих инструментов хороши для "hello world" / "посмотрите, как быстро я могу раскрутить эту классную штуку с \ shell \ commands \ like \ this \" на варианты использования одного типа машины (включая docker-compose). Если это выходит далеко за рамки этого, все начинает становиться довольно сложным, и IMO немного разваливается, и именно здесь могут появиться традиционные инструменты подготовки и спасти положение при правильном использовании.

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

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

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

Простым примером является создание контейнера, копирование конфигурации в нужное место, запуск контейнера после копирования конфигурации.

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

Однозначно будет очень полезно. Сейчас я работаю с изображением postgres в качестве серверной части базы данных, и я не хочу его перестраивать, просто чтобы обновить скрипт в папке /docker-entrypoint-initdb.d .

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

Эту проблему следует снова открыть, как упоминал @ctindel .

+1 за повторное открытие проблемы

+1 также за открытие.

+1 за открытие.

+1 за открытие.

+1 за открытие.

+1 за открытие.

+1 за открытие.

+1 за открытие.

Что не так с томом только для чтения?

myservice:
    image: foo/bar
    volume:
        - src:dest:ro

@michaelarnauts видят это .

👍 для открытия

+1 за открытие.

+1 за открытие.

+1 за открытие

+1 за открытие

+1 за открытие

+1 за открытие

+1 за открытие

+1 за открытие

Вот мое обоснование для разрешения копирования в Compose.

У меня есть приложение, работающее на множестве контейнеров. В качестве аргумента предположим, что все они запускают Apache. Все они имеют определения DocumentRoot, указывающие на такие вещи, как «/ var / www / partX». Dockerfile ничего не знает о содержимом конфигурации Apache, а Compose определяет ссылку на том для / var / www / partX. Это отлично подходит для разработки, потому что я могу отлаживать и настраивать код, не изменяя содержимое контейнера.

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

Я бы предпочел поддерживать единый набор файлов Docker и согласовывать их с файлом Compose. Compose - это то место, где я определяю, собираюсь ли я настроить / var / www / partX как общий том или копирую файлы в контейнер.

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

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

+1 за открытие.

+1. Было бы очень полезно скопировать файл конфигурации в docker-compose.yml файл вместо Dockerfile .

+1. Просто столкнулся с ним, пытаясь предоставить файл конфигурации для службы. Том только для чтения кажется вариантом, но я бы предпочел его скопировать.

Просто смонтируйте том:

version: '2'
services:
  foobar:
    image: 'postgres:9.6-alpine'
    volumes:
      - './docker/schemas/foobar:/docker-entrypoint-initdb.d'

@raszi -

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

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

+1 за открытие.

+1

+1 за повторное открытие или другое решение без объемов.

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

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 за открытие

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

+1 очень нужная функция

+1, приятно иметь функцию!

+1

+1

+1

+1

+1 открытие. Добавлено в закладки

+1 это очень нужная функция.

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

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 Для повторного открытия, так как это была бы очень полезная функция

Возможно, некоторым из вас поможет шаблонная функция https://github.com/jwilder/dockerize

+1

+1

+1

+1

+1

+1, чтобы снова открыть проблему

+1

Используйте секреты докеров, в этом примере секреты используются с изображением nginx для копирования сертификата сервера и файла конфигурации.
https://docs.docker.com/engine/swarm/secrets/#intermediate -example-use-secrets-with-a-nginx-service

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

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

Как было сказано ранее:

...
объемы:
- ./nginx/default.conf:/etc/nginx/conf.d/default. conf: ro
- ./nginx/nginx.conf:/etc/nginx/nginx. conf: ro
...

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

Я думаю, что копирование можно смоделировать аналогично процессу docker build , где Dockerfile обычно отправляется в репозиторий git вместе со всеми файлами, которые необходимо отправить в контекст сборки. Dockerfile не разрешено отправлять что-либо, что существует за пределами его структуры каталогов, даже если оно правильно связано с символической ссылкой. У нас могло бы быть то же самое с compose, где src ограничено каталогом (и теми, что ниже) docker-compose.yml . По сути, рабочий процесс будет следующим: docker-compose создает контейнер, а затем для каждой пары src:dst найдите src в текущем каталоге и скопируйте его в не запущенный контейнер, затем запустите контейнер.

В настоящее время избежать монтирования хоста можно, добавив дополнительные Dockerfiles и встраивая файлы conf в измененные изображения, но мне это кажется излишним, так как это связано с изменением тегов для нового изображения или принуждением пользователей использовать атрибут docker-compose build вместо более предпочтительного (IMO) атрибута image . Если вы уже используете атрибут build в своем определении службы и хотите сделать что-то таким образом, вы вынуждены засорять свой в остальном агностический конструктор изображений весьма самоуверенным файлом конфигурации, который должен просто принадлежать компоновке и процесс развертывания.

+1 для функции копирования в докере

+1

+1

+1

+1 за копию.

+1 для функции копирования в докере. Я думаю, что приведенные выше аргументы убедительны.

+1 за копию

+1 за копию.

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

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 за открытие

+1

+1 за открытие

Разве функция, которая работает с томом после того, как контейнер (или сам) достигает определенного состояния, не работает?
Это может быть флаг типа readonly, но вместо этого copyonly ! Тогда у вас будет стандартный конвейер / синтаксис операций с томами с добавленной функцией удаления ссылки после достижения состояния синхронизации внутри контейнера ...

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

+!

+1

+1 для функции копирования в докере

+1

+1

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

+1

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

В этом случае файлы, которые требуются для запуска службы, должны быть либо встроены в сборку (объявлены в Dockerfile), доступны через тома, либо (в случае режима docker stack / Swarm) существовать как config или секретные предметы. Копирование файлов в потенциально несколько мест назначения во время выполнения происходит медленно, подвержено ошибкам и не устойчиво к сбоям.

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

Наслоение докеров и кеширование удобны для других целей;

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

Это потребовало некоторой работы, чтобы использовать docker compose для разделения MySQL и Apache, но мне было бы все равно, если бы они все смешались.

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

Нужно добавить +1 копию docker-compose. Это позволяет значительно упростить передачу файлов конфигурации и обновлений контейнеров.

Используйте docker cp и docker config

Пт, 2 марта 2018 г., в 21:19 Джеймс Хан [email protected] написал:

Нужно добавить +1 копию docker-compose. Это позволяет значительно упростить поток
конфигурационных файлов и обновлений контейнеров.

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

>

Джеймс Миллс / прологик

Э: [email protected]
W: prologic.shortcircuit.net.au

+1 за копию docker-compose. Идея состоит в том, чтобы иметь копирование только для файлов, как описано здесь

+1

+1

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

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

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

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

Решил это с помощью docker-compose --force-recreate --rebuild , он копирует новые файлы, если они изменились (или так кажется). Не идеально, но работает.

+1

+1

+1

+1

+1 это сдержанность сводит меня с ума, кажется глупым монтировать том только для одного файла конфигурации.

+1

У нас есть способ добавлять файлы в контейнер с помощью docker compose with volume. Я заметил, что в документации Compose теперь есть параметр configs , поэтому мы также можем добавлять отдельные файлы.

https://docs.docker.com/compose/compose-file/#configs

Однако я считаю, что люди хотят объединить файлы с хоста в каталог в контейнере с предпочтением overwrite if exists , как вы ожидаете, что копия будет работать.

Мне странно, что конфигурация volumes в файле создания имеет параметр nocopy :

https://docs.docker.com/compose/compose-file/#volumes

volumes:
  - type: volume
  source: mydata
  target: /data
  volume:
    nocopy: true

Что описывается так:
volume: configure additional volume options
nocopy: flag to disable copying of data from a container when a volume is created

Значит, он отключает именно то, что нужно?

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

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

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

Редактировать:

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

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

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

+1

+1 Пожалуйста, команда Docker, учитывайте свое сообщество.

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

Предположим, я хочу подключить файл конфигурации nginx к /etc/something/whatever.conf не уничтожая все остальное, что находится в этой папке. Вы не можете создать именованный том для одного файла (см. Moby / moby # 30310), а также не можете создать том каталога, содержащий один файл, а затем смонтировать этот конкретный файл в контейнер (см. Moby / moby # 32582).

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

Здесь что-то должно уступить место: либо нужно изменить функцию томов в Docker, чтобы мы могли фактически использовать ее для внедрения файлов конфигурации в наш стек, либо нам нужно обойти это при создании, используя что-то вроде copy Параметр

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

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

Я с @masaeedu , я понимаю концептуальный идеал сохранения функции compose от ползания и, следовательно, не хочу добавлять эту функцию, но в реальной жизни потеря этой функции ОЧЕНЬ сокращает обстоятельства, при которых compose можно использовать без

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

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

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