12факторный подход к конфигурации с Docker

Question

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

Единственный не зависящий от языка метод, который я видел, - это загрязнение команды docker run переменными -e. Наиболее приемлемое решение, которое я видел, - это использование комбинации cat и sed для генерации параметров CLI с использованием файла.env: https://twitter.com/DataKyle/status/422843345120296960

В настоящее время мы используем Vagrant для dev, поставщика CI/CD для тестирования и развертывания, а также AWS Elastic Beanstalk в качестве PAAS для подготовки и производства. Наше приложение имеет более 100 настраиваемых параметров, большинство из которых настроены на значения по умолчанию, но для каждой среды все еще необходимо настроить около 10-20 из них. Просто кажется слишком хакерским запускать докер с таким огромным списком переменных командной строки.

Кроме того, он не позволяет вам получать переменные с хоста докера (например, предварительно установленные учетные данные Redis или Postgres провайдера CI) без дальнейшего взлома.

Есть ли решение для этого я не нашел? Или это недостающий кусок для Докера? Или это как-то философски против философии Докера?

Answer 1

Docker 0.10.0 и новее (8 апреля 2014 г.) принимает docker run --env-file <filename>, что позволяет кормить рабочую среду докера .env файлы

Более того, вы можете позволить докерам взаимодействовать дальше: --volumes-from может смонтировать все тома из указанного контейнера, и --link позволяет контейнеру знать детали открытых портов упомянутого контейнера.

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

С чего начать с контейнера. Обычно я рекомендую запустить сценарий оболочки, который устанавливает переменные среды по умолчанию (в соответствии с : ${ENV:=default_value}), экспортирует их, затем exec один исполняемый файл. Этот исполняемый файл может быть желаемым приложением на переднем плане или заменой инициализации, например runit или же supervisord,

Я бы не рекомендовал бегать sshd внутри вашего докера, если он не является частью системы (например, контейнер для gitlab должен содержать sshd, поскольку он обеспечивает доступ к git repo через ssh). В целях обслуживания или отладки я рекомендую использовать nsenter вместо.