Свойства версий с Spring Cloud Config

Question

Возможно, что-то здесь не хватает, но что такое хорошее решение для управления версиями?

Например, в сине-зеленом сценарии развертывания с изменениями свойств (для старой версии приложения используется старое значение, для новой версии требуется новое значение), как вы гарантируете, что обе версии вашего приложения могут успешно сосуществовать (учитывая возможные перезагрузки и откаты)?

Один из вариантов - создать новые имена свойств для свойств, которым нужны новые значения. Это, конечно, не является хорошим вариантом, поскольку нам нужно отслеживать все использование этого свойства в базе кода и соответственно обновлять его ссылку. Это также не приятно с концептуальной точки зрения.

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

Решение для аду ветви должно было иметь разделенное конфигурационное репо для каждого приложения. Но я считаю, что это в некотором смысле побеждает цель сервера конфигурации, поскольку она добавляет дополнительные служебные данные.

Любые другие подходы? Environment ресурсы

Answer 1

Spring Cloud Config в параметризованные трех переменных:

1. {application} карты в spring.application.name на стороне клиента
2. {profile} карты в spring.active.profiles на клиенте
3. {label} который является маркировка на стороне сервера функция a версия файлов конфигурации.

Поскольку в случае синезеленых развертывания, вы используете один и тот же приложение в одном профиле, лучшим вариантом является использование версированных конфигурационных файлов с помощью Git Теги.

Основная идея - создать теги для различных версий файлов конфигурации и сообщить вашему приложению использовать конфигурации, связанные с определенным тегом, используя spring.cloud.config.label в вашем bootstrap.properties.

Например, вы можете пометить два различных фиксаций с v1.0 и v2.0:

И использовать spring.cloud.config.label=v1.0 для старого экземпляра и spring.cloud.config.label=v2.0 для нового экземпляра.

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

Чтобы избежать этой проблемы, я предлагаю сохранить только общие и перекрестные свойства приложения в конфигурационных файлах application-{profile}.properties. Лучший подход заключается в том, что для каждого приложения есть свой собственный файл конфигурации, например.recommender.properties для службы поддержки и search.properties для поиска услуг. Затем вы можете использовать свойства профиля и версии для каждого из них, указав соответствующий spring.application.name. Таким образом, вы можете достичь до определенного уровня Одиночный принцип ответственности в конфигурационных файлах.