1. Обзор
Часто бывает полезно отделить наши службы от их конфигурации. Для двенадцатифакторного приложения мы должны хранить конфигурацию в среде .
Конечно, это означает, что нам понадобится способ внедрить конфигурацию в наш сервис.
В этом руководстве мы добьемся этого, передав переменные среды в контейнер Docker .
2. Использование –env , -e
В этом руководстве мы будем использовать небольшой (5 МБ) образ Linux под названием Alpine. Начнем с локального извлечения образа:
docker pull alpine:3
Когда мы запускаем наш контейнер Docker, мы можем передавать переменные среды в виде пар ключ-значение непосредственно в командную строку, используя параметр –env (или его короткую форму -e ).
Например, давайте выполним следующую команду:
$ docker run --env VARIABLE1=foobar alpine:3 env
Проще говоря, мы отражаем переменные среды, которые мы установили, обратно в консоль:
VARIABLE1=foobar
Как видно, контейнер Docker правильно интерпретирует переменную VARIABLE1 .
Также мы можем опустить значение в командной строке, если переменная уже существует в локальной среде .
Например, давайте определим локальную переменную среды:
$ export VARIABLE2=foobar2
Затем давайте укажем переменную окружения без ее значения:
docker run --env VARIABLE2 alpine:3 env
И мы видим, что Docker все еще получает значение, на этот раз из окружающей среды:
VARIABLE2=foobar2
3. Использование –env-файла
Приведенное выше решение подходит, когда количество переменных невелико. Однако, как только у нас будет больше, чем несколько переменных, это может быстро стать громоздким и подверженным ошибкам.
Альтернативное решение — использовать текстовый файл для хранения наших переменных , используя стандартный формат ключ=значение .
Давайте определим несколько переменных в файле, который мы назовем my-env.txt :
$ echo VARIABLE1=foobar1 > my-env.txt
$ echo VARIABLE2=foobar2 >> my-env.txt
$ echo VARIABLE3=foobar3 >> my-env.txt
Теперь давайте вставим этот файл в наш контейнер Docker:
$ docker run --env-file my-env.txt alpine:3 env
Наконец, давайте посмотрим на вывод:
VARIABLE1=foobar1
VARIABLE2=foobar2
VARIABLE3=foobar3
4. Использование Docker Compose
Docker Compose также предоставляет средства для определения переменных среды. Для тех, кто интересуется этой конкретной темой, ознакомьтесь с нашим руководством по Docker Compose для получения более подробной информации.
5. Остерегайтесь конфиденциальных ценностей
Чаще всего одной из переменных будет пароль к базе данных или внешней службе. Мы должны быть осторожны с тем, как мы внедряем эти переменные в контейнер Docker.
Передача этих значений непосредственно через командную строку, вероятно, наименее безопасна, так как существует больший риск утечки конфиденциальных значений куда-то, чего мы не ожидаем, например, в нашей системе управления исходным кодом или в списке процессов ОС.
Лучше определить конфиденциальные значения в локальной среде или в файле, поскольку и то, и другое можно защитить от несанкционированного доступа.
Однако важно понимать, что любой пользователь, имеющий доступ к среде выполнения Docker, может проверить работающий контейнер и обнаружить секретные значения .
Давайте проверим работающий контейнер:
docker inspect 6b6b033a3240
Вывод показывает переменные среды:
"Config": {
// ...
"Env": [
"VARIABLE1=foobar1",
"VARIABLE2=foobar2",
"VARIABLE3=foobar3",
// ...
]
}
В тех ситуациях, когда безопасность вызывает беспокойство, важно упомянуть, что Docker предлагает механизм под названием Docker Secrets . Контейнерные сервисы, такие как Kubernetes , AWS или Azure, также предоставляют аналогичные функции.
6. Заключение
В этом кратком руководстве мы рассмотрели несколько различных вариантов внедрения переменных среды в контейнер Docker.
Хотя каждый подход работает хорошо, наш выбор в конечном итоге будет зависеть от различных параметров, таких как безопасность и ремонтопригодность.