Почему там несколько ключей, развязанных в энергии?

Я согласен с "Двенадцатью факторами", что трюк с переменной окружения - это путь, по которому нужно идти. Однако существуют некоторые важные предостережения, которые не разъясняются в руководстве по "Двенадцати факторам", а также некоторые практические соображения и методы, которые необходимо использовать для достижения этой цели.

Во-первых, переменные окружения являются переменными (не постоянными). Все данные теряются при перезагрузке. Это означает, что если где-то сохранилась конфигурация не, то в случае перезагрузки сервера она будет невосстановима, если только не находится в памяти в /dev/brain0 sys-admin (не азартная игра, которую я бы сделал со 128-битными ключами). Если это личный ключ(и) сервера, то у вас в лучшем случае серьезная, а в худшем - катастрофическая проблема (вашему ЦС может понадобиться переиздание ключей). Это является хорошим аргументом в пользу того, что конфигурация должна быть где-то записана, и я не думаю, что многие люди будут спорить с этим. Однако, где/как его хранить, вот что важно.

Приложение Двенадцать Факторов решает эту проблему, хотя и не в простой форме. "Лакмусовая бумажка на предмет того, правильно ли приложение конфигурируется из кода, заключается в том, может ли кодовая база быть в любой момент сделана с открытым исходным кодом, без компромиссов в отношении каких-либо полномочий". Так что мы знаем, что мы должны записать его где-то , и что мы не можем поместить конфигурацию в кодовую базу. "Другой подход к конфигурированию - использование конфигурационных файлов, которые не проверяются в контроле за ревизиями". Это то, что я бы сделал.

В приложении "Двенадцать Факторов" сказано: "Легко по ошибке проверить в конфигурационном файле в repo". Чтобы противостоять этому, производственная конфигурация (например, приватные ключи) должна отличаться от конфигураций разработки и тестирования. Они также должны быть строго контролируемыми. Некоторые системы управления версиями, такие как git, имеют чёрные списки (например, файл .gitignore), которые препятствуют проверке в определённых файлах. Их также следует использовать. "Существует тенденция разброса конфигурационных файлов в разных местах и разных форматах, что затрудняет просмотр и управление всем конфигурационным файлом в одном месте. Кроме того, эти форматы, как правило, специфичны для языка или фреймворка." Это противодействует простому определению "переменных окружения" в конфигурационном файле. Затем они могут быть загружены сервером в окружение при запуске.

Что бы я сделал:

1. Хранить конфигурационную информацию производственного сервера (например, приватный ключ(и) сервера) в отдельном repo, отличном и отличном от основного repo
2. Очень хорошо защищать производственный конфигурационный файл(ы). Доступ к нему нужен лишь немногим, не каждому разработчику в команде. Например, QA/DevOps/Sys-admins/etc. Обращайтесь с этим файлом как с ключами к серверу, потому что они, вероятно, находятся в нём. Среды разработки и тестирования должны иметь различные учетные данные и ключи, нежели в производственном окружении. В этом случае они могут храниться более свободно
3. Пусть сервер загрузит информацию из конфигурационного файла в переменные окружения в реальном времени
4. Пусть приложение загрузит нужную ему информацию из переменных окружения во время выполнения