Доступ к свойствам эластичного материала Beanstalk в Docker

Итак, я искал пример того, как я могу указать переменные среды для своего контейнера Docker из веб-интерфейса AWS EB. Обычно в EB вы можете добавлять свойства среды, доступные во время выполнения. Я использовал их для своего предыдущего развертывания до того, как переключился на Docker, но похоже, что Docker имеет несколько разных правил в отношении того, как обрабатываются свойства среды, верно ли это? Согласно этой статье [1], ТОЛЬКО учетные данные AWS и PARAM1-PARAM5 будут присутствовать в переменных среды, но никаких пользовательских свойств не будет присутствовать. Это то, что мне кажется, особенно учитывая, что контейнеры, которые поддерживают свойства настраиваемой среды, говорят это явно, как показано на рисунке Python [2]. Кто-нибудь имеет опыт работы с этой программной комбинацией? Все, что мне нужно указать, - это одна переменная среды, которая сообщает мне, работает ли приложение в режиме "постановки" или "производства", тогда все настройки, связанные с моей средой, настраиваются самим приложением.

[1] http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options.html#command-options-docker

[2] http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options.html#command-options-python

Ответ 1

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

Ответ 2

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

Часть контейнеров Docker в документах говорит: "Нет настроек конфигурации DOCKER-SPECIFIC, предоставляемых Elastic Beanstalk"..., который не работает 't обязательно означает, что никакие переменные среды не передаются в контейнер Docker.

Например, для контейнера Ruby, которые всегда передаются переменными Ruby, которые всегда передаются... RAILS_SKIP_MIGRATIONS, RAILS_SKIP_ASSET_COMPILATION, BUNDLE_WITHOUT, RACK_ENV, RAILS_ENV. И так далее. Предположим, что для контейнера Ruby вы используете приложение Ruby, поэтому устанавливаете некоторые разумные значения по умолчанию, чтобы убедиться, что они всегда доступны.

С другой стороны, для контейнера Docker он кажется открытым. Вы указываете любые переменные, которые вы хотите... они не делают никаких предположений о том, что вы используете, Rails (Ruby), Django (Python) и т.д.... потому что это может быть что угодно. Они не знают перед собой, что вы хотите запустить, и это затрудняет установление разумных значений по умолчанию.