Название проекта не имеет значения. Мне нравится идея случайного названия проекта. Еще лучше - можем ли мы сгенерировать хеш пути к fig.yml и использовать его?

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

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

Мне нравится идея сделать имя проекта настраиваемым из файла. Я думаю, что подобное обсуждение происходило в (№ 45). Если указать имя проекта в .fig/project-name , это приведет к созданию множества очень маленьких файлов. Я думаю, что было бы проще просто поместить его в сам fig.yml (как это предлагается в # 45 и в одном из предложений компоновки докеров).

Каковы преимущества помещения его в отдельный каталог и файл?

Причина помещения его в отдельный файл имеет ряд причин, я попытаюсь объяснить, что я думаю об этом;

• Чтобы сохранить имя, которое использовалось для _старта_ проекта (например, --project-name=foobar ), которое может отличаться от автоматического имени проекта.
• Наличие нескольких экземпляров или _версий_ проекта, работающих на одном сервере, без их конфликта друг с другом.
• Или, короче, .fig/project-name содержит имя _этого экземпляра_ проекта.

Возможно, файл должен называться instance-name или аналогичный.

Мне нравится идея сделать имя проекта настраиваемым из файла

Хотя _возможно_ сделать это с этим предложением (вручную создав файл project-name ), моим основным вариантом использования было _fig_ создать файл, чтобы сохранить используемое имя.

приведет к созданию множества очень маленьких файлов.

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

Думаю, проще было бы просто положить в fig.yml

Я думаю, что оба варианта могут дополнять друг друга; используйте имя из fig.yml по умолчанию, если имя не переопределено флагом или переменной env. Поместите имя, которое фактически используется для _старта_ проекта, внутри .fig/project-name

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

Любопытно; как вы справляетесь с управлением несколькими проектами? Т.е. cd project-a && fig ps тогда cd project-b fig <something> ?

Спасибо за ваш отзыв!

Любопытно; как вы справляетесь с управлением несколькими проектами?

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

Я думаю, что оба варианта могут дополнять друг друга

Круто, согласен.

Я не знаю, продаются ли мне .fig/instance-name сравнению, скажем, .fig-instance.yml которые могут содержать любые переопределения для конкретного экземпляра, но я думаю, что это скорее второстепенный вопрос.

Обдумывание названия проекта; Если я правильно понимаю вашу ситуацию, важно иметь возможность контролировать создаваемые _изображения_, например, myapp:build12345 , или также имена _контейнеров_? Просто чтобы «почувствовать» вашу ситуацию.

Мои мысли о "случайных" именах проектов заключались в том, что, пока Fig может находить контейнеры для проекта, красивые имена не важны. Если я, как пользователь, могу получить доступ к контейнеру служб через его имя службы (например, fig stop web ), имя реального контейнера не имеет значения.

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

Есть ли какие-либо мысли о «неявном» создании файла «имя проекта» или «явно» через fig init ? Возможно, если у меня будет немного времени во время предстоящих праздников, я смогу немного поэкспериментировать (никогда ничего не кодировал на Python, так что это будет действительно экспериментально :))

важно иметь возможность контролировать создаваемые образы, например myapp: build12345 , или также имена контейнеров?

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

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

• сценарии очистки для удаления старых контейнеров, возможность определить, какой проект создал контейнер
• отладка / проверка контейнеров

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

Даже думал, что fig может отслеживать контейнеры по идентификатору в локальном хранилище внутри каталога .fig

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

Есть какие-нибудь мысли о "неявном" создании файла 'project-name' или "явно" через fig init?

Я предполагаю, что неявно будет более обратно совместима. Я бы хотел избежать fig init крайней необходимости. Вместо использования basedir я мог видеть, что он неявно создает имя проекта <basename>-<4 digit random id>

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

@ frank-dspeed благодарим за добавление вашего варианта использования. Если я правильно понимаю, вы _запускаете_ свои контейнеры с помощью fig, но после этого _ "управляете" _ ими напрямую через Docker, используя соглашение об именах, которое использует Fig?

Возможно, это вас тоже заинтересует: https://github.com/docker/docker/pull/9882 - наличие метаданных предложит больше способов идентификации контейнеров, а не только их имени.

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

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

когда я правильно понял ваше предложение, генерация случайного имени сделает бесполезными опцию FIG_PROJECT_VARIABLE и --project-name . что удобно для сервисов "шаблонов".

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

Я не совсем уверен; Фиг «тихо» перезаписывает контейнеры других проектов, потому что, если он оказался в каталоге с тем же именем, иногда неприятно.

когда я правильно понял ваше предложение, генерация случайного имени сделает параметр FIG_PROJECT_VARIABLE и --project-name-option бесполезным. что удобно для сервисов "шаблонов".

После обсуждения выше, я думаю, что что-то вроде этого сработает

• Если --project-name , используйте это (и напишите / обновите .project-name ? Не уверен)
• --project-name не предоставляется, но FIG_PROJECT_NAME есть, используйте FIG_PROJECT_NAME (и запишите / обновите до .project-name ?)
• Ничего из вышеперечисленного, но .project-name не установлено, используйте .project-name
• Ни один из вышеперечисленных; создать _случайное_ имя и записать его в .project-name

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

и все же я очень интуитивно почувствовал, что имя каталога используется в имени результирующих контейнеров, когда я только что запустил fig up .
и, скажем, вы посмотрите на docker ps -a , это не будет очень полезно, если оно заполнено случайными именами.

поможет ли вариант --random-name в вашей ситуации?
Кроме того, я думаю, что возможность добавить [a-zA-Z0-9_].* чтобы отразить некоторое пространство имен, была бы полезна для более широких развертываний.

Как насчет использования fig.yml для хранения такой информации?

schema-version: 1.1
project_name: foo
containers:
  web:
    build: .
   command: python app.py
    links:
     - db
    ports:
     - "8000:8000"
  db:
    image: postgres

И чтобы сохранить BC, в compose / project.py :: from_config

<strong i="9">@classmethod</strong>
    def from_config(cls, name, config, client):
        if 'schema-version' not in config:
            config = {
                'schema-version': '1.0',
                'containers': config
            }
        dicts = []
        for service_name, service in list(config.containers.items()):
            if not isinstance(service, dict):
                raise ConfigurationError('Service "%s" doesn\'t have any configuration options. All top level keys in your docker-compose.yml must map to a dictionary of configuration options.' % service_name)
            service['name'] = service_name
            dicts.append(service)
        return cls.from_dicts(name, dicts, client)

@jderusse Я очень за то, что вы предложили. Может быть, вы хотите добавить свое предложение в № 45, так как это, вероятно, лучшее место для его обсуждения?

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

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

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

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

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

@dnephin sgtm

@mikehaertl В моем .docker-compose , но файл также может работать, в зависимости от того, сколько информации мы хотим сохранить

@thaJeztah Ах да, прости. Я пропустил это.

@mikehaertl просто переименовал их с .fig в .docker-compose ;-)

Правильно :)

На самом деле я бы предпочел простой файл. Как насчет стиля ini? Сверху глобальные параметры, конкретные параметры команды в разделе:

project-name = blabla

[build]
no-cache

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

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

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

версия клиентского API

возможно docker_host ?

Это тоже звучит неплохо (добавлено)

Я просто столкнулся с этой проблемой.

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

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

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

Прямо сейчас я пытаюсь понять, как предотвратить наступление настроек docker-compose в /home/alice/myproject и /home/bob/myproject на контейнеры друг друга. Есть ли способ получить имена контейнеров из полного пути к файлу, а не только из последнего имени каталога?

@ chris-martin Это просто обходной путь ...

alias docker-compose="docker-compose -p ${PWD}"

docker-compose удаляет / из имен проектов?

Задокументировано ли, какие символы разрешены в названиях проектов?

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

Он обеспечивает некоторую защиту, если вы склонны помещать все свои репозитории git в один и тот же каталог (например, $ HOME или $ HOME / projects), но это создает проблемы, если вы используете другую структуру (скажем, один каталог на организацию, как я часто делают), или если ваш компьютер использует boot2docker, который имеет тенденцию к утечке информации среди пользователей одного и того же устройства, если вы не позаботитесь о том, чтобы докер-машина предоставляла вам разные виртуальные машины.

Я думаю, что # 2294 или просто более гигиеничная работа с докер-машиной тоже решит мои проблемы.

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

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

С новым синтаксисом v2 это можно реализовать, как указано в https://github.com/docker/compose/issues/745#issuecomment -74028861

На самом деле это всего лишь container_name_prefix , не так ли?

@ schmunk42

На самом деле это просто префикс имя_контейнера, не так ли?

Он также используется как volume_name_prefix , image_name_prefix и network_name_prefix , поэтому я предполагаю, что project_name - это более общий термин.

.docker-compose звучит знакомо для docker-compose.override.yml во многом. Кроме того, зачем вводить другой формат конфигурации (например, ini), когда у нас уже есть YAML?
Поэтому я поддерживаю предложение @jderusse в # 745 (комментарий) добавить ключ project_name к docker-compose.yml , чтобы включить вариант использования @JosephEarl.

Индивидуальную настройку пользователя уже можно реализовать, используя docker-compose.override.yml и исключив ее через .gitignore .
Если требуется третий явно определяемый пользователем файл переопределения, я бы предложил .docker-compose.local-override.yml .

Что касается структуры YAML, я бы предложил создать новый ключ верхнего уровня под названием project , который содержит project_name и может содержать другие переменные в будущем. Это позволяет избежать загрязнения пространства имен верхнего уровня. Проиллюстрировать:

project:
  project_name: "your-project"
  network_prefix: "abc"

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

• Первый случай: «просто дайте сети уникальное имя, но мне все равно, какое именно». В этом случае достаточно project_name .
• Другой случай - это сети, на которые ссылаются внешние системы. В этом случае в любом случае, вероятно, лучше явно указать сами имена сетей.

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

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

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

1. Используйте --project-name если указано
2. Если указано, используйте COMPOSE_PROJECT_NAME .
3. Используйте project_name ключ из docker-compose.yml (или там, где этот параметр хранится).
4. Используйте basename каталога проекта

Я не уверен в приоритете 2 против 3:

• Для согласованности с --project-name , COMPOSE_PROJECT_NAME определенно должно переопределять project_name: .
• Но: если COMPOSE_PROJECT_NAME имеет приоритет над project_name: это позволяет случайно использовать неправильное имя проекта из-за установленной переменной среды; это может быть сложно отладить. Может быть, в этом случае может возникнуть предупреждающее сообщение?

как насчет введения нового свойства container_name_pattern со значением по умолчанию %(project_name)s_%(service_name)s_%(instance_number)s для сохранения BC
этот параметр позволяет нам изменить его на hardcodedproject_%(service_name)s_%(instance_number)s и окончательно исправить эту проблему.

Я только что столкнулся с этой проблемой после того, как искал эту функцию в течение 10 минут.

Первое, что я сделал, - это поискал правильный ключ в документе Compose File Reference, поэтому +1 для project_name key в docker-compose.yml

: +1: для стратегии @ cr7pt0gr4ph7

+1 за стратегию @ cr7pt0gr4ph7

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

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

https://github.com/docker/compose/issues/745#issuecomment -182296139 звучит правильно. Переменная среды будет иметь приоритет над значением в файле создания, которое действует как значение по умолчанию (при условии, что имя проекта принадлежит файлу создания).

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

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

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

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

Если вы сделаете что-то вроде docker-compose -f compose1.yml -f compose2.yml up и оба файла определяют имя проекта, используемое имя должно быть от compose2.yml .

Я думаю, что все уже нашли решение, которое мне нравится: -) То есть project_name в docker-compose.yaml. Я просто хочу упомянуть еще один вариант использования имени проекта в файле docker-compose.yaml:

На страницах внутренней ошибки сервера HTTP 500 в моем проекте я говорю разработчику, как исправить или устранить проблему, например, я говорю ему / ей, что он / она может zcat database-dump.tgz | docker exec -i projectname_db_1 psql если сервер замечает, что нет базы данных PostgreSQL и пользователь был создан - и затем я хочу сам выбрать projectname , иначе сообщения справки не могут быть скопированы в консоль.

Согласитесь, что должно быть предупреждение, когда COMPOSE_PROJECT_NAME переопределяет имя проекта в compose.yml - такое поведение имеет смысл на основе существующих команд Docker, но не особенно логично или очевидно для новичка.

+1 за стратегию @ cr7pt0gr4ph7

Пытался что-то искать, прежде чем сам открыть проблему, так как ничего не нашел.
+1 за project_name в файле docker.compose.yml. С v2 я думаю, это становится все более и более осмысленным.

Согласитесь, что должно быть предупреждение, когда COMPOSE_PROJECT_NAME переопределяет имя проекта в compose.yml - такое поведение имеет смысл на основе существующих команд Docker, но не особенно логично или очевидно для новичка.

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

Можно ли было бы создать PR, который просто использует project_name из docker-compose.yml чтобы начать работу? Или нам нужны дополнительные вещи, такие как использование значения project_name из последнего файла yml который немедленно ссылаются?

Как насчет этого?

version: "2"
project:
    default_name: "app"

Я изменю свою реализацию (https://github.com/docker/compose/pull/3118) для этого формата. Но я не уверен, нужен ли раздел project ....

+1 желаю увидеть эту функцию

@timgriffiths , похоже, это возможно в последнем RC, добавив файл среды в ваш проект:

• https://docs.docker.com/compose/env-file/
• https://github.com/docker/compose/releases/tag/1.7.0-rc1

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

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

+1 У нас есть ситуация, когда в нашем файле компоновки есть ссылки на предварительно настроенные удаленные тома. Compose автоматически добавляет имя проекта к тем именам томов, которые затем не удается подключить из-за несовпадения имен. Возможность явно указать имя проекта в файле compose yml сделает соглашение об именах более очевидным для других участников проекта, вместо того, чтобы скрывать переменные среды в неясных внешних файлах, которые могут различаться в разных средах.

@edevenport в вашем случае вы можете использовать внешний параметр именованных томов:

# docker-compose.prod.yml
volumes
  dbdata:
    external:
      name: my-project-db-data

Спасибо @fesor - мне следовало более подробно

    ...
    volumes:
      - media:/data/media:ro

volumes:
  media:
    driver: glusterfs

В этом случае media становится projectname_media на хосте и не может быть смонтирован, если том glusterfs не создан заранее с именем проекта. Я думал монтировать тома glusterfs на хосте вручную и использовать external в файле docker-compose, но я бы предпочел не делать это вручную на всех узлах заранее.

@edevenport Я понимаю это. Но вы можете просто добавить этот том вручную с помощью docker volume create и использовать его:

    volumes:
      - media:/data/media:ro

volumes:
  media:
    external:
      name: my-glusterfs-media

Так что нет необходимости менять проект и избавляться от префиксов.

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

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

@timgriffiths Я сделал пиар (https://github.com/docker/compose/pull/3118) - может, это поможет. Но он не справится с вашим случаем, если у вас есть несколько файлов compose.

@fesor, что PR был бы идеальным, есть ли возможность его объединить?

Теперь Compose предоставляет файл среды , поэтому имя проекта может быть сохранено в нем.

@mkuzmin жаль , что есть COMPOSE_FILE а нет COMPOSE_OVERRIDE_FILE .

@fesor AFAIK вы можете указать несколько файлов

@ schmunk42 Я

docker-compose up -d

вместо

docker-compose -f $COMPOSE_FILE -f $COMPOSE_OVERRIDE_FILE \
            up -d

COMPOSE_PROJECT_NAME в примере выше определяется CI. И такая функция, как .env file - это круто, но ... бесполезно в случае сохранения имени проекта.

Я использую .env для DRY переменных env (а для docker-compose <1.7 у меня есть простая оболочка), но это не решает никаких других проблем. @timgriffiths уже указывал на случай с развертыванием в кластере роя.

COMPOSE_FILE=one.yml:two.yml - это как установить несколько файлов. Так что просто включите файл переопределения в $COMPOSE_FILE

@dnephin пропустил эту функцию, круто.

Что ж ... о развертывании роя, я уже обрабатываю это с помощью COMPOSE_PROJECT_NAME в переменных ENV моего задания jenkin, поэтому проблемы только с развертыванием вручную. И моя реализация не позволяет переопределить имя проекта по умолчанию, поэтому ...

Этому вопросу почти 2 года, и он до сих пор не решен. Интересно, что именно мешает команде докеров наконец добавить правильное исправление. Неужели так сложно добавить новую простую директиву конфигурации для файлов docker-compose.yml ?

Хотя обходной путь с .env хорош, его нельзя использовать всегда (файл .env может уже использоваться вашим приложением). И это тоже обходной путь.

И я даже видел другие новые проблемы, которые могут быть связаны с появлением названия проекта в последних версиях (# 3966).

Так в чем проблема на самом деле?

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

Нет! Проблема никогда не заключалась в сложности реализации.

Хотя обходной путь с .env хорош, его нельзя использовать всегда (файл .env может уже использоваться вашим приложением). И это тоже обходной путь.

Это не обходной путь, это решение! Файл .env содержит переменные среды, которые должны быть прочитаны Compose. Если у вас есть переменные среды, которые должно читать ваше приложение, поместите их в другой файл (скажем, app.env ) и укажите на него ссылку с помощью параметра env_file .

Так в чем проблема на самом деле?

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

Добавление имени проекта в файл docker-compose.yml делает его менее переносимым,

Разве это не может быть необязательным? Лично я никогда не проверяю свой docker-compose.yml а только добавляю docker-compose-example.yml в свое репо, которое я настраиваю локально. Например, во время разработки я могу добавить несколько дополнительных переменных окружения или отобразить дополнительные тома в свой контейнер. Почему бы также не дать нам возможность указать название проекта?

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

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

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

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

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

Как добавление имени проекта в docker-compose.yml делает его менее переносимым?

ИМХО, на самом деле все наоборот, как показано в # 3966, созданном @mikehaertl. Эта проблема ясно показывает, что отсутствие имени проекта, хранящегося в docker-compose.yml фактически делает вещи менее переносимыми (например, с большей вероятностью столкнуться с другими проектами Compose, запущенными на том же компьютере), поскольку Compose полагается на соглашение о имя папки контейнера, которое многие люди, по крайней мере, поначалу, не знают.

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

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

клонировать репо
докер-сочинять

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

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

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

Если разрешены именованные контейнеры, почему нельзя разрешать именованные проекты?

Пример использования, в котором было бы удобно определение имени проекта в файле .yml, следующий:
У нас есть один и тот же файл docker-compose для разных веб-серверов (разные учетные данные базы данных, разные объемы данных, некоторые небольшие различия, такие как логотип и т. Д.). На каждое запущенное приложение приходится 3 службы, и они настраиваются в файле создания. Когда несколько серверов работают рядом друг с другом, было бы неплохо увидеть, какая служба принадлежит какому проекту.

Пригодится подстановка переменных в имени контейнера с префиксом $ COMPOSE_PROJECT_NAME. Хорошо, я понимаю решение .env-файла, но это не делает его более "удобным для разработчиков" в среде развертывания (CI).

На мой взгляд, наличие одного контейнера уничтожения docker-compose с совершенно другим docker-compose из-за того, что не было установлено -p или переменной среды и вы создали docker-compose во вложенной папке «docker».

При серьезном развертывании просто слишком много места для ошибки. Просто забудьте указать имя проекта, будь то в -p, .env или в другом месте: вы отключаетесь на некоторое время, пока не заметите, что произошло. Хуже того: отключается сервис коллизий, а не тот, над которым вы работаете. У тебя будет счастливый день :(

@dnephin Что именно удерживает команду

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

Если это будет реализовано, подумайте о BC.

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

@ schmunk42 Мы не говорим, что функция .env должна быть удалена. Если вы предпочитаете, чтобы имя вашего проекта было в .env просто не настраивайте его в docker-compose.yml .

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

Пожалуйста, добавьте названные проекты. Пример использования:
Проект первый:
docker-compose up --build --remove-orphans

• nginx
• статический контент
  Второй проект:
  docker-compose up --build --remove-orphans
• nginx
• статический контент

Когда запускается второй проект, он убивает контейнеры первого проекта с выходом 137 (код 128 + уровень 9).

Теперь мне нужно запускать docker system prune и каждый день перестраивать сети, чтобы не иметь десятков мертвых контейнеров.

export COMPOSE_PROJECT_NAME=somethingnew

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

Пока что единственным аргументом было сохранить переносимость docker-compose.yml . В этом нет смысла, потому что

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

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

@mikehaertl У вас уже есть постоянные названия проектов. Просто поместите .env file и установите там переменную COMPOSE_PROJECT_NAME . Я больше не вижу пользы от имени проекта в файле композиции.

@fesor У меня обычно нет файлов .env под контролем версий, потому что они содержат настройки, зависящие от машины / среды - именно поэтому я хотел бы, чтобы имена проектов настраивались в файле docker-compose.yml .

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

@fesor Мне очень жаль, но я не думаю, что личные предпочтения - реальный аргумент. Настоящий вопрос не в том, почему мы не хотим использовать .env или переменную окружения. Все наоборот: почему он не был помещен в конфигурационный файл, которому он принадлежит?

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

И снова: никто не забирает у вас старую опцию - нам только наконец нужна эта дополнительная опция. Это честно.

@dnephin : Кажется, что вы и все остальные довольны решением, указанным в уточнении этой проблемы cr7pt0gr4ph7 .

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

@ cr7pt0gr4ph7

@dnephin @fesor, имеющий имя проекта в * compose.yml, упрощает единую схему конфигурации

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

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

Если значение по умолчанию неверно, разработчик может его переопределить ( -p или COMPOSE_PROJECT_NAME ), которые могут быть псевдонимами или помещены в файл .env .

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

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

_Почему я исключаю COMPOSE_PROJECT_NAME и -p: _
COMPOSE_PROJECT_NAME и -p, на мой взгляд, не сохраняются в производстве, так как вы должны не забыть их установить. Или создайте сценарий запуска и не забудьте не использовать docker compose up напрямую. Когда Человек А полагается на этот механизм, а Человек Б этого не знает, это определенная неудача.
(Я уже подробно описал это выше)

@dnephin Для меня и моей команды логика приложения обычно хранится в папке htdocs в папке нашего проекта. Это позволяет нам хранить другие связанные документы / ресурсы вместе в одном каталоге. В качестве разработчика работает с удаленными разработчиками. Мне легко заставить их принять Docker, если мне не нужно ничего предполагать о структуре их папок. Я уже говорил об этом раньше, .env - не вариант для меня, потому что обычно он не является частью общего репо.

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

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

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

Может быть, это правда для вас - это не для меня и многих других. Структура моего приложения похожа на myapp/app/docker-compose.yml . Итак, все мои приложения используют имя каталога app . И у меня на хосте больше 1 контейнера.

Если значение по умолчанию неверно, разработчик может переопределить его (-p или COMPOSE_PROJECT_NAME), который может быть псевдонимом или помещен в файл .env.

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

Вместо того, чтобы спрашивать нас снова и снова и игнорировать наши ответы, почему кто-то не может наконец оправдать сопротивление. И нет: «... но мне это не нужно» - не верный аргумент!

@dnephin У меня есть несколько проектов в их собственных репозиториях git, и чтобы поддерживать чистоту корневых каталогов проектов, я помещаю все, что связано с докерами, в подпапку с именем docker (контекст сборки просто становится .. , все прекрасно работает).

Чтобы запустить несколько проектов на одном сервере, мне сейчас нужно создать docker/.env.dist в каждом репо и cp docker/.env.dist docker/.env после git clone . В противном случае имя проекта будет просто docker , что мне явно не нужно. В некоторых случаях .env содержит пароли и т. Д., Поэтому в любом случае требуется копирование .env.dist , но в большинстве случаев .env существует просто потому, что нет способа определить COMPOSE_PROJECT_NAME в docker-compose.yml .

Я понимаю, что могут быть сбои в запуске и остановке контейнеров, если один и тот же COMPOSE_PROJECT_NAME дважды используется внутри docker-compose.yml , но это уже происходит, если я забыл скопировать .env.dist или когда я случайно назначаю одно и то же имя двум разным файлам .env на одном сервере. Для меня было бы идеально, если бы я мог определить default_compose_project_name прямо в docker-compose.yml а затем переопределить значение в .env если, скажем, я хочу запустить промежуточную копию некоторого проекта. . Это будет 100% BC, но удобнее.

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

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

Возможно, docker-compose.env был бы правильным выбором.

FWIW: мы изменяем только файлы .env в производстве, файлы yml объединяются с docker-compose.override.yml если это необходимо.

Обходной путь также состоит в том, чтобы определить ваши файлы yml таким образом, чтобы они не запускались без файла .env , например. используя переменную image: $IMAGE .

Это обходной путь для моих 4 файлов docker-compose в 1 каталоге, указанном выше @ schmunk42 ? В самом деле?

@RobIsHere Но вам все равно нужно использовать -f , верно?

В ответ @dnephin в этом комментарии :

Мне непонятно, почему название проекта имеет значение.

Это важно, потому что это влияет на имя контейнеров Docker, которыми управляет docker-compose . Если вы забудете указать имя проекта, docker-compose ps не найдет контейнеры, которые вы создали ранее с помощью docker-compose --project-name <project_name> up -d <container_name> .

Кроме того, когда вы запускаете глобальную команду docker ps , имя проекта будет включено в список запущенных контейнеров, чтобы вы знали, откуда они. Например, если вы тестируете сразу несколько проектов кода, которые все используют MySQL, и каждый из них имеет контейнер mysql , тогда docker ps покажет неоднозначный список контейнеров. Таким образом, имя проекта важно в контексте многих проектов Docker, работающих на одном компьютере.

Никакая часть файла конфигурации не должна полагаться на какое-либо конкретное имя проекта.

Не имеет смысла устанавливать имя проекта в другом месте, чем _все другие переменные, связанные с проектом Docker Compose_.

Единственное важное качество имени проекта состоит в том, что оно не конфликтует с именем любого другого проекта, что на самом деле является аргументом против помещения его в файл docker-compose.yml.

По причинам, указанным в моем первом абзаце, это не _ "единственное важное качество названия проекта" _. Это для простоты использования и понимания.

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

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

Если значение по умолчанию неверно, разработчик может переопределить его (-p или COMPOSE_PROJECT_NAME), который может быть псевдонимом или помещен в файл .env.

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

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

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

Практически все, кто подписался на этот выпуск, согласны с этим.

Добавление возможности установить имя проекта в docker-config.yml даже не будет конфликтовать с какой-либо текущей функциональностью. Нет причин не реализовывать его.

@ schmunk42 В прошлый раз, когда я проверял, докер не позволял нам выбрать имя нашего файла .env. Я что-то пропустил (сложно угнаться за изменениями). Изменение его на что-то вроде docker-compse.env исправит его для моего варианта использования. Моя проблема в том, что я использую две очень популярные технологии, для которых требуется файл .env. Фреймворк PHP Laravel не отслеживает этот файл в репозитории, а в производственных средах он иногда не существует.

Я обнаружил, что это настоящий тупик при первом использовании Docker, потому что, например, @RobIsHere это иллюстрирует. Все каталоги моих проектов имеют формат myapp/htdocs/docker-compose.yml . В первые дни внедрения Docker я случайно удалил другие контейнеры, которые не собирался делать. Было бы лучше, если бы докер назвал проект случайным образом, а не использовал имя папки в моем случае.

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

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

Случаи, когда значение по умолчанию не подходит:

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

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

@dnephin В этом комментарии у вас также были эти опасения:

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

Установка порядка приоритета разрешения имени проекта, как это, решит эту проблему (большие числа имеют приоритет перед меньшими):

1. docker-compose.yml
2. Переменная среды COMPOSE_PROJECT_NAME
3. Параметр командной строки --project-name

В прошлый раз, когда я проверил, докер не позволил нам выбрать имя нашего файла .env.

@fiveanddone AFAIK, вы не можете этого сделать, но это также просто переместит проблему, поскольку тогда вам нужно будет знать, какой ENV-файл вам понадобится для проекта.

В нашем случае с phd5 мы переместили (app) -environment в src/ а .env - это исключительно «файл control-environment-file», я попытался объяснить это здесь .
Мне это не нравится, и я бы не стал менять это самостоятельно. Я знаю, что для многих проектов это может быть невозможно.
Но наличие .env из вашего приложения на том же уровне, что и ваш docker-compose.yml становится супер-раздражающим, потому что а) вы получаете переменные в своей "контрольной среде", которые не принадлежат ей и б) вы должны перенаправить эти переменные в свой контейнер, если они вам там нужны, и c) вы больше не можете переопределить / изменить их в своем файле app.env .

@dnephin Что насчет того, чтобы ввести docker-compose.env в качестве предпочтительного файла env и использовать .env в качестве запасного. Вы сделали то же самое с fig.yml один раз.

Я не думаю, что это решает проблему для всех. Именование файла .env кажется мне другим вопросом.

Я думаю, что суть проблемы в следующем:

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

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

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

1. --project-name (всегда отменяет)
2. COMPOSE_PROJECT_NAME переменная среды
3. Значение по умолчанию, определяемое пользователем, отдельно от любого версионного файла
4. Значение по умолчанию, определяемое проектом, которое можно проверить в
5. Имя каталога (по умолчанию, если ничего не указано)

(3) может быть достигнуто с помощью файла .docker/project-name (как предлагается в OP)
(4) может быть достигнуто с помощью поля в файле docker-compose.yml

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

@dnephin относительно 3, позволяя пользователю установить значение по умолчанию, для этого нужны переменные env, нет необходимости создавать файл

Хм ... А что, если немного обобщить проблему и просто ввести default_environment section в docker-compose.yml ? Таким образом, мы сможем установить COMPOSE_PROJECT_NAME не вводя специального поля в yaml, но также сможем определить другие переменные по умолчанию, которые, вероятно, будут присутствовать в другом месте файла. Это сократит количество случаев, когда нужно скопировать .env.dist в .env и стоимость того, что вы это забудете, будет меньше.

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

# ~/projects/sketches/sketch-42/docker/docker-compose.yml
version: "2"
default_environment:
  - SUBDOMAIN=sketch-42
  - ROOT_HOST=example.com
  - COMPOSE_PROJECT_NAME=sketch-42
services:
  web:
    build:
      context: ../
      dockerfile: docker/Dockerfile
    environment:
      - VIRTUAL_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - VIRTUAL_PORT=80
      - VIRTUAL_NETWORK=proxy
      - LETSENCRYPT_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - LETSENCRYPT_EMAIL=admin@${ROOT_HOST}
    restart: always
    networks:
      - proxy

networks:
  proxy:
    external:
      name: proxy

Этот yaml очень похож на то, что я часто использую - он описывает скетч vis, который всегда имеет службу с именем web , но также может быть поддержан мини-сервером API и, возможно, контейнером с базой данных. Предполагается, что https://github.com/jwilder/nginx-proxy находится в начале всего и прослушивает реальные порты 80 и 443.

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

Имея в своем распоряжении секцию default_environment , я мог бы разместить все свои производственные переменные в одном файле, и мне не пришлось бы копировать .env.dist на сервере. На локальном компьютере в приведенном выше примере я бы просто поместил одну переменную в .env , которая будет ROOT_HOST=example.com.dev (или, может быть, я мог бы даже export ROOT_HOST=example.com.dev в профиле bash? )

Подводя итог, можно сказать, что раздел default_environment в docker-compose.yml может не только решить проблему, которую мы в настоящее время обсуждаем, но также может включить несколько дополнительных приятных трюков, будучи на 100% BC и легким для понимания!

WDYT?

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

Однако имейте в виду, что в свете вышеупомянутого (горячего) обсуждения ваша
решение примерно переводится так: «Вместо того, чтобы добавлять новый файл в
yml, как насчет добавления нового раздела? » :)

Вт, 28.02.2017, 00:02 Александр Качкаев [email protected]
написал:

Хм ... А что, если немного обобщить задачу и просто ввести
раздел default_env в docker-compose.yml. Таким образом мы определяем
COMPOSE_PROJECT_NAME без добавления специального поля в yaml, но
также сможет определять другие переменные по умолчанию, которые, вероятно, будут
присутствует в другом месте файла. Это уменьшит количество случаев
когда .env.dist необходимо скопировать в .env, а стоимость забывания
сделать так будет меньше.

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

~ / проекты / эскизы / эскиз-42 / докер / докер-compose.yml

версия: "2"
default_env:
ПОДДОМЕН = эскиз-42
ROOT_HOST = example.com
COMPOSE_PROJECT_NAME = эскиз-42
Сервисы:
Интернет:
сборка:
контекст: ../
dockerfile: докер / Dockerfile
окружающая обстановка:
- VIRTUAL_HOST = $ {SUBDOMAIN}. $ {ROOT_HOST}, www. $ {SUBDOMAIN}. $ {ROOT_HOST}
- VIRTUAL_PORT = 80
- VIRTUAL_NETWORK = прокси
- LETSENCRYPT_HOST = $ {SUBDOMAIN}. $ {ROOT_HOST}, www. $ {SUBDOMAIN}. $ {ROOT_HOST}
- LETSENCRYPT_EMAIL = admin @ $ {ROOT_HOST}
перезапуск: всегда
сети:
- прокси

сети:
прокси:
внешний:
имя: прокси

Этот yaml очень похож на то, что я часто использую - он описывает vis
эскиз, который всегда имеет службу под названием веб, но также может быть скопирован
мини-сервером API и, возможно, контейнером с базой данных. Предполагается
что https://github.com/jwilder/nginx-proxy сидит впереди и слушает
к реальным портам 80 и 443.

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

Имея в своем распоряжении раздел default_env, я мог бы иметь всю свою продукцию
переменные на месте, и мне не пришлось бы копировать .env.dist на сервер.
На локальном компьютере я бы просто поместил одну переменную в .env, которая была бы
ROOT_HOST = example.com.dev (или, может быть, я мог бы даже экспортировать
ROOT_HOST = example.com.dev в профиле bash?)

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

WDYT?

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

Наличие «project_name» внутри docker-compose.yml решит проблему с нашим стеком.
У нас есть монолитное репо со стандартизированным деревом, обрабатывающим несколько проектов, которое выглядит примерно так:

projectA/infrastructure/docker-compose.yml
projectB/infrastructure/docker-compose.yml
...

Очевидно, что это сложнее, чем в реальном мире, поэтому мы не можем просто переместить файл docker-compose.yml в папку «projectA / projectB».

У нас есть CLI в корне, который спрашивает, какие проекты загружать, и, поскольку имя проекта напрямую зависит от родительской папки docker_compose.yml, мы сталкиваемся с конфликтами.

Поскольку мы сами не пишем команду docker-compose (заключенную внутри нашего сценария CLI), мы не можем просто добавить аргумент «-p» к команде вручную.
Решением для нас было бы всегда генерировать имя_проекта внутри сценария CLI, чтобы при вызове docker-compose мы всегда использовали «-p» на основе absolute_path, но это звучит странно.

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

Почему это возможно определить «имя_контейнера» в файле docker-compose.yml (отключение масштабирования) для службы, но не может определить «имя_проекта» для самого файла docker-compose.yml на том же уровне, что и "версия" / "услуги" / "сети" / "объемы"?

Это кажется необходимым с использованием scale чтобы имена контейнеров были очевидны. (например, <project_name>_<container_name>_1 ).

Это поможет при использовании имени контейнера для DNS.

Пришел сюда в надежде, что это было сделано. Остался разочарован. 3 года +

Да, это одна из самых глупых проблем с юзабилити Docker, и она остается нерешенной.

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

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

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

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

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

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

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

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

Я не хочу, чтобы мои задания CI постоянно «выясняли», каким должно быть имя проекта - оно должно быть четко указано в docker-compose.yml, чтобы мои задания могли его извлечь и использовать.

У вас есть проблема с тем, что ваш стек назван как "build1234" и / или как бы вы хотели использовать имя стека в другом месте, например docker exec build1234_myservice script.sh ?

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

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

Я не хочу говорить вам, что вам нужно менять рабочие процессы, потому что меня тоже раздражала эта проблема.
По сути, это что-то вроде того, что мы относимся к изменениям в docker-compose.yml больше как к изменениям исходного кода, а .env - это исключительно конфигурация. Но я также согласен с тем, что в docker-compose.yml есть несколько вариантов, например network которые сильно зависят от проекта. Возвращаясь к вышесказанному; Я бы определил для сети переменную .env . 🤐

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

Я еще немного подумал о своей ситуации. На самом деле у меня нет проблем с внешней установкой имени проекта, и я делаю это с флагом -p <project_name> , который позволяет изолировать уникальные экземпляры стека в CI и запускать несколько стеков одновременно, если необходимо. Только эта цепочка CI должна знать это имя проекта, чтобы оно могло быть автоматически сгенерировано или случайным (но известным), без проблем. У меня также нет проблем с использованием переменной окружения для переопределения имени по умолчанию, однако я считаю трюк .env неочевидным.

Однако есть и другие ситуации, когда полезно иметь где-то явно определенное _default name_ проекта. Так почему же в качестве источника этого имени берется имя родительского каталога? Для меня это слабое место. Его можно было взять откуда угодно - выбор родительского каталога кажется произвольным и без особой причины (например, почти во всех моих проектах файл docker-compose.yml находится в подкаталоге с именем docker ). Поэтому, если он будет произвольным, сохраните его в более явном месте, например в файле yml, а не создавайте внешние побочные эффекты, влияя на имена родительских каталогов, которые во многих случаях должны быть полностью независимыми от содержимого каталога (в зависимости от года опыта работы с повторно используемыми ресурсами).

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

Если вам нужно что-то еще, кроме случайного идентификатора, то я не вижу реальной альтернативы родительскому каталогу. По крайней мере, у вас есть шанс узнать, откуда «взялся» ваш стек.
Но я также согласен с вами, так как в наших проектах мы тестируем стеки в папках tests которые - без файла .env - также будут плохо конфликтовать друг с другом. Вот почему я предложил предпочесть файл с именем docker-compose.env который, ИМХО, был бы намного понятнее.

Не могли бы вы, ребята, просто закрыть эту ошибку, признав, что вам все равно, или реализовать невероятно простую вещь, которую хочет подавляющее большинство из нас? Это 2,86 года спустя. Слезь с горшка. Принимайте собственные решения или исправляйте свои ошибки. Однако вы хотите на это посмотреть. Делайте больше, чем ничего.

@matsaman и все, кто

Не могли бы вы, ребята, просто закрыть эту ошибку, признав, что вам все равно, или реализовать невероятно простую вещь, которую хочет подавляющее большинство из нас? Это 2,86 года спустя. Слезь с горшка. Принимайте собственные решения или исправляйте свои ошибки. Однако вы хотите на это посмотреть. Делайте больше, чем ничего.

Кто такие «вы, ребята»? В открытом исходном коде сообщество принимает решения и исправляет ошибки других. Докер имеет открытый исходный код. Попробуйте отправить запрос на перенос вместо нытья.

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

CLI arg:

$ cd foo
$ docker-compose up
$ docker-compose -p bar up
... some time later wanting to take down bar forgetting '-p'
$ docker-compose down
Stopping foo_nginx_1 ... done
Stopping foo_mysql_1 ... done
Removing foo_nginx_1 ... done
Removing foo_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

Потерпеть поражение.

Env файл:

$ cd foo
$ source foo.env
$ docker-compose up
$ source bar.env
$ docker-compose up
... some time later wanting to take down foo forgetting to `source .foo.env`
$ docker-compose down
Stopping bar_nginx_1 ... done
Stopping bar_mysql_1 ... done
Removing bar_nginx_1 ... done
Removing bar_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

Потерпеть поражение.

Предлагаемые решения с названием проекта в yml файле:

$ cd foo
$ docker-compose -f foo.yml up
$ docker-compose -f bar.yml up
... some time later
$ docker-compose down
ERROR:
        Can't find a suitable configuration file in this directory or any
        parent. Are you in the right directory?

        Supported filenames: docker-compose.yml, docker-compose.yaml

Ура!

$ COMPOSE_PROJECT_NAME=foo docker-compose up -d
$ COMPOSE_PROJECT_NAME=bar docker-compose up -d
... some time later
$ docker-compose down -v
Removing network project_default
WARNING: Network project_default not found.

O /

Кто такие «вы, ребята»?

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

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

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

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

Если я нахожусь в папке с файлом docker-compose.yml , как мне узнать, какое имя проекта имеет мой стек?
Это довольно простой вопрос, но на него нет простого ответа.

На данный момент (по приоритету):

• значение -p
• значение COMPOSE_PROJECT_NAME из вашей среды
• значение COMPOSE_PROJECT_NAME из вашего .env файла
• имя текущего каталога

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

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

Должно быть хотя бы что-то вроде docker-compose config --project-name . В настоящее время мне нужно знать указанные выше местоположения и проверить их в правильном порядке.

Если я нахожусь в папке с файлом docker-compose.yml, как мне узнать, какое имя проекта имеет мой стек?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

cd /some/path/test
docker-compose up -d
cd /a-completely-different-path
docker-compose -p test down -v --remove-orphans

Это убьет ваш первый стек, будет таким же, как имя проекта в файле yml .

И почему вы не используете один и тот же механизм во всех своих проектах, если он вас так смущает?

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

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

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

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

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

3 из 4 опций в дереве приоритетов бесполезны, если у вас есть несколько именованных файлов compose в каталоге. Не говорите мне создавать подкаталоги, потому что я все еще использую в них файл .env.

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

Вы делитесь файлом .env для конкретного приложения, который используется в env_file ?
Или тот, который использует docker-compose ?
Или вы их смешиваете?

В этом нет смысла. Если кто-то не добавит название проекта в docker-compose.yml, ничего не изменится.

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

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

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

У меня есть общий единственный файл .env, который используют 4 именованных файла compose (в одном каталоге). Без переменных среды. Никаких сценариев оболочки. Я просто сочиняю.

Я бы предпочел это

docker-compose -f service1.yml up -d

Вместо этого это больше похоже на это

docker-compose -f service1.yml up -d
# F#&$, forgot the -p flag.   Curse the compose devs for 3 years of c#*$blocking
docker-compose -f service1.yml down
docker-compose -f service1.yml -p service1 up -d

@ schmunk42, вы серьезно считаете, что это решение набирать 'COMPOSE_PROJECT_NAME = ...' каждый раз для каждой команды docker-compose, возможно, в дополнение к имени файла? Это также требует, чтобы вы знали и запоминали название проекта. Возможность указать имя проекта в переменной среды наверняка имеет его использование, но в некоторых случаях вы просто хотите иметь каталог с парой файлов yml в нем и иметь возможность легко управлять проектами надежным способом без необходимости запомните названия проектов, которые вы выбрали несколько месяцев назад, и не нужно помнить об экспорте переменных среды.

Разве вы не можете использовать одну папку для каждой службы и по-прежнему иметь файл .env в верхней папке?

docker-compose -f service1/docker-compose.yml up -d
docker-compose -f service2/docker-compose.yml up -d

Просто впишите имя проекта в файл (-path) 😉

Я сдаюсь. Очевидно, что клиентская база для этого изменилась.

Сообщите мне, что не так с предложением, которое я вам сделал.

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

Я не могу вспомнить, чтобы случайно не убил стек за последние 2 года никем из нашей команды. Таким образом, мы запускаем> 200 стеков с примерно 1.000 контейнеров и 1.000 автоматических или ручных повторных развертываний.

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

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

@ schmunk42 и @mikehaertl

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

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

На данный момент (по приоритету):

1. значение -p
2. значение COMPOSE_PROJECT_NAME из вашей среды
3. значение COMPOSE_PROJECT_NAME из вашего файла .env
4. имя текущего каталога

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

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

1 + 2. Должен быть предоставлен вручную пользователем, вызывающим команду.

1. _Можно_ поделиться, но на практике .env следует игнорировать и не передавать по уважительной причине. (Я работаю над этим, разделяя .env.example , но это все равно требует дополнительных действий вручную.)
2. Фактически является случайным и зависит от пользователя / среды. (Я также рассматриваю это как запасной вариант, потому что составьте _необходимо_ имя проекта. Это даже не очень хороший запасной вариант, потому что в разных каталогах могут быть проекты с одинаковыми именами, которые могут конфликтовать.)

На мой взгляд, и многие из тех, кто в этом потоке, должен быть вариант, который живет между 3 и 4, где имя проекта по умолчанию _ может_ быть предоставлено в любом файле docker-compose, который используется для этого проекта и используется как первый отступать. Это значение затем будет передано всем, кто развертывает этот проект. Варианты 1-3 переопределят это значение, а вариант 4 будет использоваться только в том случае, если он не предоставлен.

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

@joshuajabbour

1. Можно совместно использовать, но на практике .env следует игнорировать и не использовать по уважительной причине.

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

1. Фактически является случайным и зависит от пользователя / среды.

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

У меня для всех есть последняя альтернатива:

docker stack deploy -c docker-compose.yml the-project-name

(*) Доступно только в режиме роя.

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

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

это внесет огромный источник возможных ошибок в нашу настройку.

Вот в чем загвоздка. Закройте проблему.

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

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

Если вы поделитесь именем, зафиксированным в docker-compose.yml вы также можете зафиксировать .env (этот файл предназначен только для команды docker-compose - ничего больше).

Ну, если бы в моем .env файле было только COMPOSE_PROJECT_NAME , тогда да. Но он заполнен множеством других _secure_ переменных, которые я не хочу фиксировать. И я импортирую их в docker-compose с помощью свойства environment . Вот для чего обычно нужны файлы .env ...

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

@ schmunk42 Вы говорите: «Мне не нужны новые функции, потому что я больше не понимаю настройки моего проекта».

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

Для протокола: я тоже здесь. Смело закрывайте вопрос. Обсуждение здесь стало бессмысленным.

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

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

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

Используйте для них secrets.env и импортируйте его через env_file .
Как это повлияет на ваш рабочий процесс?

Это то, для чего обычно нужны файлы .env ...

Верно ... но я все же думаю, что проблема в том, что docker-compose захватывает файл .env .

Как бы это было, если бы вы могли установить эти переменные плюс те, которые используются на верхних уровнях docker-compose.yml , например IMAGE_VERSION , в файле с именем docker-compose.env ?

Я никогда не осмеливался предложить COMPOSE_COMMAND_ENV_FILENAME=.env - до сих пор :)

Я до сих пор не понимаю, как это нарушит вашу настройку ...

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

Подумайте об использовании нескольких файлов -f docker-compose.A.yml -f docker-compose.B.yml , допустим, A - это ваш проект, и он зависит от имени проекта по каталогу (мы делаем это, так как мы его контролируем!), А B - это набор дополнительных сервисов с project_name: extra , случайно введенных во время тестирования в папку, в которой был файл .env который перезаписал имя проекта на COMPOSE_PROJECT_NAME=testing .

Но теперь любой проект, запущенный без файла .env , будет называться extra . 💥

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

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

Предупреждение: немного не по теме, но все еще связано с докером ...

• "Я не думаю, что нам это действительно нужно"
• «имеет больше слоев, чем необходимо. большая сложность»

@mikehaertl Мне действительно интересно, что вы так это видите;)

Эй, ребята,

Мы подхватили горячую дискуссию в этой теме (спасибо тем из вас, кто поддерживал ее вежливо и сердечно!), И хотя мы по-прежнему твердо верим, что имя проекта не принадлежит файлу Compose, мы все же придумали, что мы считаем, что это разумная золотая середина со следующим PR: # 5378. Тем не менее, мы будем признательны за ваш отзыв, чтобы убедиться, что он отвечает вашим потребностям.

Вот суть:

• Вы можете добавить запись x-project-name в свой файл Compose. По умолчанию этот ключ игнорируется.
• Когда COMPOSE_X_PROJECT_NAME установлен в вашей среде (или .env file), Compose попытается получить имя проекта из записи x-project-name внутри вашего файла Compose.
• Этот параметр имеет более низкий приоритет, чем COMPOSE_PROJECT_NAME и --project-name

Будем рады ответить на любые вопросы или проблемы по этому поводу.

@ shin- Значит, COMPOSE_X_PROJECT_NAME нужно установить на 1 , чтобы активировать эту функцию?

Если да, то COMPOSE_ENABLE_X_PROJECT_NAME тоже может быть названием, о котором стоит подумать, но это всего лишь мои 2 цента - я все равно не буду им пользоваться 😄

@ schmunk42 Любое значение "истина" подойдет , но да, идея именно в этом.

@matsaman Классно , спасибо за полезный, действенный отзыв.

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

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

@ shin - Я объясню, почему это изменение не имеет никакого значения:

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

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

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

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

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

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

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

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

@nhooey @matsaman
Он специально предназначен для помощи людям, у которых есть несколько файлов для создания файлов в одном каталоге, для которых решение .env file не подходит. Если это должно быть всегда включено для ваших проектов, это легко установить в вашем файле .env , в вашем .profile или в любом другом месте, где всегда будет использоваться x-project-name в учетную запись.

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

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

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

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

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

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

С самого начала у нас было .env . Вы явно пропустили весь разговор.

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

Чтобы прояснить некоторую путаницу

Ты уже мог это сделать

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

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

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

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

Если нет ни того, ни другого, просьба уточнить.

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

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

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

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

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

Прелесть docker-compose - это up . Не инструкции по настройке этого вызова.

@fiveanddone

Опять же, размещение .env в репозитории для меня не вариант.

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

@ shin- Да, без проблем.

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

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

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

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

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

@fiveanddone Спасибо за понимание! Итак, если вместо этого файл .env будет называться docker-compose.env (или аналогичный), разве это уменьшит ваши опасения?

@ shin-

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

Docker Compose автоматически загружает файл env?

Если нет, может ли docker-compose.env загружаться автоматически?

@nhooey Файл env загружается автоматически, если он называется .env . И вы также можете указать файл env для каждой службы индивидуально. См. Документы .

Файл env загружается автоматически, если он называется .env. И вы также можете указать файл env для каждой службы индивидуально. См. Документы.

Не быть здесь придирками, но это не совсем правильно. И ИМХО самый большой источник непонимания всей темы.

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

env_file: 
  - .env

или же

environment:
  - VAR_FROM_DOTENV
  - FOO=${ANOTHER_VAR_FROM_DOTENV}

Да, файл .env загружается автоматически, но без дальнейшей настройки он применяется только к этим переменным среды Compose CLI .

Я настоятельно рекомендую переименовать это в docker-compose.env по умолчанию и даже лучше - переменную для этого , чтобы это можно было использовать BC-способом, просто установив одну ENV-var.

(спасибо тем из вас, кто сохранил его вежливо и сердечно!)

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

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

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

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

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

Вот предложение: как насчет добавления двух других вариантов для имени проекта и отказа от использования .env в V4 из docker-compose.yml ? Один - это project_name в docker-compose.yml , другой - файл .dockerproject который содержит только имя и никогда не должен отправляться в репозиторий. Это должен быть локальный файл.

Вот мое предложение о приоритете (сначала наивысший):

• -p аргумент CLI
• .dockerproject файл
• project_name in docker-compose.yml (следует избегать, если docker-compose.yml распространяется вместе с проектом)
• COMPOSE_PROJECT_NAME из среды
• COMPOSE_PROJECT_NAME от .env (устарело)
• имя каталога

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

ОБНОВЛЕНИЕ: я также мог жить с использованием .dockerenv или docker.env вместо .dockerproject . Но для решения проблемы он должен иметь более высокий приоритет, поскольку некоторым здесь необходимо переопределить жестко запрограммированные имена проектов в docker-compose.yml .

Привет всем,

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

Я проверил PR 5378 в тестовом проекте для следующего варианта использования: A default project name defined by the project, that can be checked in (https://github.com/docker/compose/issues/745#issuecomment-282858900). Для этого я сделал репозиторий git, иллюстрирующий различные возможности: https://github.com/estarter/compose_745

Я обнаружил, что PR № 5378 частично покрывает этот вариант использования. Проблема в том, что для решения требуется переменная COMPOSE_X_PROJECT_NAME env. Возможные решения:

1. сохранить переменную env в папке проекта. Я пробовал .env file, но он не работает, когда docker-compose вызывается из другого места (см. Пример команд , создание файлов )
2. определить COMPOSE_X_PROJECT_NAME глобально (.profile или эквивалент). Это сработает, но это не может быть указано в проекте, т.е. это не решение для нашего варианта использования defined by the project, that can be checked in
3. есть еще вариант?

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

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

1. есть еще вариант?

Есть такая опция docker-compose --project-directory <PATH> (укажите альтернативный рабочий каталог). Также должен работать с файлом .env .

Чтобы добавить еще один нюансированный вариант использования:
В моем случае использования у меня есть два репозитория: один для основного проекта (используется для сборки / развертывания) и один для DevOps (содержащий файлы Dockerfile, docker-compose.yml и т. Д.)
В нашей текущей настройке репозиторий основного проекта находится в корневом каталоге ./, а репозиторий DevOps извлечен в подкаталог ./devops/

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

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

Что не работает, поскольку вызывается как: docker-compose -f devops/docker-compose.yml
Конечно, мы можем добавить сюда параметр -p, который мы и используем в настоящее время, но он подвержен человеческой ошибке, как упоминалось выше.

Если файл .env (или предлагаемый docker-compose.env) можно прочитать из того же каталога, где находится docker-compose.yml, то определение имени проекта там сработает.

Использование директивы env_file внутри docker-compose.yml не работает, потому что эти переменные env применяются только внутри контейнера, а не для создания контейнеров.

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

Есть такая опция docker-compose --project-directory(Укажите альтернативный рабочий каталог). Также должен работать с файлом .env.

@ schmunk42 может быть хорошим выстрелом, но --project-directory не работает с файлом .env. Я пробовал следующее, файл .env был проигнорирован ( файлы проекта ):

docker-compose -f PR_5378/docker-compose.yml -f PR_5378/docker-compose2.yml --project-directory PR_5378 down

В дальнейшем я буду удалять комментарии, которые не способствуют конструктивному общению. Мне неинтересно общаться с детьми.

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

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

При добавлении project_name в файл Compose
Мы уже несколько раз подтверждали нашу позицию по этому поводу - см о некоторых из причин, по которым мы против этого изменения. Не то чтобы это было сложно. Не то чтобы мы об этом не думали. Мы потратили много времени на его оценку, и мы чувствуем, что качество проекта в результате слишком сильно пострадает, чтобы оправдать его добавление (в этой форме). Реально говоря, # 5378, вероятно, лучшая уступка, которую мы можем сделать для того, чтобы это работало таким образом, чтобы это работало по подписке и было обратно совместимо (РЕДАКТИРОВАТЬ: конечно, я открыт для предложений, которые улучшат это предложение в рамках этих параметров)

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

С учетом всего сказанного, есть ли кто-нибудь, для кого docker-compose.env + # 5378 не было бы удовлетворительным решением? Я понимаю, что, возможно, это не ваше излюбленное решение, но я спрашиваю, идет ли оно на разумные уступки, с которыми вы можете справиться.

Все шутки в сторону ...

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

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

Надеюсь, это было конструктивно.

@estarter Я бы счел это багом, может стоит

На самом деле я ожидал, что это будет работать с файлом .env в каталоге PR_5378 :

docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

При добавлении project_name в файл Compose

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

Не могли бы вы помочь мне понять, почему у нас есть container_name и даже network в docker-compose.yml ? Первый тоже может быть источником потенциальных конфликтов. И последнее сильно зависит от хоста. Следуя вашей логике, этих двоих (и других) там быть не должно. Я не вижу разницы в project_name .

Пожалуйста, не игнорируйте этот вопрос снова.

@ michael-k Вы говорите, что project_name - это то же самое, что container_name ? Если вы так говорите, то я хотел бы сообщить вам, что один проект может состоять из нескольких контейнеров. Или я вас неправильно понял?

Хотя для network это не обязательно зависит от хоста. Во многих случаях проекту требуется центральная изолированная сеть, в которой один контейнер взаимодействует с другой сетью. И его конфигурации хранятся в папке docker-compose.yml .

@AyushyaChitransh Вы неправильно поняли. Возникает вопрос: почему container_name , network и другие находятся в docker-compose.yml а project_name не должны быть там? Все они имеют одинаковый потенциал для конфликта или конфигурации конкретного хоста, которые не должны использоваться совместно.

@aanи я знаю об этой возможности. То же самое можно сказать и об именах контейнеров, но у нас есть возможность указать имя контейнера в файле compose, верно?

Да, но я не думаю, что это было хорошей идеей.

Из связанного обсуждения. Укажите имя сети в файле docker-compose .

@estarter Я бы счел это багом, может стоит

@ schmunk42, я вижу, что сопровождающие знают об этом - см. On --project-directory в комментарии Джоффри плюс # 4709, # 4933 и # 4841

На самом деле я ожидал, что это будет работать с файлом .env в каталоге PR_5378:
docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

Вы предположили, что --project-directory влияет на параметр -f .
На самом деле это не так, эта команда дает IOError: [Errno 2] No such file or directory: u'./docker-compose.yml'

Очень хорошо, что --project-directory не влияет на -f - иначе представьте, каким кошмаром было бы использовать --project-directory и несколько файлов docker-compose в разных каталогах.

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

Это порядок приоритета, который я привык видеть:

1. жестко запрограммированный
2. вариант cli
3. окружающая обстановка
4. project.rc
5. нормальный по умолчанию

Для project_name настоящее время нет ни варианта №1, ни варианта №4. Это основная проблема, с которой сталкиваются люди, и кажется, что ее легко решить обратным образом.

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

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

Однако цель не в этом. С самого начала мы очень четко понимали, где мы находимся в отношении определения имени проекта в файле Compose.

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

Не могли бы вы помочь мне понять, почему у нас есть container_name и даже network в docker-compose.yml? Первый тоже может быть источником потенциальных конфликтов. И последнее сильно зависит от хоста. Следуя вашей логике, этих двоих (и других) там быть не должно. Я не вижу разницы в project_name.

Для container_name эта опция была введена в самом начале жизненного цикла проекта. Как отметил @ schmunk42 , если бы мы повторили это заново, этого бы точно не было в спецификации. Он постоянно используется неправильно и на протяжении многих лет является источником бесчисленных проблем для пользователей.
Что касается network , я не совсем уверен, как вы сравниваете?

А как насчет упомянутого мной варианта №4? Я видел разговоры о введении .docker-compose для настроек, специфичных для локального каталога. Это было бы намного предпочтительнее (imo), чем введение флагов среды _x_ (которые по-прежнему требуют управления средой).

Это было бы так:

# <my-project-dir>/.docker-compose
project_name: foobar

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

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

@thedeeno По нашему мнению, COMPOSE_PROJECT_NAME внутри файла .env уже выполняет это (с тем же порядком приоритета, что и в вашей схеме). Однако мы слышали от вас, что имя .env - плохой выбор имени, поэтому мы рассматриваем docker-compose.env в качестве альтернативы. Это сработало бы для вас?

На наш взгляд, COMPOSE_PROJECT_NAME внутри файла .env уже выполняет это

@ shin - вот где мы не согласны. Я не думаю, что это так.

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

Это отлично подходит для помощи с number 3 выше, конфигурацией на основе среды.

Это не дает нам выхода ( number 4 ), когда мы не хотим, чтобы среда владела именем проекта.

В моем случае у каждого из наших разработчиков будет свой файл .env (не VC). Он содержит секреты для инъекции в docker-compose.yaml . Люблю это.

Однако мы не хотим, чтобы разработчики контролировали имя проекта, поскольку оно тесно связано с некоторыми инструментами. Поскольку .env не находится в управлении версиями, мы должны заставить наших разработчиков вручную установить COMPOSE_PROJECT_NAME с этим подходом; и это _one_ вещь_ не похожая на другие, потому что это не секрет.

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

Я покажу один пример использования из моей практики:

Я использую .env file, чтобы указать версию изображения, и чтобы избежать странного синтаксического анализа sed / awk / perl / любого другого, я просто перезаписываю значение в CI:

    echo APP_VERSION=$CI_COMMIT_REF_NAME > .env
    docker-compose pull
    docker-compose up -d

позже в docker-compose.yml изображение указывается как:

    image: my.registry.example.net/app:${APP_VERSION}

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

поэтому, возможно, также добавьте поддержку «каталогов», например: docker-compose.env.d/* или .docker-compose.env.d/* или docker-compose.d/* .

но поскольку такой glob может мгновенно создать проблемы с сопоставлением резервных копий редактора ( *~ , *.bak ), вместо этого лучше использовать какое-то расширение: docker-compose.env.d/*.sh

... но опять же, может быть, просто сделать его настраиваемым в docker-compose.yml какие файлы .env корневого уровня загружаются, или это вызовет проблему куриного яйца? я не знаю, как работает парсер конфигурации :)

немного оффтоп, но COMPOSE_PROJECT_NAME env не позволяет полностью управлять префиксом, он все равно будет разделен, чтобы соответствовать A-Za-z0-9_ ... Я хотел использовать - в моем префиксе. (я не могу найти, где я сообщил об этом прямо сейчас, но, черт возьми, это не адресовано)

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

@glensc Это очень много инфраструктуры для управления средой. Я лично не думаю, что это ответственность docker-compose .

Единственное, что я видел в других проектах, это автоматический источник .env

@glensc @thedeeno Итак, в идеале у нас было бы два файла *.env , один из которых предназначался для совместного использования с другими пользователями, а другой оставался закрытым, причем последний переопределял первый, когда оба определяли одну и ту же переменную?

На прошлой неделе я обратился к настраиваемым именам .env в своем комментарии .

Наличие общедоступного docker-compose.env (при автоматическом поиске частных .env ) подойдет нам!

Мы бы относились к нему как к rc-файлу и передали его в систему контроля версий.

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

@thedeeno @glensc Не могли бы вы привести пример использования, когда вам нужен частный файл ENV, заменяющий значения в общедоступном?

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

@ schmunk42 У меня нет такого project_name контролю версий. docker-compose.env решает эту проблему.

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

@ schmunk42 https://github.com/docker/compose/issues/745#issuecomment -346491062

это просто потому, что ТОЛЬКО место для определения ${variables} для значения image кажется .env file.

@glensc Согласен!

Но вместо этого я бы предложил docker-compose.override.env чтобы выровнять его с текущей функцией переопределения для файлов yml .

docker-compose.env
docker-compose.override.env
docker-compose.override.yml
docker-compose.yml

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

@thedeeno, я полагаю, вы это делаете:

environment:
  - ${SECRET_VAR_FROM_DOTENV}

что также должно быть возможно с docker-compose.override.env . Или вы могли бы сделать:

env_file:
  - .env

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

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

В четверг, 23 ноября 2017 г., в 1:15 Тобиас Мунк [email protected]
написал:

@glensc https://github.com/glensc Согласен!

Но вместо этого я бы предложил docker-compose.override.env согласовать его с
текущая функция переопределения для файлов yml.

docker-compose.env
docker-compose.override.env
docker-compose.override.yml
docker-compose.yml

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

@thedeeno https://github.com/thedeeno Я предполагаю, что вы делаете это:

окружающая обстановка:

• $ {SECRET_VAR_FROM_DOTENV}

что также должно быть возможно с docker-compose.override.env. Или ты
мог сделать:

env_file:

• .env

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

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

Не обязательно, для BC docker-compose все равно может смотреть на .env если другие не найдены, как и в случае с fig.yml один раз. Хотя решить следующие случаи может быть непросто:

.env
docker-compose.env

.env
docker-compose.override.env

.env
docker-compose.env
docker-compose.override.env

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

Для меня .env следует использовать во всех случаях. Это файл с особым значением
в более широкой экосистеме.

В ваших третьих случаях это просто файл с самым низким приоритетом.

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

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

Вт, 23 ноября 2017 г., в 1:31 Тобиас Мунк [email protected]
написал:

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

Не обязательно, для BC docker-compose все еще может смотреть на .env, если
другие не встречаются, так же, как когда-то с fig.yml. Хотя может быть
сложно решить следующие случаи:

.env
docker-compose.env

.env
docker-compose.override.env

.env
docker-compose.env
docker-compose.override.env

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

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

Что касается сети, я не совсем уверен, как она сравнивается в вашем уме?

@ shin-

services:
    web:
        build: ./
        networks:
            - my_project_network_on_my_localhost
networks:
    my_project_network_on_my_localhost:
        external: true

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

Я поклонник "4 project.rc", хотя, вероятно, я бы использовал что-то вроде docker-project.yaml вместо другого формата. Это именно то, что описывает исходная проблема. Насколько я понимаю, любое обсуждение включения имени проекта в файл набора должно быть в отдельном выпуске.

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

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

my_project_network_on_my_localhost мне кажется неправильным. Зачем нужно название проекта во внешней сети? Необязательно совпадать с названием проекта создания.

my_project_network_on_my_localhost мне кажется неправильным.

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

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

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

Здесь у нас такой же рабочий процесс. В нашем случае «общее» определение docker-compose почти ничего не сводит , но это единственные вещи, которые действительно используются разработчиками, тестированием, постановкой и производством.
Основные части настроек разработки определены в отдельном файле, автоматическое объединение выполняется через файл .env . То же самое и с настройкой тестирования .

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

(cd tests && docker-compose up -d)
(cd tests && docker-compose ps)
(cd tests && docker-compose run php codecept run)

для тестирования ... или это

(cd production && docker-compose logs -f --tail 100)

для производства (Бонус: вы можете определить DOCKER_HOST in production, чтобы указать на другую машину, но только с docker-compose ).

Но да, это папка, а не файл - и для работы требуется cp .env-dist .env в двух местах, иначе это не сработает с недопустимым файлом набора. Собственно, я просто хотел поделиться этим ИМХО аккуратным рабочим процессом.

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

@dnephin Есть причины.

Да, есть обходные пути. Просьба сделать его более удобным и предсказуемым.

Вот один пример, в котором помогает жестко заданное имя проекта: по умолчанию конфигурация docker traefik создает правила хоста для контейнеров в следующем формате: <service>.<project>.<domain> . Это форматирование изменить непросто. Для наших разработчиков очень выгодно использовать одни и те же fqdns для наших служб docker-compose. Было бы здорово, если бы мы могли использовать настройку с нулевой конфигурацией, поскольку единственный способ гарантировать согласованность - это либо: а) заставить их использовать определенное имя каталога для своего клона; б) вручную указать правила для traefik. Оба - отстой.

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

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

Сохранение имени проекта в файле docker-compose.yml имеет смысл при использовании с другими инструментами, например PyCharm.

Было бы здорово сохранить его в том же YAML-файле, но при необходимости переопределить.

Я думаю, что суть этой проблемы заключается в том, что имя проекта по умолчанию просто (я должен сказать _naively_?) Взято как базовое имя текущего каталога. Это эффективно сжимает пространство имен файловой системы (иерархическое) до плоского, что проблематично из-за конфликтов имен. Например, это вызывает проблемы у людей, запускающих службы в ~/fooproject/master и ~/barproject/master .

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

Однако мне нравится настойчивая идея. Возможность зафиксировать имя проекта в Git - очень распространенный вариант использования. Возможно, чтение файла .env.default до .env - простое решение для этого (который, кстати, позаботится и о давнем # 210)?

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

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

DEFAULT_DOCKER_COMPOSE=~/my-project

function dcompose() {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    /usr/local/bin/docker-compose $@;
    popd &> /dev/null;
}
## maintain auto complete
function _dc {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    _docker_compose;
    popd &> /dev/null;
}

complete -F _dc dcompose

У меня проблема с коллизией изображений, и это выглядит очень странно, что я не могу установить project_name в docker-compose.yml, поскольку это выглядит очень логичным и прямолинейным решением. На самом деле брать имя из папки проекта изначально было плохой идеей. Во многих случаях папки проектов могут быть такими, как / home / project1 / repository, / home / project2 / repository и так далее, в этом случае docker сгенерировал те же имена изображений, как repository_app.

@vedmant Вы можете установить имя изображения в docker-compose.yml , просто используйте image и build .

Итак ... Как насчет разделения проектов по одноименной папке?

docker-compose -f /foo/bar up -d
docker-compose -f /foo/foo/foo/bar down

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

мой .docker-compose / project-name не работал ...
- имя-проекта работало

Я также хотел бы указать имя проекта в docker-compose.yml.

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

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

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

Однако проблема возникает, когда я не хочу, чтобы этот yml-файл специальной задачи располагался в том же каталоге верхнего уровня (или даже в том же репозитории), что и основной docker-compose.yml . Например, возможно, я хочу поместить специальную задачу docker-compose.adhoc.yml во вложенную папку с DOCKERFILE и активами, которые задача требует, хорошо изолированными / сгруппированными вместе, поскольку это собственная забота. Как только я перемещаю его в подпапку, название проекта перестает совпадать. Это означает, что у него больше нет доступа к тем же томам / сетям и т. Д., Определенным в основном проекте.

Если бы я мог указать projectname в docker-compose.yml и docker-compose.adhoc.yml - тогда я мог бы структурировать их, как хочу (даже поместить их в отдельные репозитории), и по-прежнему выполнять их без необходимости постоянно указывать дополнительные аргументы командной строки или переключать переменные среды.

Для меня это настоящая проблема, потому что это вызывает конфликты имен

У меня несколько проектов в структуре

/company
    /ab   # project prefix
        /backend   # actual project
        /webapp
    /cd
        /backend
        /webapp

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

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

/project-1
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside
    /feature
        /new-feature # docker-compose.yml inside
/project-2
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside

Итак, «мастера» и «разработчики» конфликтуют между проектами. Это может решить файл .docker-compose .

@simplesmiler Рискуя повториться, .env уже решает эту проблему.

@ shin- .env часто используется для секретов, не связанных с контролем версий.

Что хочет @simplesmiler, так это способ зафиксировать имя проекта в системе контроля версий _ при сохранении .env вне системы контроля версий_.

Насколько я могу судить, до сих пор нет способа сделать это легко.

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

Мы не работаем вместе. Это моя интерпретация их проблемы. Совершенно справедливо, я могу ошибаться и предполагать.

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

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

Есть ли способ передать имя проекта в систему управления версиями, игнорируя .env? Или это все еще отсутствующая возможность?

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

1 / https://github.com/docker/compose/issues/745#issuecomment -345054893

Это отличные новости! Принимая пиар?

Я давно потерял надежду, но давайте попробуем еще раз:

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

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

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

Я думаю, можно сказать, (почти) все настройки в docker-compose.yml "ограничены" именем проекта .

Как предлагается в # 4841, опция, указывающая, какой файл .env использовать (например, --env-file ), должна быть очень полезной.

@roipoussiere см. https://github.com/docker/compose/issues/4841#issuecomment -414543951

Спасибо @ schmunk42.
Но это означает, что я должен создать такую ​​иерархию, как:

.
├── project_a
│   ├── .env
├── project_b
│   ├── .env

вместо чего-то более простого:

.
├── a.env
├── b.env

Да, см. Также https://github.com/docker/compose/issues/745#issuecomment -345054893 - вам может потребоваться открыть это в новом окне, так как иногда он здесь скрыт : nerd_face:

Я поддерживаю предложение --env-file . Сделал билет только за это. Иди и люби, если тебе нужен этот вариант.

Итак, я прочитал только несколько комментариев по этой ошибке / функции, и тот факт, что обсуждение продолжается и что оно открыто, подводит меня к выводу, что прошло 4 года с тех пор, как это было открыто, и до сих пор нет решения? Можем ли мы принять частичное решение, а затем двигаться дальше ..?

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

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

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

Скорее всего, вы в конечном итоге создадите файл .env и .env.prod и проигнорируете оба из системы контроля версий. Таким образом, вы можете иметь свои ключи test / dev в разработке, а затем ссылаться на них с помощью env_file в вашем файле compose.

Но затем в производственном файле вы ссылаетесь как на .env и на .env.prod в рабочем файле компоновки.

Но вы видите, к чему все идет? Прямо сейчас Docker Compose не позволяет иметь дополнительные файлы env_file . Если файл не существует, Docker Compose взорвется, как только вы попытаетесь запустить Docker Compose.

Таким образом, вам автоматически понадобится файл .env который будет существовать в конце, если вы планируете использовать его с env_file и это также не ограничивается Stripe. У многих веб-фреймворков есть определенные настройки, зависящие от среды, но они будут меняться как при разработке, так и при производстве (например, SERVER_NAME с Flask).

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

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

Пожалуйста, есть ли эта проблема на какой-то дорожной карте?

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

В нашем случае мы можем как бы обойти это ограничение docker-compose, создав COMPOSE_PROJECT_NAME в нашем make-файле.

Я хотел бы, чтобы это настраивалось из самого compose yaml.

Это все еще открыто? Боже мой...

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

Это займет вечность 🤦‍♂

было бы очень полезно иметь эту функцию

эта функция будет очень кстати в проекте, над которым я работаю

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

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

Я бы добавил к этому списку альтернатив переменную ENV.

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

Использование ENV вместо содержимого yaml противоречит философии совместного использования файлов yaml между разными проектами. Фактически, это официально задокументировано: https://docs.docker.com/compose/extends/ (см., Например, «Примеры использования»). Если вы используете один базовый файл yaml, а затем переопределяете файлы для dev, test и prod, и черт знает что еще, нет смысла запускать его под тем же именем проекта или устанавливать имя проекта с помощью ENV / cli. Он просто создаст N * N комбинаций, пока N действительны.

Я просмотрел несколько из этих обсуждений и увидел ТОННУ комментариев от людей, желающих, чтобы имя проекта можно было настроить в файле YML. Но ни одного комментария, объясняющего, почему этого не следует делать. Эти дискуссии начались очень давно.

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

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

services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value

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

services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}

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

@jderusse

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

services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value

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

services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}

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

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

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

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

У нас есть 2 комментария:

https://github.com/docker/compose/issues/745#issuecomment -345054893
https://github.com/docker/compose/issues/745#issuecomment -346487757

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

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

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

(1) Добавление имени проекта в файл YML может сделать проект менее пригодным для повторного использования, поскольку это предотвратит или, по крайней мере, усложнит запуск одного файла YML с более чем одним именем проекта.
(2) «качество проекта в результате слишком сильно пострадает, чтобы оправдать его добавление (в этой форме)»
(3) «Если имя проекта находится в файле компоновки, тогда любые два проекта могут использовать одно и то же имя, что вызовет конфликт, который приведет к поломке обоих проектов».

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

(4) Реализация обратно совместимым способом (приоритет / порядок значений)

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

Опять же, есть официальный способ разделить конфигурацию на базовую, файловую и унаследованную - https://docs.docker.com/compose/extends/. В базовой конфигурации нельзя было указать название проекта.

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

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

Если я задаю имя проекта в файле yaml явно как my-project тогда можно упростить задачу для отдельного экземпляра проекта или там, где я делаю что-то вроде добавления всех моих файлов докеров в папку docker в нескольких проектах.

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name: my-project)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name: some-other-project)

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

project_name: ../(*) так в том же примере

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_a)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b)
├── project_b_copy
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b_copy)

аналогично project_name: ../(../*)

.
├── dev
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=dev_project_a)
├── test
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=test_project_a)

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

Только полушутя: это означает, что для настройки фиксированного имени в моем docker-compose.yml я бы создал файл с желаемым именем, а затем установил бы project_name: name-of-the-file-named-like-the-name-i-want ?

В настоящее время у меня есть загрузка файлов docker-compose в том же каталоге. Например, dc-work.yml , dc-server.yml и т. Д., Которые загружают разные, несвязанные службы.

Когда я запускаю docker-compose up dc-A.yml , а затем запускаю docker-compose up dc-B.yml , Докер ворчит, что есть запущенные сиротские службы (конечно, их нет, это из-за проклятого имени проекта).

Неужели нет способа решить это? Перемещение каждого файла dc-A|B|C|etc.yml в отдельный каталог, а затем переход к каждому из них для загрузки всех моих служб кажется пустой тратой времени, или я что-то упускаю?

Почему не решена эта проблема? Четкое и простое решение было представлено здесь @ cr7pt0gr4ph7 : https://github.com/docker/compose/issues/745#issuecomment -182296139. Он получил много голосов. В ходе обсуждения были затронуты все вопросы. И, что самое главное, он решает множество вопросов для множества людей. Что дает?

Также возникает эта проблема, потому что мы используем фиксированную структуру каталогов проекта с папкой .docker, которая содержит все, что связано с докерами, поэтому я получаю много имен проектов .docker - я работаю над архитектурой микросервисов так что нормально иметь несколько ... но эта маленькая мелочь продолжает мешать -> также, PHPStorm и т. д. не имеют возможности передать аргумент -p / - project-dir, и я не могу действительно используйте для этого .env, потому что, поверьте мне, установка правильного значения будет забыта ...

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

Может быть, добавить свойство в файл docker-compose для установки имени проекта?

@AyushyaChitransh

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

Это лучшее резюме:
https://github.com/docker/compose/issues/745#issuecomment -182296139

Было много дискуссий. В дальнейшем обсуждении нет необходимости. Сопровождающим проекта просто нужно прочитать потоки (во множественном числе) и сделать необходимое.

Для меня это все еще так: https://github.com/docker/compose/issues/745#issuecomment -248644429

Для меня это по-прежнему: # 745 (комментарий)

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

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

@AyushyaChitransh
Мы хотим использовать механизм для установки имени проекта, как описано здесь: https://github.com/docker/compose/issues/745#issuecomment -182296139

1. Командная строка аргумент.
2. Переменная среды (файл .env)
3. Прямо в файле Compose
4. Путь к папке

Не думаю, что есть какие-то возражения.

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

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

Извините за это, но это следует закрыть как wontfix .. (изменить) или выпустить новую ОСНОВНУЮ (!) Версию

@ schmunk42

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

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

1. Что, если файл компоновки загружается из репозитория git, а затем при следующем коммите владелец репо перемещает его в другую подпапку? Или переименовал папку, в которой он находится? Влияние на рабочий процесс уже присутствует, поскольку файлы можно перемещать, и это влияет на название проекта.
2. Если вы полагаетесь на конкретное имя проекта, мы предложили механизм для его обеспечения, либо используя переменную среды (файл .env), либо используя аргумент командной строки при выполнении Docker compose - оба из которых переопределяют любое значение, которое могло быть в файл набора (если он был добавлен по какой-либо причине).

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

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

Моя основная проблема с решением файла .env заключается в том, что этот файл должен находиться в рабочем каталоге выполняемой команды, тогда как docker-compose разрешает файл compose в родительский каталог. Следовательно, становится важным, чтобы все разработчики либо (A) извлекали код в папку с тем же именем (при условии, что файл docker-compose.yml находится в корне репозитория кода), либо (B) запускали команды docker-compose только в корневая папка репо в противном случае создает конфликтующие стеки или (C) они имеют разные имена стека, и вся документация и скрипты должны указывать replace stack name here .

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

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

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

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

@ dc-pm написал: «Учитывая, что Kubernetes теперь де-факто инструмент развертывания для докеров»

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

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

@ dc-pm написал:

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

Дело не только в том, что это не исправили, но и в том, что разработчики активно отказываются это исправлять.

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

Несколько дружеских напоминаний ...
Разработчики с открытым исходным кодом - это не ваши «сотрудники / колледжи», в большинстве случаев они работают в основном бесплатно.
Если это явно проблема для вас, найдите время, чтобы изучить решения (и продвигать PR).

Обвинять - не выход.

https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md

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

Сб, 14 мар 2020 в 03:19, Антуан Гравело [email protected]
написал:

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

Обвинять - не выход.

https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md

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

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

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

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

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

Что было бы более конструктивным путем вперед?

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

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

Привет, ребята, как пользователь я хотел просто поделиться своим вариантом использования. Итак, у меня есть 2 файла docker-compose.yml, один для среды разработки, один для производства. Они находятся в одной папке. У них обоих есть служба с одинаковым названием - «база данных». Я хотел бы развернуть обе эти службы одновременно - только потому, что я могу, мы говорим о контейнеризации, я могу масштабировать столько, сколько захочу. Однако у них разные значения "имя_контейнера".

Итак, я бегу:

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-server_autocat-dev" with the default driver
Creating database-dev ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-server_autocat-prod" with the default driver
Recreating database-dev ... done

Обратите внимание, как написано «Воссоздание базы данных-dev», в то время как я явно имею в виду службу, расположенную в проекте «prod». Фактически перезаписывает существующий контейнер. База данных прекращает работу, и контейнер заменяется последним.

Я делаю это исходя из предположения, что отдельные файлы «docker-compose.yml» означают отдельные проекты, но, очевидно, в реальной жизни это не так. Проект, в котором будет развернута служба, определяется расположением файла docker-compose.yml. Чтобы сделать их частью отдельных проектов, мне нужно отдельно указать имя проекта в переменной среды. Наконец, он работает с этим:

macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-prod docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-prod_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-dev docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-dev_autocat-dev" with the default driver
Creating database-dev ... done

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

В качестве альтернативы я смог объединить службы в один проект, дав им разные имена: «database-dev» и «database-prod». Единственная проблема с этим подходом заключается в том, что появляется предупреждение о том, что ранее созданный экземпляр службы становится сиротой, поскольку он не упоминается в другом docker-compose.yml.

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database-prod                
Creating network "autocat-server_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database    
WARNING: Found orphan containers (database-prod) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Creating database-dev ... done

В этом нет смысла, чб, почему так должно быть. Почему на самом деле так должно быть?

EDIT1: @ dc-pm @CharlieReitzel, что ты думаешь? Можете ли вы прокомментировать мой вариант использования, на всякий случай, если он недействителен :)
EDIT2: я поместил оба файла композиции в отдельные каталоги и вуаля

ооочень?

сопровождающие, здесь есть кто-нибудь?
разработчики ждут 6 лет!

Привет! Я создал проблему в спецификации компоновки, чтобы добавить имя проекта в схему компоновки, поскольку это определяет, что мы можем добавить в файл компоновки.
Как только свойство project-name добавлено в спецификацию compose, мы можем начать реализацию в docker-compose.