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

fig up -d -e HOSTNAME:ci

Другой вопрос: какой контейнер должен устанавливать эту встроенную переданную переменную? Первый, второй, оба?

формат fig up -d -e HOSTNAME:ci мне нравится.

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

Это здорово: +1:

Прямо сейчас есть два возможных варианта:

• После fig up -d -e HOSTNAME:ci мы передаем переменную всем контейнерам и допустим, что мы можем использовать имена переменных, чтобы определить, какой контейнер должен использовать переменную, например:
  Имея web и db контейнер, мы можем просто запустить:

fig up -d -e WEBS_ENDPOINT=192.168.0.40 -e DBS_ENDPOINT=192.168.0.50

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

• Мы также можем использовать имена контейнеров, как в подходе scale=? , но с синтаксисом:
  fig up -d -e <container_name>:<VARIABLE_NAME>:<VARIABLE> , но хорошо ли выглядит:
  fig up -d -e web:HOSTNAME:ci ??
  Может что-то вроде:
  fig up -d -c web -e HOSTNAME:web -e ROLE:ci -c db -e PASS:pass
  где web и db - имена контейнеров, определенные в fig.yml

Но первая идея кажется мне определенно лучше

не могли бы вы показать мне макет файла fig.yml и соответствующую команду CLI
так я могу лучше понять первый вариант?

имена переменных произвольны или они должны соответствовать имени контейнера?

2014-09-30 11:47 GMT + 02: 00 mieciu [email protected] :

Но первая идея кажется мне определенно лучше

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

Ну, я думал только о произвольных именах переменных, но сопоставление их с именем контейнера тоже будет нормально (поскольку фиг использует его «изначально» http://www.fig.sh/env.html). Так что, возможно, это правильный способ: +1:

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

fig up -d -e HOSTNAME:ci

для меня 100% нормально.

Итак, допустим, что:

fig up -d -e WEB_HOSTNAME:ci

передаст переменную во все веб-контейнеры, и если префикс не обнаружен (например, HOSTNAME:ci ), переменные будут переданы всем контейнерам

хорошо, тогда мы, наверное, говорим о разных вещах.

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

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

например, docker -h '$HOSTNAME' jenkins

который в формате fig.yml переводит:

 Дженкинс:
 изображение: aespinosa / jenkins: последний
 имя хоста: ci

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

то, что вы предлагаете, уже сделано
http://www.fig.sh/yml.html#environment, но
только белый список вещей, которые определены в fig.yml как возможные
переменных, что кажется достаточным (автор fig.yml должен
объясните, какие записи можно разобрать из контейнера)

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

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

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

+1 по этой просьбе!

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

+1

+1

Это действительно удобно, если вы храните fig.yml в VCS. Например, наша команда использует опцию Volume:, но все сопоставляют папку контейнеров с разными путями на хост-машине. Итак, нам нужен способ изменить некоторые параметры перед выполнением 'fig up', не изменяя сам файл fig.yml.

Это фрагменты файлов, которые нужно уточнить:

# run.sh
export DIST_FOLDER=~/work/project/dist
fig up

# fig.yml
tomcat:
  image: internal/tomcat
  volumes:
    - "$DIST_FOLDER:/dist:ro"

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

26 ноября 2014 г., среда, 14:34 Дмитрий Пауленка [email protected]
написал:

Это действительно удобно, если вы храните fig.yml в VCS. Например, наша команда
использует параметр _volumes: _, но все сопоставляют папку контейнеров с
другой путь на хост-машине. Итак, нам нужен способ изменить некоторые
параметры перед выполнением 'fig up', без изменения самого fig.yml.

Это фрагменты файлов, которые нужно уточнить:

run.shexport DIST_FOLDER = ~ / work / project / dist

наряжать

fig.ymltomcat:

изображение: internal / tomcat
объемы:
- "$ DIST_FOLDER: / dist: ro "

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

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

# fig.yml
app:
  image: mickey/theapp:${APP_VERSION:latest}
test:
  image: mickey/tests
  links:
   - app

# run
APP_VERSION=1.3 fig up

+1

+1

+1

+1

+1

+1

Есть ли планы по внедрению этой функции?

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

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

Я считаю, что все, что ему нужно, это os.environ() в fig/service.py:_get_image_name()

Ага, извините, я не понял. Я имел в виду разрешение среды внутри самого Fig.

+1

+: 100:

+1

+1

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

db:
  image: postgres:9.3
  volumes:
    - /$APP_NAME/postgresql/:/var/lib/postgresql/data/
  environment:
    - POSTGRES_USER=$CURRENT_USER
    - POSTGRES_PASSWORD=
  ports:
    - "5432:5432"

+1

+1

: +1:

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

• Fig должен поддерживать два отдельных метода доступа к этим данным:
  
  
  
  • Переменные среды, обозначенные в пространстве имен FIG_VARIABLE_X
  
  
  • Пример: если вы ищете HOSTNAME в fig.yml, переменная среды должна храниться как FIG_VARIABLE_HOSTNAME
  
  
  • Отдельный файл YAML
  
  
  • По умолчанию мы будем искать в файле variables.yml корневой папки.
  
  
  • Пользователь может указать расположение этого файла в качестве переменной среды в FIG_VARIABLES_YML.
  
  
  • Пользователь также может передать этот файл через командную строку для любой команды как --fig-variables = / foo / bar / variables.yml.
  
  
• Создайте класс с именем FigConfig, который обеспечивает полный доступ к данным конфигурации из fig.yml.
  
  
  
  • Этот класс конфигурации должен иметь все API, доступные из возвращаемого значения yaml.safe_load, чтобы минимизировать изменения во взаимодействиях во всей библиотеке.
  
  
  • Этот класс конфигурации должен включать хуки для интерполяции значений сначала из templates.yaml, перезаписываемых значениями, заданными как переменные среды.
  
  
• Замените все существующие вызовы yaml.safe_load созданием нового экземпляра FigConfig с указанным именем файла.

Если все будут довольны этим предложением, я буду счастлив поработать над ним и сделать PR.

+1
Не могу дождаться!

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

Как будут представлены значения в этом yaml-файле? Было бы лучше использовать файл с одним key=value на строку? Так как это скорее «приятно иметь», я бы, наверное, подождал.

FigConfig

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

Другой связанный запрос - предоставить возможность предоставлять значения по умолчанию для вещей. Примерно так: ${HOSTNAME:localhost} используется в других файлах (по крайней мере, tox.ini, возможно, в других), чтобы указать значения по умолчанию.

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

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

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

7 января 2015 г., среда, 21:20:47 Даниэль Нефин [email protected]
написал:

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

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

FigConfig

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

Другой связанный запрос - предоставить значения по умолчанию для
вещи. Примерно так: $ { HOSTNAME: localhost } используется в других файлах
(по крайней мере, tox.ini, возможно, другие), чтобы указать значения по умолчанию.

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

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

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

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

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

Так что, возможно, предложение должно быть примерно таким:

• Добавить доступ к os.environ () для всех полей fig.yml
• Представьте класс FigConfig, отвечающий за обертку доступа к данным из fig.yml
• Класс FigConfig должен иметь перехватчики, которые могут получать доступ к данным из среды (при условии формата $ {}). Значение по умолчанию должно быть поставлено с точкой с запятой для предоставленной строки.

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

Я счастлив попытаться выполнить этот кусок работы за один или два пиара. Я склоняюсь к тому, чтобы сделать это в рамках единого PR, поскольку мы действительно хотели бы убрать os.environ () из всех открытых в настоящее время полей, и чтобы этот доступ происходил непосредственно в классе Config.

+1

+1

+1

+1, особенно точка @relwell о наличии отдельного файла YAML

+1

+1

Особенно такой:

# fig.yml
app:
  image: django:${DJANGO_VERSION:latest}
  environment:
    - SECRET_KEY=${SECRET_KEY:ONLYFORTESTING}

+1

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

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

В остальном попробуйте envsubst, который может заменять ссылки на переменные, используя синтаксис $var или ${var}

envsubst < "fig.tpl" > "fig.yml"
fig up

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

Я согласен с @thomasdavis .

@NoumanSaleem дает хороший совет, но поскольку envsubst недоступен в OS X без установки gettext из, например, homebrew, что, по-видимому, может вызвать некоторые проблемы, я собрал эквивалент Go: https://github.com/ilkka/substenv

Согласен с @thomasdavis

+1 для ENV передано во время выполнения

Я ненавижу +1, но это наиболее востребованная и обсуждаемая функция здесь.

Можем ли мы подвести итоги дискуссии здесь?

1. Какие переменные уже поддерживаются в RC2 и где это задокументировано?
2. Каков текущий статус?
3. Принимается ли этот запрос функции и когда можно ожидать решения?

Согласен с @ Vad1mo , +1

Это простой скрипт, который можно использовать перед docker-compose.

https://gist.github.com/Vad1mo/9ab63f28239515d4dafd

вот один лайнер для установки:
sudo curl https://gist.githubusercontent.com/Vad1mo/9ab63f28239515d4dafd/raw/aa54b91f4c3671097789a54a9f42ba679b89dbaf/replace-var -o /usr/local/bin/replace-var && sudo chmod 755 /usr/local/bin/replace-var

+1

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

определенно +1
Каков текущий статус? Над этой функцией работают?

+1

+1

+1

+1, мой вариант использования для этого - иметь 3 среды (несколько машин), которые в основном дублируются, но мне нужен другой порт для каждой. Вместо того, чтобы поддерживать другой файл fig, я предпочел бы иметь файл .sh, я могу добавить параметр, например 2000, и это развернет среду, которая использует порты, такие как 2001, 2002, 2003. Я могу выполнить логику добавления в сценарии bash, но мне нужно кое-что перейти к рис.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

позвольте мне подвести итог достигнутому прогрессу:

добавление комментариев «+1» и непослушных картинок, конечно, не помогает в дебатах.

Я хотел бы иметь право удалять их. :-П

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

+1

разве это невозможно с помощью env_file ?
например:

echo 'VAR=test' > env && docker-compose up -d

Возможно, нет, потому что «Переменные среды, указанные в среде, переопределяют эти значения.», Что я нахожу немного странным, потому что env_file предназначен для разрешения настраиваемых (для каждой установки) параметров ИМХО

Файл Compose.yml не определяет только переменные env. Так что это не сработает
для динамической установки имени хоста или выставленного номера порта и т. д.

В среду, 15 апреля 2015 г., 9:39 Флориан Кляйн [email protected]
написал:

разве это уже невозможно, используя env_file
https://docs.docker.com/compose/yml/#env_file ?
например:

echo 'VAR = test'> env && docker-compose up -d

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

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

+1

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

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

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

+1

+1

: +1:

Да ладно, даже в Symfony 2 есть поддержка переменных в YML!

Или нам нужно что-то поверх docker-compose.

+1

+1

+1

Каждый раз, когда вы пишете +1 , 73 человека получают бесполезные письма. В этом нет никакого смысла. Готов поспорить, специалисты по обслуживанию уже поняли вашу точку зрения.

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

к вашему сведению, вчера я запросил автоматическую цензуру за спам- контент на github.

если вы хотите что-то реализовать, сделайте спонсорское предложение!

ХОРОШО! Искренняя благодарность ребятам +1, действительно полезно знать, сколько людей хотят эту функцию. Я создал новую проблему на https://github.com/docker/compose/issues/1377, чтобы отслеживать ее. Отправляйтесь туда со своими мыслями.

Если кто-то не знает, вы можете отказаться от подписки на уведомления с помощью кнопки «Отписаться» справа. /мета

Я хотел поделиться довольно простым временным решением, которое у меня было для расширения переменных:

#!/bin/bash
apply_shell_expansion() {
    declare file="$1"
    declare data=$(< "$file")
    declare delimiter="__apply_shell_expansion_delimiter__"
    declare command="cat <<$delimiter"$'\n'"$data"$'\n'"$delimiter"
    eval "$command"
}
#in case you want to store the variables in a local file
source ./local.env
if ! [ -n "$DOCKER_DATA_PATH" ] ; then
    echo "DOCKER_DATA_PATH not set, using default value"
fi
DOCKER_DATA_PATH=${DOCKER_DATA_PATH:=//c/projects/dockerdata}

apply_shell_expansion docker-compose.tpl.yml > docker-compose.yml

Затем ваш docker-compose.tpl.yml может быть зафиксирован, каждый человек может иметь local.env, полученный из скрипта, и он просто использует собственное расширение переменной bash, быстро и легко.

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

Изменить: на самом деле этот скрипт кажется только bash, поскольку boot2docker имеет только sh, sh будет:

#!/bin/sh
apply_shell_expansion() {
    local file="$1"
    local data=$(cat "$file")
    local delimiter="__apply_shell_expansion_delimiter__"
    local command="cat <<$delimiter"$'\n'"$data"$'\n'"$delimiter"$'\n'""
    eval "$command"
}
#in case you want to store the variables in a local file
source ./local.env
if ! [ -n "$DOCKER_DATA_PATH" ] ; then
    echo "DOCKER_DATA_PATH not set, using default value"
fi
DOCKER_DATA_PATH=${DOCKER_DATA_PATH:=//c/projects/dockerdata}

apply_shell_expansion docker-compose.tpl.yml > docker-compose.yml

Для небольшого количества переменных («токенов») я использую простой сценарий оболочки вместе с шаблонной версией моего файла YAML. Вот реальный пример:

файлы:

docker-compose-template.yml
docker-compose.yml
compose_replace.sh

бежать:

sh compose_replace.sh

сценарий:

#!/bin/sh

# variables
base_url_token="{{ base_url }}" # find all these...
base_url="api.foo.com" # replace with url of public rest api
host_ip_token="{{ host_ip }}" # find all these...
host_ip=$(docker-machine ip $(docker-machine active)) # replace with ip of host running NGINX

# output
echo ${base_url_token} = ${base_url}
echo ${host_ip_token} = ${host_ip}

# find and replace
sed -e "s/${base_url_token}/${base_url}/g" \
    -e "s/${host_ip_token}/${host_ip}/g" \
    < docker-compose-template.yml \
    > docker-compose.yml

это в docker-compose-template.yml :

  extra_hosts:
   - "{{ base_url }}:{{ host_ip }}"

преобразуется в docker-compose.yml :

  extra_hosts:
   - "api.acme.com:192.168.99.100"

Github необходимо реализовать функцию поддержки / важности проблем.

@apobbati +1

(Интерполяция переменных среды была реализована и объединена в https://github.com/docker/compose/pull/1765, если это то, к чему вы пришли.)

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

+1