Задача выдачи файлов конфигураций и файлов секретов по Интернету — а есть ли готовые решения?
Администрирую десятки серверов с помощью Ansible, деплою несколько образов Docker с помощью него (пусть Ansible для этого не предназначен).
Возникает вопрос: каждому docker-compose.yml требуется .env-файл и иногда ещё парочка файлов конфигов любого вида. А ложить/класть десятки таких файликов с конфигами в репу с Ansible как-то зазорно, особенно если там секреты есть.
Я глянул решения - HashiCorp Vault, Azure Key Vault, Doppler, Dotenv Vault - все они key-value без возможности скачать свой .env-файл. Dotenv Vault подошел бы, но он не работает с Docker, только с бекендом внутри контейнера. А это неприемлемо, бекенды внутри контейнеров я не контролирую вообще, image не мои.
Так что появилась задача: docker-compose файл запускается (или его запускает Ansible) и перед запуском самостоятельно качает нужный ему .env-файл с какого-то моего бекенда (либо Ansible перед запуском это делает). Бекенд проверяет, что это точно IP моего сервера (без MITM, не фейк, вот фото паспорта и ЭЦП) и выдаёт ему контент этого файла с секретами. Файл качается, ложится рядом с docker-compose, и весь стек начинает запускаться.
Мой будущий бекенд, который я напишу, будет делать так:
1. Юзер заливает туда нужные файлики, пишет текстовый идентификатор сервиса и хосты, для которых этот файл(ы) предназначается. Настраивает единый ключ доступа в виде строки для своего аккаунта;
2. Сервис, который стартует в docker-compose, обращается к этому URL'у и сообщает свой ключ и нужный сервис, получает список файлов и качает их. Не нужно сообщать свой IP-адрес, мой бекенд проверит его и сопоставит сам.
Конфигурация сервера и деплой программных решений - разные вещи. Меня учили, что Ansible предназначен для первого, но для второго лучше воспользоваться методикой ДевОпсь и начать носить фурри-костюм.
Иннокентий Иванов, да учить могут как угодно. пользоваться надо как считаете нужным и как удобно...)
у нас к примеру спокойно деплоится докер через ансибл без всяких проблем.
насчет env - хранится в гитхабе закрытом, добавляется сервер туда, с гита идет деплой и расшифровывается secrets, но Вам это наверно не подойдет.
Зачем хранить прям конфиги? Обычно передают параметры через env или через vault/consul/итд, а для приложений, которые хотят именно конфиг, он генерится по шаблону с заполнением в нём секретов.
shurshur, я понял вашу (общепринятую) методику, но в итоге-то кто прокидывает параметры в docker-контейнеры? В моём случае это Ansible. Откуда он берет параметры для конфигов и секреты? Правильно, из .env-файла. Или откуда? Моего понимания хватает только на такой метод деплоя...
Иннокентий Иванов, например, из vars/host_vars/group_vars. Их там даже можно с помощью ansible-vault пошифровать (при запуске плейбука надо будет использовать --ask-vault-pass и вводить пароль).
Прогоняешь плейбук - он на удалённых хостах всё создаёт/настраивает/делает конфиги итд.
Более сложные вещи делают, если надо не хранить на удалённых хостах пароли в явном виде. Тогда в зависимости от нужного сценария защиты могут быть разные решения. Например, как одно из простых решений, можно запускать приложение с помощью ansible, который сходит на нужный хост, зная токен от hashicorp vault, получит секреты, запустит приложение и уйдёт, нигде токен не сохранив. В случае компроментации хоста на нём паролей нет и токен тоже отсутствует. Если у взломщика не будет root и 0-day эксплойта - он даже память не сдампит.
Я глянул решения - HashiCorp Vault, Azure Key Vault, Doppler, Dotenv Vault - все они key-value без возможности скачать свой .env-файл. Dotenv Vault подошел бы, но он не работает с Docker, только с бекендом внутри контейнера. А это неприемлемо, бекенды внутри контейнеров я не контролирую вообще, image не мои.
А в чем проблема положить конфигурационный файл в value?
Так многие делают. Просто клади их как base64 строку.
Кстати, как вариант... надо подумать... спасибо за наводку! Если я правильно продумаю имя ключа, например:
<IP-адрес сервера, для которого предназначается файл>___<имя сервиса>___<имя файла>___<структура и место в папке, где должен файл лежать относительно рабочего каталога>
как-то сложно.
У тебя просто айпишники сервисов? Это не лучшее решение..
Сервис же запущен не просто так, это продакшен или тест, или дев. То есть имя енвайрнмента.
Во-вторых зачем имя сервиса и имя файла? У сервиса несколько конфигов?
Структура и место в папке - для контейнеров как бы хорошо, если все стандартизировано..
В итоге может быть типа
OpenFeature(это не решение, а попытка сделать стандартное API для таких сервисов как в списке выше, пока к сожалению не очень популярно)
Гуглите "remote configuration" и "feature flags", обычно это идёт комплектом. Может применяться как к клиентским приложениям (десктоп, мобилка), так и к приложениям на стороне сервера (то, что как раз вам нужно).
Средний
Простой
