Есть ряд микросервисов, размещены в облаке, с использованием своего кластера Kubernetos. Пока конфигурация для них прописывается вручную. Планируем перейти на сервисную сетку. Все сервисы на C#, размещены на Linux.
Есть нерешенный вопрос, где хранить конфигурацию. Есть идея использовать некоторый центральный сервис конфигурации. В файлах конфигурации сервисов достаточно будет хранить адрес сервиса конфигурации. Тогда, сервисы при старте будут обращаться к сервису конфигурации, читать свою конфигурации.
Что в такой схеме не очень хорошо – если сервис конфигурации лежит, то сервисы не смогут стартовать. Еще, непонятно как отслеживать изменения конфигурации.
Есть ли какие-нибудь хорошие практики для управления конфигурацией?
Какие-то существующие подходящие open source решения?
Здравствуйте, andsm, Вы писали:
A>Есть ряд микросервисов, размещены в облаке, с использованием своего кластера Kubernetos. Пока конфигурация для них прописывается вручную. Планируем перейти на сервисную сетку. Все сервисы на C#, размещены на Linux. A>Есть нерешенный вопрос, где хранить конфигурацию. Есть идея использовать некоторый центральный сервис конфигурации. В файлах конфигурации сервисов достаточно будет хранить адрес сервиса конфигурации. Тогда, сервисы при старте будут обращаться к сервису конфигурации, читать свою конфигурации. A>Что в такой схеме не очень хорошо – если сервис конфигурации лежит, то сервисы не смогут стартовать. Еще, непонятно как отслеживать изменения конфигурации. A>Есть ли какие-нибудь хорошие практики для управления конфигурацией? A>Какие-то существующие подходящие open source решения?
Какая конфигурация имеется ввиду?
Если конфигурация самих сервисов, то кубере, передавать через ENV в докер.
Если настройки приложения, то в базе (отдельном сеттингс-сервисе).
Здравствуйте, andsm, Вы писали:
A>Что в такой схеме не очень хорошо – если сервис конфигурации лежит, то сервисы не смогут стартовать. Еще, непонятно как отслеживать изменения конфигурации.
Ну, если у вас кубер, то если сервис лежит — то его тут же поднимут.
A>Есть ли какие-нибудь хорошие практики для управления конфигурацией?
Там много нетривиальных вызовов:
1) Согласование конфигурации между всеми сервисами
2) Согласованное изменение конфигурации между сервисами (чтобы не было, что разные сервисы используют разные версии настроек)
3) Права и процессы изменения конфигов (кто что может сделать)
Проще действительно сделать один общий сервис, который отдает конфигурацию (с версиями, датой начала действия и т.п.) для всех интересующихся.
Ну и топик в каком-нибудь MQ о том, что такой-то кусок конфигурации поменялся, пусть все подпишутся.
A>Какие-то существующие подходящие open source решения?
Можно смотреть на Consul, Zookeeper и прочие решения под эту задачу. Но что-то придется и самим доделывать, конечно.
AB>Полагаю, что под хранением конфигурации подразумевается service discovery. В общем-то много их разных, из наиболее распространенных наверное consul.
Нет, это мы решаем через использование сервисной сетки.
G>Какая конфигурация имеется ввиду? G>Если конфигурация самих сервисов, то кубере, передавать через ENV в докер. G>Если настройки приложения, то в базе (отдельном сеттингс-сервисе).
Задачу найти где что находится, мы планируем решить при помощи сервисной сетки. Система уже работает, но пока много чего еще не сделали, и сервисную сетку в том числе еще не внедрили.
Отдельный сервис конфигурации — на самом деле уже есть, используем для этого consul.
Но это же только часть решения. Полно других вопросов, связанных с конфигурацией.
Пример. Какая-то команда добавила новый параметр в существующем сервисе. Настроен continuous delivery.
И тут возникают сложности. Если отдельный сервис конфигурации, как туда попадет значение? Возможное решение вполне понятное, через описание изменений и ручным применением. У нас этих сервисов планируется несколько десятков, и несколько сотен инстансов работающих сервисов. Хочется минимизировать ручные операции, упростить сопровождение системы.
Здравствуйте, andsm, Вы писали:
A>Есть ли какие-нибудь хорошие практики для управления конфигурацией? A>Какие-то существующие подходящие open source решения?
Я бы сформулировал практики так:
— настройки делятся на секретные и несекретные, секретные должны находиться в отдельном специализированном хранилище
— все изменения настроек должны версионироваться и иметь автора
— настройки должны применяться к хостам явно и осознанно
И по реализации:
— несекретные настройки храним в гите
— секретные настройки храним или в отдельном гите, или в защищенном облачном хранилище
— настройки применяются при деплое приложения, не при старте, т.к. рестарт — слабоконтролируемое событие и может случаться спонтанно
— для эстетов — настройки компилируются в бандл с версией и имеют свой релизный цикл, включая тестирование.
Здравствуйте, andsm, Вы писали:
A>Есть ряд микросервисов, размещены в облаке, с использованием своего кластера Kubernetos. Пока конфигурация для них прописывается вручную. Планируем перейти на сервисную сетку. Все сервисы на C#, размещены на Linux. A>Есть нерешенный вопрос, где хранить конфигурацию. Есть идея использовать некоторый центральный сервис конфигурации. В файлах конфигурации сервисов достаточно будет хранить адрес сервиса конфигурации. Тогда, сервисы при старте будут обращаться к сервису конфигурации, читать свою конфигурации. A>Что в такой схеме не очень хорошо – если сервис конфигурации лежит, то сервисы не смогут стартовать. Еще, непонятно как отслеживать изменения конфигурации. A>Есть ли какие-нибудь хорошие практики для управления конфигурацией? A>Какие-то существующие подходящие open source решения?
Тут коллеги уже сказали про Consul. Добавлю к нему еще один хешикорповский продукт для хранения секретов — Vault.
На самом деле конфигурировать в дотнете крайне просто, т.к. из коробки сервисы умеют читать конфиги прямо из переменных окружения: — см. раздел с Enviroment Variables
Ну и плюс есть сам кубик. ConfigMap тот же... все зависит от задачи, думаю упомятуе средства подскажут как действовать в вашем случае.
Здравствуйте, andsm, Вы писали:
A>Есть нерешенный вопрос, где хранить конфигурацию.
Если конфигурация не меняется после деплоймента очередной версии — в файлах в образе сервисов.
Если конфигурация относительно несложная и не предполагается прод без кубера — ConfigMap.
Если конфигурация довольно сложная и/или какие то особые требования к инфраструктуре — Consul
Если еще и безопасники наседают — тогда Vault (в качестве бека тот же Consul или Postgre).
Если облако это Ажур и только он — AppConfiguration/KeyVault.
Еще можешь покурить steeltoe, это идеология из жабного мира.
A>Что в такой схеме не очень хорошо – если сервис конфигурации лежит, то сервисы не смогут стартовать.
Так его тоже надо либо с fault tolerance разворачивать, либо использовать SaaS, где за SLA голова болит у других людей.
Здравствуйте, Anton Batenev, Вы писали:
AB>Полагаю, что под хранением конфигурации подразумевается service discovery.
С чего бы? Это разные вещи. И если уж у них Кубер, то там оно есть искаропки и его вполне можно использовать, если нет каких то фич которые он не умеет типа прописывания туда сервисов вне кластера.
Здравствуйте, scf, Вы писали:
scf>- настройки делятся на секретные и несекретные, секретные должны находиться в отдельном специализированном хранилище
Необязательно, если они шифруются.
scf>- настройки применяются при деплое приложения, не при старте, т.к. рестарт — слабоконтролируемое событие и может случаться спонтанно
И тут приходят продакты и просят сделать применение настроек не просто после рестарта, а и вообще без рестарта подов. А ты им — ну вот идите в гит, передеплоивайте сервис, рестартуйте все его поды ... Догадываешься что они тебе скажут?
scf>- для эстетов — настройки компилируются в бандл с версией и имеют свой релизный цикл, включая тестирование.
Истинно так. Причем это тестирование должно осуществляться в соответствии с матрицей совместимости кода приложения. Скажем, приложение v1.2 может работать толко с v1.2.1-v1.2.5 конфигурации. Все остальные комбинации не поддерживаются.
Если у разработчиков есть контроль и за кодом приложения, и за конфигурацией, тогда зачастую проще и вовсе не выделять отдельно "код" и "конфигурацию", а гнать все через ту же самую систему CI/CD. Стало быть, хранить конфигурацию прямо там же, в том же репо, что и исходный код. Ибо это он и есть.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Необязательно, если они шифруются.
У нас CTO, которого я бесконечно уважаю, запрещал использовать шифрованные настройки. Их проблема в том, что одна ошибка в управлении ключом шифрования настроек — и все секреты становятся доступными всем.
НС>И тут приходят продакты и просят сделать применение настроек не просто после рестарта, а и вообще без рестарта подов. А ты им — ну вот идите в гит, передеплоивайте сервис, рестартуйте все его поды ... Догадываешься что они тебе скажут?
Догадываюсь, но это же "другие" настройки)
Я бы поделил настройки на три типа
а) без которых приложение просто не работает (пароли те же)
б) которыми приложение можно сломать, ну или починить (xmx и прочий тюнинг)
в) которые управляют бизнес-функциональностью, а не доступностью приложения.
Здравствуйте, scf, Вы писали:
scf>У нас CTO, которого я бесконечно уважаю, запрещал использовать шифрованные настройки. Их проблема в том, что одна ошибка в управлении ключом шифрования настроек — и все секреты становятся доступными всем.
Я это комментировать даже не буду.
scf>Я бы поделил настройки на три типа scf>Конечно, с ними нужно обращаться по-разному.
Ты, вместо внесения ясности, все окончательно запутал.
