☰

Получение учетных данных для каждого экземпляра в экземплярах Docker

tag-icon • tag-icon docker
Получение учетных данных для каждого экземпляра в экземплярах Docker

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

По сути, каждый экземпляр должен иметь уникальное имя и либо пароль/сертификат SSL. Затем он подключается обратно домой при запуске и начинает обработку задач.

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

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

решение1

Вы можете добавить том Docker и указать его, на основе контейнера, на папку на хосте, содержащую нужный вам сертификат SSL. Вы даже можете создать том "из одного файла".

docker run -d \
    --name=worker0 \
    -v "/etc/ssl/worker0.crt":/etc/ssl/private/container.crt \
    -v "/etc/ssl/worker0.key":/etc/ssl/private/container.key \
    myworkerimage

docker run -d \
    --name=worker1 \
    -v "/etc/ssl/worker1.crt":/etc/ssl/private/container.crt \
    -v "/etc/ssl/worker1.key":/etc/ssl/private/container.key \
    myworkerimage

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

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

Связанный контент