Я просто смотрел на это

Использование: сборка докеров [ОПЦИИ] ПУТЬ | URL | -

так что если ты бежишь

docker build -t мой / вещь мой-dockerfile

жалуется на слишком короткий tar-файл.

Мне кажется, что опция «ПУТЬ» не задокументирована, поэтому она может иметь какое-то унаследованное значение?

Итак - мне интересно, обнаруживает ли PATH файл isa, а не Tarfile.

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

Этот PATH относится к каталогу, а не к конкретному Dockerfile.

ах, а потом тарс этот каталог до отправки на сервер - круто!

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

или использовать -f таким же образом - позволяя вашим определениям Dockerfile существовать отдельно от полезной нагрузки

теперь, чтобы разобраться, как работают тесты, попробуйте и посмотрите, сработает ли он для меня

Он ничего не запоминает - PATH - это каталог, в котором предполагается, что есть Dockerfile

это еще не все, что он делает с этим PATH - читая код, «контекст» отправляется на сервер путем тарирования каталога.

(хорошо, так что я все еще не знаю, go, и я читал код только последние несколько минут, так что отнеситесь к нему с долей скептицизма)

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

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

так что я мог иметь:

docker build -t my/thing fooproj
docker build -t my/thing -f debug-dockerfile fooproj

2108 (добавление директивы include в Dockerfiles) добавляет интересную морщину

должен ли include относиться к указанному dockerfile или PATH. пока не важно.

веселье:

docker build -t my/thing fooproj
docker build -t my/thing -f ../../debug-dockerfile fooproj
docker build -t my/thing -f /opt/someproject/dockerfiles/debug-dockerfile fooproj

в качестве дополнительного бонуса - тестов CmdBuild пока нет, так что угадайте, что я узнаю в первую очередь :)

@SvenDowideit , вы над этим работаете? Я думал о том, чтобы взломать его сегодня

Я медленно знакомлюсь с кодом и иду, так что дерзайте - мне слишком весело, просто пишу модульные тесты (возможно, вы можете использовать коммиты тестирования, чтобы помочь :)

Я сделаю :)

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

Итак: +1 от меня!

Похоже, это может иметь ту же конечную цель, что и # 1618 (хотя и с разными подходами). Идея состоит в том, чтобы использовать один Dockerfile с несколькими инструкциями TAG которые приводят к нескольким изображениям, по сравнению с несколькими Dockerfile и системой включения, как описано здесь. Мысли?

Кажется, что если вы можете передать Dockerfile внутрь, вы также сможете указать путь. Интересно посмотреть, что получится из # 1618, но я думаю, что это предлагает гораздо больше возможностей.

Вот где я: https://github.com/peterbraden/docker/compare/2112-specify-dockerfile?expand=1

Меня поразило то, что в документации четко не указано, что каталог, содержащий Dockerfile, является контекстом сборки - я сделал неправильное предположение, что контекст сборки был текущим рабочим каталогом, поэтому, если я передал путь к Docerfile вместо этого из-за того, что он находится в текущем каталоге, файлы, которые я пытался ДОБАВИТЬ из текущего рабочего каталога, были разбомблены с ошибками «нет такого файла или каталога».

Я получаю ту же ошибку, Любые идеи

docker build Dockerfile

Контекст загрузки

2013/12/11 21:52:32 Ошибка: Ошибка сборки: слишком короткий Tarball

@bscott попробуйте вместо этого docker build . . Сборка принимает каталог, а не файл, и это «контекст сборки». :)

Worked Thx !, я просто хотел бы выбирать между разными файлами Docker.

+1 от меня.

Мне нужно создать несколько изображений из моего источника. Каждое изображение - это отдельная задача, для построения которой требуется один и тот же контекст. Загрязнение одного Dockerfile (как предложено в # 1618) - ненадежное занятие. Для меня было бы намного чище хранить 3 отдельных файла <image-name>.docker в моем исходном коде.

Я бы хотел, чтобы что-то подобное было реализовано.

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

api/client.go
archive/archive.go
buildfile.go
server.go

client использует archive для тар build context и отправляет его server который затем использует archive для распаковки build context и передать байты в buildfile .

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

@thedeeno Я быстро посмотрю и покажу вам, нужно ли внести изменения. Я думаю, это только в одном месте.

+1 от меня!

Я слежу за № 1618 и № 2112, и это наиболее элегантное решение.

В моей разработке есть один конкретный вариант использования, в котором эта функция была бы невероятно удобной ... При работе с приложениями, которые имеют как «веб», так и «рабочие» роли. Я хотел бы создать два файла докеров для этой ситуации: «Dockerfile-web» и «Dockerfile-worker». Затем я мог бы создать их обоих, пометить их и отправить в свой репозиторий изображений. Затем я запускал несколько экземпляров веб-интерфейса за балансировщиком нагрузки и нескольких рабочих для обработки задач, помещаемых в очереди.

+1 в качестве альтернативы # 2745.

+1

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

+1
Я был бы признателен за это изменение

+1
Действительно нужно это.

5033 должен разрешить эту функцию. cc / @ crossbymichael

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

Я колеблюсь.

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

С другой стороны, меня беспокоит то же самое, что и с _run -v / host: / container_ и _expose 80: 80_. Другими словами, это позволит 1% знающих, что они делают, добавить классную настройку, а остальные 99% затем довольно сильно выстрелят себе в ногу.

Например, у нас есть много новых пользователей Docker, которые начинают с томов, подключенных к хосту, а не с обычных томов. И нам пришлось полностью отказаться от синтаксиса _expose 80: 80_, потому что слишком много людей публиковали изображения, которые нельзя было запускать более одного раза на хосте без уважительной причины.

Итак, мой вопрос: не рискуем ли мы иметь множество исходных репозиториев, которые нельзя повторно построить с помощью _docker build?

@shykes Я

1. У меня есть среда сборки на основе Docker, которая создает артефакт (в данном случае файл JAR). Среда сборки отличается от среды выполнения (различные зависимости, увеличенное изображение и т. Д., Поэтому я не хочу наследовать среду сборки во время выполнения. Для меня наиболее разумно иметь сборку Dockerfile и запустите среду выполнения вокруг JAR. Итак, у меня есть отдельный файл Dockerfile.build который строит и запускает среду сборки и создает JAR. Но, поскольку я не могу указать Dockerfile, мне пришлось создать файл scripts/build файл, который выполняет docker build < Dockerfile.build а затем монтирует хост-том с docker run -v ... для запуска сборки (так как я не могу использовать ADD с встроенными Dockerfiles). Что Вместо этого я хотел бы просто иметь возможность запускать docker build -t foobar/builder -f Dockerfile.build , docker run foobar/builder , docker build -t foobar/runtime , docker run foobar/runtime и просто использовать команды ADD в обоих файлах Docker.
2. С помощью инструкций ONBUILD я хотел бы иметь возможность помещать файлы Dockerfiles в подкаталоги (или иметь файлы Dockerfile.env и т. Д. В корне), которые имеют корневой файл Dockerfile в их инструкции FROM, но могут по-прежнему использовать корень проекта как контекст их сборки. Это полезно, например, для ввода параметров конфигурации для различных сред. Корневой Dockerfile по-прежнему будет создавать полезный контейнер, но другие будут создавать разные варианты, которые нам нужны.

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

@ cap10morgan есть ли шанс указать мне на свой пример 1 или что-то

@shykes https://github.com/shykes - это не совсем мечта о переносимости
что для чего нужен индекс изображения? Зачем нужна среда сборки
переносной?

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

Это действительно влияет на нашу команду. В нашей настройке мы хотели бы создать несколько
образы из того же «контекста». Добавив опцию --file мы можем сделать
то, что мы действительно хотим сделать - добавить foo.docker и bar.docker
в корень нашего репозитория. Вместо этого мы пишем сценарии bash для копирования
тонны файлов во временные папки, чтобы установить контекст, и переименовать наши
именованные файлы докеров в волшебный Dockerfile так что docker build может
Работа.

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

В понедельник, 7 апреля 2014 г., в 16:23 Соломон Хайкс написал на [email protected] :

@ cap10morgan https://github.com/cap10morgan при любой возможности указать
меня к вашему примеру 1 или что-то, что его приближает? Так что я могу играть
вокруг и убедитесь, что мы говорим об одном и том же.

Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/dotcloud/docker/issues/2112#issuecomment -39778691
.

@shykes, поскольку это, кажется, становится "нефиксированным", можете ли вы указать на документы или объяснение сертифицированного Docker способа решения этой проблемы?

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

Это и проблема .dockerignore (https://github.com/dotcloud/docker/pull/3452) (копирование всего моего каталога .git в контекст сборки) являются первыми критическими болевыми точками, с которыми я столкнулся при тестировании Docker для одного. наших проектов за последние несколько дней, и мне кажется, что это не проблема, но, похоже, по этим вопросам есть возражения.

+1 о том, что это тоже нужно - у нас есть единая кодовая база с несколькими разрабатываемыми микросервисами. Мы хотели бы иметь возможность генерировать несколько изображений, например, одно изображение, содержащее services / base / * и services / fooservice / *; и еще один образ, содержащий services / base / * и services / barservices / *, а также staticfiles / *.
Мы не можем поместить файлы Dockerfiles в служебную папку, потому что Docker рассматривает эту папку как контекст, и мы не можем ДОБАВИТЬ ничего, что находится выше в структуре папок. Мы не можем поместить два Dockerfile в корень, потому что у них будет одно и то же имя.
Единственное решение, которое у нас есть, - это поместить Dockerfile в служебную папку, а затем написать собственный скрипт для анализа выбранного Dockerfile, определить, какие пути он хочет добавить (все указанные относительно корня проекта), а затем скопировать их в новый временную папку, скопируйте выбранный Dockerfile в корень этой новой папки и, наконец, запустите «временную папку docker build». Это действительно необходимо?
Было бы намного проще, если бы вы могли просто отдельно указать «сборку докеров», где находится файл Docker, а где - контекст.

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

+1, кодирование этого ограничения - огромная боль.

+1 для флага -f, который указывает путь к Dockerfile отдельно от контекста сборки

Docker - отличный инструмент, но эта тесная связь контекста и конкретного Dockerfile определенно портит команду Docker. Структура каталогов не всегда точно отражает структуру «контейнер / подсистема».

Насколько сложно это исправить? И было несколько PR по этому поводу, но они были проигнорированы.

Связанное простое дополнение - иметь файл игнорирования для вещей, которые мы не хотим добавлять в контекст - да, я смотрю на вас, .git ...

На самом деле это может привести меня к тому, что пока я пропущу Docker и вернусь к Vagrant + Ansible. Отлично.

@davber .dockerignore находится в -> # 6579

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

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

/ cc @shykes @creack @crosbymichael @vieux

+1 для флага -f. Также переменная среды DOCKERFILE для переопределения настроек сборки.

@jakehow: да, определенно есть элемент перегрузки, на каждого сопровождающего приходится не менее 1000 человек, которые что-то активно запрашивают и требуют подробного объяснения того, почему это еще не было сделано. Мы действительно делаем все возможное, и если вы посетите irc-каналы #docker и # docker-dev, вы воочию увидите пожарный шланг.

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

Конечно, возможность динамически комбинировать каталог X с Dockerfile Y на лету в некоторой степени удобна (хотя я никогда не чувствовал острой необходимости в этом и часто использую Docker). Но из-за этого слишком легко сделать что-то глупое, а именно нарушить самоописательный характер вашей сборки. И это кажется очень плохим компромиссом. Отсюда и решение не реализовывать эту функцию.

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

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

@davber У меня сложилось впечатление, что Vagrant имеет такое же ограничение - 1 файл описания на проект (предположительно по тем же причинам). Как переход на Vagrant точно решит вашу проблему?

@gabrtv вы хотите попробовать вернуть мульти-изображение? Вот предварительное предложение:

$ ls | grep Dockerfile
Dockerfile
db.Dockerfile
frontend-prod.Dockerfile
frontend-dev.Dockerfile
$ docker build -t shykes/myapp .
Successfully built shykes/myapp/db
Successfully built shykes/myapp/frontend-dev
Successfully built shykes/myapp/frontend-prod
Successfully built shykes/myapp
$ docker build -t shykes/myapp2 --only frontend-dev .
Successfully built shykes/myapp2/frontend-dev

Это предложение подойдет нам, и я вижу, что оно решает и другие проблемы для других людей.

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

Возьмем, к примеру, make-файлы - чаще всего у проекта есть «Makefile», но make также позволяет вам указать с «-f» другой make-файл.

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

вы говорите: «Итак, мой вопрос: не рискуем ли мы иметь множество репозиториев исходных текстов, которые не могут быть созданы повторно с помощью сборки Docker»,

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

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

Насколько я понимаю, проблема здесь в том, что когда
запуская Dockerfile (cat Dockerfile | docker build -), мы теряем рабочий
каталог для ADD и CP.

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

cat Dockerfile | docker build --cwd=~/my_docker_data_files -

В этом предложении флаг --cwd указывает базовую папку для ADD и CP.
команды.

2014-06-29 19:42 GMT + 10: 00 Питер Брейден [email protected] :

вы говорите: "Итак, мой вопрос: не рискуем ли мы иметь много источников
репозитории, которые не могут быть созданы повторно с помощью сборки Docker ",

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

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/dotcloud/docker/issues/2112#issuecomment -47449994.

@llonchj на самом деле https://github.com/dotcloud/docker/pull/5715 решает это (в некотором смысле), и это уже объединено с мастером.

@shykes определенно открыт для другого PR с несколькими изображениями, хотя, посмотрев на # 5715, мне интересно, актуален ли этот конкретный PR.

Исходный комментарий Per @peterbraden ...

Было бы неплохо указать [команда отредактирована], чтобы я мог ДОБАВЛЯТЬ файлы, а также иметь несколько файлов докеров.

Per @ cap10morgan ...

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

Разве это не то, что делает # 5715? Я так понимаю:

$ cd myapp
$ ls Dockerfile
Dockerfile
$ docker build -t gabrtv/myimage
Successfully built gabrtv/myimage
$ ls subfolder/Dockerfile
Dockerfile
$ tar -C subfolder -c . | docker build -t gabrtv/myotherimage -
Successfully built gabrtv/myotherimage

Я знаю, что это не решает проблему сборок с несколькими образами из корня репо (что, я согласен, было бы неплохо), но мне интересно, можно ли сейчас положить конец этой конкретной PR / реализации с # 5715.

@gabrtv Мне кажется, что # 5715 не соответствует критериям @shykes о наличии единственной команды, которая всегда будет работать. tar -C subfolder -c . | docker build -t gabrtv/myotherimage - для меня крайне неочевидно.

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

Мне лично очень нравится последнее предложение @shykes с потенциально несколькими файлами .dockerfile (почему не только .docker?), Которые создаются по умолчанию. Это позволяет легко приступить к работе с помощью одной команды, несмотря ни на что, и оптимизировать позже.

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

@rattrayalex, поверьте, я согласен с целью «иметь единую команду, которая всегда будет работать». Есть хороший шанс, что я напишу код и отправлю PR. :подмигивание:

Я считаю, что с точки зрения организации проекта мы должны провести это обсуждение в другом месте, а не по затянувшейся проблеме под названием Allow specifying of a dockerfile as a path, not piping in :

1. Большая часть дискуссии здесь не имеет никакого отношения к @shykes новое предложение в https://github.com/dotcloud/docker/issues/2112#issuecomment -47448314
2. Первоначальная основная проблема (отделение контекста сборки от Dockerfile) решается с помощью # 5715, хотя, возможно, не всем нравится.

Цитата @llonchj ...

Насколько я понимаю, проблема здесь заключается в том, что при подключении Dockerfile (cat Dockerfile | docker build -) мы теряем рабочий каталог для ADD и CP.

Другими словами, если вас устраивает docker build -t <image> -f <path-to-dockerfile> , вы можете использовать tar -C <path-to-context> -c . | docker build -t <image> - в качестве функционально эквивалентного обходного пути, пока мы не сможем составить PR для предложения @shykes .

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

Спасибо всем, кто сегодня вмешался в эту проблему:

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

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

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

Разве "Dockerfile.frontend-prod" не был бы лучше, чтобы все Dockerfiles
в директории естественно разбирать вместе?

Простите, но это просто глупо. Если мое репо строит 100 сервисов, я определенно не хочу иметь 100 файлов Docker в корне. (Пример: репозиторий dotCloud PAAS.)

Мне тоже не нужен один огромный Dockerfile со 100 секциями.

Мне нужно 100 Dockerfiles, и я хочу, чтобы они были в отдельных каталогах.

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

Опять же, я не понимаю, почему наличие дополнительного флага для указания пути к Dockerfile (по умолчанию просто Dockerfile ) - это такая большая проблема?

Кроме того, текущее предложение ( <imagename>.Dockerfile ) вообще не соответствует текущему дизайну автоматизированных сборок. Если одно репо в любой из моих систем сборки будет скомпрометировано, злоумышленник может перегрузить все мои репозитории ...?

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

_ Опять же, я не понимаю, почему наличие дополнительного флага для указания пути к Dockerfile (по умолчанию только Dockerfile) - это такая большая проблема? _

Выше я привел конкретный аргумент. Не стесняйтесь прочитать его и представить контраргумент.

Re: беспорядок. @gabrtv тоже беспокоился о IRC. После некоторого обсуждения мы пришли к следующей альтернативе:

$ ls Dockerfile Dockerfiles/*
Dockerfile
Dockerfiles/frontend-prod
Dockerfiles/frontend-dev

Та же идея, но меньше отдельных файлов, лежащих в корневом репо.

Кроме того, текущее предложение (.Dockerfile) вообще не соответствует текущему дизайну автоматизированных сборок. Если одно репо в любой из моих систем сборки будет скомпрометировано, злоумышленник может перегрузить все мои репозитории ...?

Ну как они теперь называются? Если у вас есть репо с именем «abc» с простым Dockerfile, тогда он будет иметь смысл для изображения, сгенерированного этим именем, с именем «abc». Если у вас есть репозиторий «xyz» с «Dockerfile.abc» и «Dockerfile.zzz», то для вас имеет смысл называть сборки из них как «xyz-abc» и «xyz-zzz».

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

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

@shykes хорошо, если мы дошли до того, что получили Dockerfile / *, то почему бы не сделать еще один шаг и сделать так, чтобы "docker build" просто выполнял поиск файлов с именем "Dockerfile. *" во всех подпапках текущего каталога, рекурсивно и запустить их все в контексте текущего каталога? И пока мы находимся в if, предоставьте возможность просто построить один из них ... например, "-f"? :)

... не люблю, когда тебя называют глупым

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

Я думаю, что ваш конкретный аргумент был: «Я не хочу, чтобы люди начали размещать файлы Docker в случайных местах и ​​систематически использовать -f когда это не является строго необходимым». Это правильно? В этом случае имеет смысл назначить один Dockerfile в верхней части репозитория, перечислив другие Dockerfile. Если этот файл отсутствует, построитель может отказаться от работы (или выдать предупреждение), а если он перечисляет только один файл Dockerfile, построитель также может выдать предупреждение. Не думаю, что здесь уместна параллель с -v и -p .

@aigarius, если бы мы это сделали, было бы менее очевидно, как сопоставить каждый суб-файл Docker с дочерним изображением. Преимущество как ./Dockerfile.* и ./Dockerfiles/* заключается в том, что они сопоставляются с одним пространством имен, которое мы можем использовать для именования полученных изображений. Напротив, если у меня есть ./foo/Dockerfile.db и ./bar/Dockerfile.db , и я docker build -t shykes/myapp . , какой из них будет называться shykes/myapp/db ?

какой из них называется shykes / myapp / db?

Ни один. В таком сценарии вы должны закодировать полный путь к Dockerfile в имени, так что у вас будут «shykes / myapp / bar / db» и «shykes / myapp / foo / db». Это приближается к пространству имен Java, но я оставлю другим решать, хорошо это или плохо.

@shykes : что касается Vagrant, ну, я и, скорее всего, довольно много других, использую Vagrant для некоторых перекрывающихся функций Docker. Итак, мне нужно убедиться, что мои текущие многомашинные сборки - которые я делаю в Vagrant с несколькими определениями машин - не становятся более неудобными при использовании Dockerfiles. Дело в том, что «контекст» намного более гибок в Vagrant, где я могу на лету получать контекст из любого места по общим каталогам, как и язык, поэтому, если я просто хочу создать одну службу (или машину) Я могу установить переменную окружения и «бродить / подготовить» ее. Я использую этот метод ежедневно, чтобы просто создать или предоставить несколько сервисов в моей системе. И, если меня слишком раздражает растущий Vagrantfile, я могу легко «загрузить» sub-Vagrantfile, описывающий отдельную услугу или аспект.

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

Итак, у меня две проблемы:

1. Не получается получить огромный беспорядочный файл для всех сервисов
2. Возможность создания одной конкретной службы в этом файле / кластере файлов.

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

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

С параметром '-f' можно определенно структурировать подкаталоги и подкаталоги Dockerfiles, как угодно, например, Dockerfiles / подходы выше. Да, тогда понадобится простой однострочник, чтобы имитировать точное поведение ...

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

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

Я не думаю, что совместное использование - самая важная особенность. Совместное использование достигнуто
через изображения.

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

Предназначенная опция -f дает нам необходимую гибкость. С другой стороны,
возможность указать абсолютный путь для контекста сборки также
Работа.
3 июля 2014 г. в 18:00 «Дэвид Бергман» [email protected] написал:

Извините, если я повторю то, что подробно описано выше, но я не вижу
чем любое решение лучше, чем поддержка опции -f. Т.е. по модулю
проблемы с реализацией из-за глубоко укоренившейся зависимости от
Dockerfile находится в корне контекста, я не вижу недостатков в
Это.

С опцией '-f' можно определенно структурировать подкаталоги.
и подфайлы Dockerfiles, как угодно, например Dockerfiles /
подходит выше. Да, тогда понадобится простой однострочник, чтобы
имитировать точное поведение ...

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/dotcloud/docker/issues/2112#issuecomment -47989616.

Согласились с тем, что -f обеспечивает максимальную гибкость с минимальным "сюрпризом" (я лично предполагал, что есть такой флаг, и попробовал его перед тем, как перейти к этой теме).
Добавление -c , либо каталога, либо tar, для обеспечения контекста также кажется потрясающим дополнением. Это удалит константу cd s из больших процессов сборки, например; в компаниях.

Более того, README, содержащий инструкции для docker build -f foo/bar/Dockerfile -c foo/ просто не звучит так, как будто это меня оттолкнет.
Также согласился, что docker build может легко найти Dockerfile s. Таким образом, репо структурировано как таковое:

-- README
-- foo/
---- Dockerfile
---- etc
-- bar/
---- Dockerfile
---- etc
---- subbar/
------ Dockerfile
-- context/
---- etc

позволит избежать любых возможных конфликтов имен ( repo/bar/subbar ), легко вычислить сумму и должен иметь смысл во многих контекстах разработки. Это позволит легко использовать как docker build , который будет создавать множество контекстов, так и docker build -f , который может исключить посторонние Dockerfile в большинстве контекстов.

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

Просто чтобы это не потерялось, вчера в IRC-дискуссии с @shykes у него была другая идея по реализации этого:

• В корне репозитория есть главный файл Dockerfile, который содержит только несколько строк в новом формате, например «INCLUDE foo / bar / Dockerfile AS bar-foo» для каждого создаваемого образа.
• Каждый подпроект (например, модуль bar подпроекта foo), которому требуется отдельный образ, поддерживает обычный Dockerfile в foo / bar / Dockerfile. Пути в этом Dockerfile (для ADD и COPY) по-прежнему относятся к корню контекста, который является корнем репозитория (где находится главный Dockerfile).
• Регулярный вызов «docker build -t mycorp / myapp». создаст все изображения, зарегистрированные в корневом файле Docker, и назначит им имена, такие как "mycorp / myapp / bar-foo" в этом примере
• Дополнительная опция командной строки для «docker build» должна быть введена только для сборки некоторых из объявленных образов, например «docker build -t mycorp / myapp --only bar-foo, baz-db»

На всякий случай люди все еще ищут обходной путь:

#!/bin/bash
ln -s Dockerfile-dev Dockerfile
docker build -t image/name-dev:latest .
rm Dockerfile

@shykes ping? Если есть одобрение основного разработчика для конкретного дизайнерского решения, то гораздо более вероятно, что кто-то попытается реализовать это и сделать запрос на перенос.

+1 к решению -f, хотя я согласен, что каждое репо теоретически должно развертывать свою собственную службу. Некоторые люди не могут позволить себе роскошь этого решения. Моя особая проблема заключается в том, что у меня есть репозиторий для шеф-поваров с несколькими кулинарными книгами, и мне нужно уметь создавать множество сервисов. Но мне нужно иметь возможность ДОБАВЛЯТЬ каталоги выше. Поэтому оптимально хранить контекст в корне и указывать на файл докеров в подкаталоге.

"-f", вероятно, не будет реализован по уже указанным причинам.

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

Я думаю, что # 7115, вероятно, подходящее решение для этого.

Есть также # 7204, который, я думаю, также подойдет для большинства вариантов использования.

Мне не нравятся оба из 2 предложенных решений, включающих добавление синтаксиса в файл докеров. Ни один из них не кажется прямолинейным. # 7115 все еще не похоже, что он решит вариант использования, когда я хотел бы сгенерировать несколько типов изображений из одного репо, как я, например, делаю в одном из моих проектов для генерации `` тестового '' изображения и "производственное" изображение. # 7204 кажется слишком сложным решением, которое решает другую проблему. -f позволяет _конфигурируемость_ сборки, тогда как оба этих решения обращаются к _sub_builds_.

Мне бы очень хотелось пояснить: «Совершенно необходимо, чтобы сборка работала одинаково от хоста к хосту». Я не понимаю, почему это такой ключевой принцип.

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

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

Обязательно, чтобы сборка работала одинаково от хоста к хосту.

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

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

В понедельник, 28 июля 2014 г., в 10:43, Питер Брейден [email protected]
написал:

Мне не нравятся оба из 2 предложенных решений, включающих добавление синтаксиса к
dockerfile. Ни один из них не кажется прямолинейным. # 7115
https://github.com/docker/docker/issues/7115 все еще не похоже
решит вариант использования, когда я хотел создать несколько типов изображений
из одного репо, как я, например, делаю в одном из своих проектов на
создать "тестовое" изображение и "производственное" изображение. # 7204
https://github.com/docker/docker/pull/7204 кажется
слишком сложное решение, которое решает другую проблему -f позволяет
_конфигурируемость_ в сборку, в то время как оба этих решения обращаются к
_sub_builds_.

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

Как бы то ни было, я использую make для создания среды докера как
обходной путь для всей этой проблемы, которая, похоже, уже нарушает ваши
host-to-host run-the-same im обязателен.

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/docker/issues/2112#issuecomment -50347483.

Насколько я понимаю, основная идея заключается в том, что вы можете вытащить репозиторий git, и если вы увидите там Dockerfile, то вы можете выполнить команду «docker build -t mytag». в нем и получите полную ожидаемую сборку. Ключевым моментом здесь является то, что нет никаких пользовательских инструкций по сборке, о которых люди могли бы ошибиться или не знать.
Что _ может_ быть компромиссом, так это способ определения нескольких образов Docker в едином контексте, где по умолчанию все они построены с заранее определенными вложенными тегами, а затем у вас может быть возможность создать только один из множества возможных образов.
Таким образом, общий синтаксис сборки сохраняется, а также позволяет: 1) генерировать множество разных изображений из одного контекста; 2) выберите создание только одного из них с опцией «расширенный».
Предлагаемый синтаксис описан в моем комментарии выше - https://github.com/docker/docker/issues/2112#issuecomment -48015917

@algarius, спасибо, я думаю, на этом этапе мы должны открыть новое предложение по дизайну для синтаксиса _INCLUDE_. Примеры проектных предложений см. № 6802 или № 6805.

Процесс выглядит так:

• Подать проектное предложение
• Обсудить проектное предложение
• Одобряю проектное предложение
• Отправить PR на дизайнерское предложение

Давайте будем честными, сборки сейчас не повторяются.

Если в моем Dockerfile есть RUN apt-get update && apt-get install build-essentials ruby python whatever , значит, я уже во власти
все, что является "последним" в репозиториях на момент создания образа. Если
ВЫ создаете образ через неделю, вы вполне можете получить разные версии
зависимости от тех, что у меня есть.

@codeaholics Но это зависит от вас, потому что вы не привязываете версию, и это полностью вне контроля Docker.

Наверное, справедливый комментарий

@codeaholics, вы правы в том, что повторяемость сборок не идеальна, хотя есть возможности для ее контроля (например, закрепление версий), и мы должны предоставить больше. Но, по крайней мере, сборка всегда имеет одну и ту же _точку_ входа_, что означает, что мы _можем_ улучшить повторяемость в будущем. Однако, если ваша сборка зависит от стороннего инструмента, предшествующего самому Docker, пути назад уже не будет: повторяемость вашей сборки в основном равна нулю, и никакие будущие улучшения Docker не могут ее исправить.

Дело не только в повторяемости. Если ваша сборка зависит от определенного набора аргументов, которые не могут быть обнаружены _docker build_, тогда ваш настраиваемый инструмент является единственным инструментом сборки в мире, который может его построить: вы больше не можете использовать различные инструменты и плагины CI / CD, которые предполагают родная, доступная для обнаружения _docker build_.

@peterbraden в # 7115, как только вы добавите возможность для нескольких вызовов PUBLISH , теперь вы можете создавать несколько изображений. Затем вы можете добавить возможность настройки, выбрав, какие суб-изображения нужно построить. Ключевым моментом является то, что конфигурируемость осуществляется _внутри набора суб-образов, обнаруживаемых Docker_. Таким образом вы сохраните возможность обнаружения.

@shykes > если ваша сборка зависит от стороннего инструмента,
сам по себе ... повторяемость вашей сборки практически равна нулю.

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

Если повторяемость не является основной причиной ограничения, плагин CI
поддержка кажется довольно слабым резервом. Инструменты сборки предназначены для
поддерживать идиосинкразические варианты использования. Плагин, который не делает ничего, кроме
настройка docker build cmd кажется бесполезной. Мой инструмент сборки
уже среда сценариев. Хуже того, выгребая весь потенциал
варианты использования в сверхурочное время Dockerfile кажутся плохим способом
Это. Dockerfile должен оставаться сосредоточенным на простом создании нового образа с помощью
добавление слоев к базовому изображению. Другая работа кажется необычной.

Я пока люблю Docker. Отличная работа, ребята! Эта конкретная проблема просто возникает
быть болевой точкой.

В понедельник, 28 июля 2014 г., в 12:25, Соломон Хайкс [email protected]
написал:

@peterbraden https://github.com/peterbraden в # 7115
https://github.com/docker/docker/issues/7115 , как только вы добавите способность
для нескольких вызовов PUBLISH теперь можно создавать несколько изображений. Затем вы
может добавить настраиваемость, позволяя выбирать, какие фрагменты изображений нужно построить.
Ключевым моментом является то, что конфигурируемость осуществляется внутри набора
под-изображения, обнаруживаемые Docker_. Таким образом вы сохраните возможность обнаружения.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/docker/issues/2112#issuecomment -50361586.

@thedeeno цель Dockerfile - указать, как преобразовать репозиторий исходного кода во что-то, что может запускать Docker.

Как насчет «цель _a_ Dockerfile - указать, как преобразовать репозиторий исходного кода во что-то, что может запускать Docker».

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

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

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

@peterbraden @shykes Я согласен с тем, что -f проще и интуитивно

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

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

Создал новое предложение с этой идеей INCLUDE - https://github.com/docker/docker/issues/7277

В качестве побочного примечания - возможно, стоит подумать о более эффективной команде «APT» вместо неуклюжей команды «RUN apt-get install -y ....» (а затем, впоследствии, YUM, EMERGE, PACMAN и т. Д.)

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

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

@shykes говорит что-то вроде: «Тот факт, что вы можете указать на каталог с исходным кодом без какой-либо внеполосной информации и построить из него изображение в точности в соответствии со спецификацией разработчика-разработчика, это очень мощный и полезный инструмент. ключевое отличие Docker. "

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

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

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

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

Мысль о том, что каждый проект может выбрать что-то разумное за docker build . - это фантастика. Проекты, которые не могут сделать что-то осмысленное, существуют, и их количество. Единственный вопрос на данный момент заключается в том, будет ли Docker поддерживать напрямую многопользовательский характер этих проектов или они будут использовать традиционные инструменты сборки, такие как make или даже сценарии оболочки. Это происходит сейчас : например, Discourse, один из крупных распределенных проектов на Docker, частично использует собственную систему сборки для решения этой проблемы.

@drewcrawford, как видите, проблема именно в этом. "сборка докеров". должен построить _the_ образ. Единственно верный образ. Вы должны изменить параметры запуска докера, чтобы настроить поведение одного-единственного образа в разных средах.
В этом контексте вам, вероятно, понадобится релизная версия, только приложение, и ничего больше. Все остальные вещи, такие как «изображение postgres», - это разные вещи, которые связываются с вашим приложением во время выполнения. Вы можете взять тот же образ выпуска и запустить его с командой, отличной от стандартной, для выполнения в нем ваших тестов.
В идеале, с поддержкой нескольких изображений, вам даже не нужно выбирать между сборками «выпуск», «отладка» и «с тестами» - у вас просто все они с базовой сборкой и 3 сборками с небольшой разницей наверху.
Если вы попытаетесь склонить Docker к старому образу мышления, у вас будут плохие времена. Не пытайтесь забить винт отверткой.

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

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

@drewcrawford предоставил конкретный пример того, как это решается в текущем популярном приложении, которое распространяется с поддержкой Docker. Как они должны это делать?

@aigarius Дело не в том, что я не понимаю "докерский путь". Я просто считаю это неправильным.

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

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

Проблема здесь в том, что Dockerfile не может быть одновременно предпочтительным пользовательским интерфейсом для сборки, а также существенно менее мощным, чем, например, make . Это может быть либо предпочтительный пользовательский интерфейс для сборки с подобной мощью, либо это может быть инструмент низкого уровня с make и т. Д. В качестве реального пользовательского интерфейса. Но «настоящие» системы сборки не являются произвольно сложными - они сложны, потому что люди используют эти функции, и никакие упрощенные сборки докеров не изменят этого. Все, что произойдет, это докер станет новым cc , который люди вызывают с помощью make .

@shykes @drewcrawford @aigarius Я написал предложение для простой опции -f так же, как @shykes, описанное ранее в этой теме здесь: # 7284

@drewcrawford, вы правы, чтобы быть предпочтительным пользовательским интерфейсом для сборки, docker build должен быть как минимум таким же мощным, как, например,. make . Сделать это можно двумя способами:

• 1) Мы могли бы попытаться повторно реализовать каждую функцию каждой вариации make, а также любую альтернативу, которую можно было бы сделать: Maven, scons, rake и, конечно же, старые добрые сценарии оболочки.

ИЛИ

• 2) Мы могли распознать, что эти инструменты сборки сами по себе являются исполняемыми программами, что означает, что они имеют зависимости времени выполнения и сами были построены из зависимостей сборки - и так далее до самого конца. И мы могли бы предоставить вам способ _реально использовать_ ваш любимый инструмент сборки. Таким образом, нам не нужно было бы повторно реализовывать make, потому что мы действительно можем собирать и запускать make.

Когда вы говорите make , какую марку вы имеете в виду? Какая версия? Построен из какой именно svn checkout? С какими вариантами сборки? С какой libc он связан? Тот же вопрос для cc котором вы также упоминаете. Может быть, это не имеет значения - может быть, ваше приложение будет одинаковым независимо от того, какую случайную версию make я использую для сборки. Но опять же, может быть, это имеет значение. Возможно, единственный способ получить точно такую ​​же сборку, как и вы, - это использовать точно такую ​​же сборку Make и Cc, чем вы использовали. И сегодня нет простого способа сделать это, но я бы хотел этим заняться.

Я действительно не думаю о docker build как об инструменте сборки, точнее, скорее как об инструменте мета-сборки: известной отправной точке, из которой вы можете надежно воссоздать любую среду сборки. Это мотивация для № 7115.

@shykes Я не думаю, что действительно необходимо копировать _все_ функции make, Maven, rake и т. д. В конце концов, эти инструменты не копируют все функции друг друга, и каким-то образом они уживаются.

Однако необходимо (если Docker должен быть предпочтительным пользовательским интерфейсом для создания образов), чтобы Dockerfile стал более выразительным языком, чем он есть сейчас.

Предложение в этом выпуске на самом деле является довольно скромным шагом в этом направлении: в нем говорится: «Нам нужен эквивалент для make's _targets_». Вопрос о том, «какая версия make» на самом деле не входит в общую картину - понятие «цель» является общим для make, Maven, rake и любой другой серьезной системы сборки. У них разный синтаксис, но тот факт, что эта функция универсальна, должно указывать на то, что люди часто делают это при создании вещей.

Не имеет значения, является ли то, что они создают, программой на языке C, образом Docker или чем-то промежуточным - вы все равно создаете какую-то цель. Идея цели сборки настолько фундаментальна, что охватывает реализации системы сборки, языки программирования, операционные системы. Мы не говорим здесь о воспроизведении каких-то неясных особенностей GNU Make, мы говорим о чем-то, что имеет самое широкое согласие.

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

Такие предложения, как # 7115, интересны, но если я чего-то не упускаю, они не могут служить эффективной заменой целей. Цель говорит вам, что строить. # 7115 дает вам более гибкий DSL, который все еще может построить только одну вещь. Это что-то, но это не то, о чем здесь просят.

docker build -t my_project_builder .
# Builds the builder container
docker run my_project_builder my_target | docker build -t my_project/my_target -< Dockerfile_MyTarget
# target is built, tarballed, and sent to stdout, then piped into a new docker build as the context and custom Dockerfile name

@drewcrawford просто для подтверждения, если docker разрешил что-то эквивалентное Make target, чтобы вы могли 1) указать, какую цель строить, например. make clean; make foo , 2) по умолчанию создаются _все_ цели и 3) есть способ перечислить цели ... Вас это устроит?

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

Хорошо.

@shykes @drewcrawford : +1:

Все, что произойдет, это docker станет новым cc, который люди будут вызывать с помощью make.

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

@drewcrawford : +1: +1,000,000

Вот ситуация, с которой я постоянно сталкиваюсь:

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

В любом случае, в репо есть файлы, которые мне нужно ДОБАВИТЬ для обоих этих контейнеров. Как есть, это невозможно сделать, не прибегая к копированию отдельных файлов Dockerfile по одному в сценарии bash, выполнению сборки и последующей замене или удалению файла Dockerfile.

Мне нужно либо:

1. Команда -f для указания файла, который будет использоваться как Dockerfile.
2. Возможность ДОБАВИТЬ файл не по пути вниз от Dockerfile.

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

@ShawnMilo

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

@jakehow Спасибо за обновление. Так что до официального решения проблемы, похоже, еще далеко. А пока есть "хороший способ" сделать это? Лучшая идея, которая у меня есть, - это сценарий bash, который копирует файлы по одному в «Dockerfile» в корне репо и создает образы. Это будет работать, но кажется грязным.

@ShawnMilo да, я думаю, что большинство людей используют для этого инструменты сборки (make, rake и т. Д.) Или просто старые сценарии bash.

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

Вот мой способ решения этой проблемы. Мне нужно создать образ для разных версий платформы, скажем, v2 и v3. Итак, у меня есть Dockerfile.v2 и Dockerfile.v3. Когда я хочу создать сборку, я запускаю сначала ln -s ./Dockerfile.v3 ./Dockerfile затем docker build . На самом деле у меня есть сценарий, и я просто запускаю ./build v3 или ./build v2

Хотя в настоящее время я использую сценарий, который связывает указанный Dockerfile с ./Dockerfile , это было бы неплохо.

Я создал PR № 7995, чтобы попытаться решить эту проблему. Некоторые решения, обсуждаемые в этой (длинной :-)) ветке, кажутся людям ужасно болезненными для использования. Одним из самых больших преимуществ Docker (для меня) было то, насколько он прост в использовании, и поэтому просить людей прыгать через такие обручи из-за того, что кажется довольно простым вопросом, не кажется правильным.

Возможно, я что-то упустил, но есть ли техническая причина, по которой его следует называть "Dockerfile"? Создавая PR, я не смог его найти и был приятно удивлен тем, насколько легко его было изменить.

@duglin , вся моя поддержка.

Это то, что мы делаем, чтобы обойти отсутствие опции -f в нашем текущем проекте.

# build.sh
...
mv specialDockerfile Dockerfile
docker build -t $(PROJECT) .

Считайте это +1 к добавлению -f .

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

+1000

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

Однако, если я попытаюсь использовать это в подкаталоге моего репо, мой GOPATH сломается, поскольку папка .git в корне репо отсутствует. Мне нужно ADD корень репо, а затем создать его в моем подкаталоге, но это не разрешено докером.

Прочитав эту длинную ветку, я заметил, что не могу воспроизвести сборки. Один из способов смягчить это - разрешить параметру -f указывать только внутри контекста сборки или вниз. Таким образом, вы можете иметь несколько файлов Docker в подкаталогах и создавать их из корня репо. Кроме того, вы можете ограничить это быть в пределах границ репо, например, на том же уровне, что и .git / .hg / .foo и ниже, но не за пределами репо.

Вот что я думаю

FROM scratch
BUILD myname1 path/to/dockerfile/in/context
BUILD myname2 path/to/dockerfile2/in/context

docker build -t myimage .

Это даст 3 изображения:

1. Основное изображение называется "myimage", в котором на самом деле ничего нет для примера.
2. Изображение под названием myimage-myname1
3. Изображение под названием myimage-myname2

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

-1

В этом особом случае вы можете использовать средство подачи контекста для docker build - например dockerfeed .

@itsafire Смысл в том, чтобы

Я здесь в растерянности. У нас есть несколько запросов на включение этой дополнительной функции, верно? И это несложно сделать ... Можно даже применить правило, упомянутое @maxnordlund : ограничить путь относительным контекстом / корнем. Это, по крайней мере, сделало бы его более плавным с boot2docket и тому подобным, и сделало бы его «портативным».

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

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

Начинаю чувствовать себя сумеречной зоной.

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

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

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

Я думаю, что Docker (например, .deb) может удовлетворить потребности обеих сторон, но придется идти на компромиссы.

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

@itsafire В прошлый раз, когда я проверял, докер может есть Dockerfile но не контекст. Фактически, контекст игнорируется, когда вы предоставляете Dockerfile таким образом. Если бы они добавили поддержку тому, что вы предложили, это было бы закрытым вопросом.

Я давно не смотрел, но основной запрос таков: дайте нам явный способ предоставить как Dockerfile и context во время сборки. Честно говоря, шокирован, это похоже на 8 месяцев спустя и все еще открыт.

@thedeeno, это действительно возможно
cat mystuff.tar.gz | docker build -

@ cpuguy83, но я не могу предоставить явный файл Docker с этой командой. Верно?

@thedeeno да, вы можете настроить любой Dockerfile, какой хотите, с любым контекстом.

@ cpuguy83 @thedeeno Нет, это не сработает, потому что тогда вы не сможете ДОБАВИТЬ какие-либо файлы, потому что ни один из них не находится в области "cwd", которую вы обычно получаете с Dockerfile.

Изменить: это утверждение неверно; Я неправильно понял пример @ cpuguy83 .

@ShawnMilo, да, это так. Все, что находится в tar, находится в контексте.

@ cpuguy83 Извините, моя ошибка. Я поспешно прочитал, что это просто конвейер в Dockerfile, а не целый архив.

@ cpuguy83 Отлично ! Я голосую за закрытие, если это сработает так, как вы предлагаете.

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

Продолжайте в том же духе!

Создание всего контекста нисколько не облегчает то, о чем мы говорим выше.

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

Я не понимаю, как в этом поможет использование tar-архивов каталога. Да, можно создать специальный каталог и скопировать туда конкретный Dockerfile, а затем весь контекстный каталог или tar и добавить новый Dockerfile, а затем сжать его. Но насколько это проще, чем [довольно ужасный] обходной путь, который мы в настоящее время должны использовать, когда сценарий препроцессора помещает правильный файл Docker на место перед запуском докера?

И, как я отмечал выше, это не поможет с экологией Docker.

Я что-то упустил?

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

@davber Что вам действительно нужно, так это чтобы Docker обрабатывал архивирование контекста и Dockerfile за вас.
И я не категорически против этого. Хотя я думаю, что вложенные сборки могут быть лучшим решением.

@ cpuguy83 : да, поэтому я хочу, чтобы Docker

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

Т.е. мы по-прежнему хотим использовать тот же корневой контекст.

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

@ cpuguy83 : не могли бы вы объяснить, как вложенные сборки могут помочь мне или любому другому из нытиков? :-)

@davber
Я так понимаю:

FROM scratch
BUILD myname1 path/to/dockerfile
BUILD myname2 path/to/another/dockerfile

И это:

docker build -t myimage .

Получится 3 изображения: «myimage», «myimage-myname1», «myimage-myname2».
Каждая внутренняя сборка будет иметь доступ к полному контексту сборки в виде абсолютных путей. Относительные пути будут относиться к Dockerfile.
И «myimage» может иметь свои собственные вещи, помимо инструкций BUILD.

Как я упоминал ранее, многие новые инструменты в более крупной (и великолепной!) Среде Docker предполагают, что каждый Dockerfile связан ровно с одним образом Docker. Существуют различные инструменты оркестратора, подобные «фигу». И многие новые и старые облачные решения, имеющие конкретную поддержку Docker, также имеют это однозначное предположение. Конечно, в мире, созданном с помощью опции '-f', они должны были бы получить не только контекст - например, tar-шар, - но также потенциально отдельный Dockerfile. Но каждая такая загрузка по-прежнему будет соответствовать ровно одному образу Docker.

Если мы пойдем по пути потенциального отделения Dockerfile от корневого контекста, я надеюсь, что эти инструменты начнут жить с этим сценарием:

Each deployment/use of a Docker image is done with an upload of either:

   1. a Dockerfile solely, when no contextual operations are needed
   2. a context tar ball only, containing the context with a top-level Dockerfile
   3. both a context tar ball and a separate Dockerfile

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

И, честно говоря, это разумное и концептуально привлекательное предположение - иметь изоморфизм между Dockerfiles и изображениями, даже если первые будут строго пространством продукта, состоящим из каталогов контекста (увеличено ...) и Dockerfiles, по умолчанию (null, file), если предоставляется только Dockerfile и (context, context / 'Dockerfile'), если предоставляется только context.

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

изоморфизм между Dockerfiles и изображениями

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

@hanikesn : два комментария:

1. почему это предположение нарушается из-за необходимости копировать файлы Docker на место перед сборкой; все равно будет один Dockerfile <-> один образ?
2. Я утверждаю, что я хочу, чтобы любое решение, которое мы здесь придумали, _работало_ с существующим и растущим ландшафтом Docker, без необходимости слишком больших изменений в этом ландшафте; и я думаю, что, сохраняя упомянутый изоморфизм, мы делаем это.

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

@davber

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

Предлагаю решение, о котором уже говорил ранее:

$ docker-pre-processor [ --options ... ] . | docker build -

В то время как --options - это правила, контекст в (здесь) текущем каталоге должен быть изменен и передан докеру. Это нужно делать "на лету", создав временный tar-архив, содержащий контекст. Таким образом, исходный контекст останется нетронутым. Поменять препроцессор проще, чем синтаксис Dockerfile.

@itsafire

А как насчет инструментов, ожидающих сегодня Dockerfiles? Их становится все больше благодаря Amazon, Google и т. Д. И фига и подобные фреймворки оркестровки.

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

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

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

Фрагментация этой ситуации противоречит заявленной командой

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

+1

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

`-- project
     |-- deploy
     |    |-- .dockerignore
     |    |-- Dockerfile
     |    ...
     `-- src

Мой способ - содержать в чистоте корень проекта. Но ADD ../src и -f deploy/Dockerfile не работают. На данный момент у меня есть Dockerfile и .dockerignore в корне проекта, но для меня это больно.

Со своей стороны я создал сценарий, который подготавливает папку с необходимыми файлами и выполняет стандартную командную строку docker build -t my/image . поскольку я столкнулся с проблемой, что файл .dockerignore игнорируется ADD ...

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

+1 за это. Мне нужно добавить файлы к разным изображениям из одной папки для разных серверов.

+1 Мне пока нравится Docker, но из-за того, как я настраиваю мою команду, мне действительно нужен способ создания разных развертываемых объектов, которые разделяют хороший кусок кода, из одного репо. Не особенно заинтересован в том, чтобы объединить их все в контейнер убердокера, поскольку тогда их циклы развертывания / выпуска без необходимости связаны друг с другом. Как лучше всего обойти это?

@jfgreen : поместите несколько файлов Docker в любое место и назовите их как хотите. Затем создайте сценарий bash, который копирует их по одному в корень репо как «./Dockerfile», запускает «сборку докеров», а затем удаляет их. Это то, что я делаю для нескольких проектов, и это отлично работает. У меня есть папка «dockerfiles», содержащая файлы с именами, такими как база данных, база, тесты и т. Д., Которые все являются Dockerfiles.

@ShawnMilo Спасибо, это кажется очень разумным решением.

+1

+1

+1 к -f . Существует разумное значение по умолчанию, которое, если флаг опущен, Docker будет делать _ правильные вещи_. В случае, если по какой-либо причине очень конкретный взгляд на _ правильное_ для пользователя _ неправильное_ есть -f . Приведенные выше сравнения с такими инструментами, как make я считаю разумными. make - также очень самоуверенная утилита, изначально написанная в 1976 году, и поэтому у нее было достаточно времени для стабилизации набора функций. Я думаю, поучительно, что в man make единственный флаг, который упоминается в очень кратком синопсисе, - это ... -f .

       make [ -f makefile ] [ options ] ... [ targets ] ...

В самоуверенных, ориентированных на ux утилитах нет проблем, но некоторые вещи вроде -f являются прагматическими кивками в адрес реальных пользователей. Инструмент должен облегчить вам жизнь, а не усложнить ее. Если мне нужно написать Makefile или сценарий оболочки для работы с инструментом без -f означает сбой инструмента. Судя по количеству пользователей, которые нашли время, чтобы прокомментировать, и оценили +1, эта функция имеет значительную полезность даже через год после того, как она была первоначально предложена.

+1

+1 (или официальный пост в блоге с рекомендуемым обходным путем)

+1

+1

@crosbymichael Я считаю, что теперь это можно закрыть из-за слияния # 9707

ПОБЕДА.

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

master.dockerproject.com

Спасибо @duglin !

:хлопать в ладоши:

Спасибо @crosbymichael за двоичный файл! : +1:

Молодцы ребята! :хлопать в ладоши:

Так это docker build -f Dockerfile.dev . ? редактировать: да