Pull to refresh

Comments 2

  • Часть конфигурации становится известна только на этапе деплоймента, например, если для ноды поднимается новый инстанс в AWS с новым IP, или если пароли хранятся централизованно и доступны только деплоеру. Как это решить со статической конфигурацией?


  • если статическая конфигурация компилируется в отдельный jar, как определить, совместим ли конкретный jar конфигурации с конкретной версией приложения?


  • страдает повторное использование? Хорошо написанный микросервис — это "вещь в себе", его можно использовать через годы после последней компиляции и не заглядывая в исходники. Со статической конфигурацией придется перекомпилировать приложение, что может оказаться проблемой для старого кода.


  1. По поводу разрешения IP — есть в статье. Удобный вариант — прописать новый IP в /etc/hosts для предопределённого имени.
    По поводу паролей — (1) разбить конфигурацию на 2 части — общая и секретная; (2) предусмотреть макрос или скрипт сборки, который будет забирать пароли из хранилища и запекать в конфигурацию; (3) по-старинке, предусмотреть runtime-загрузку паролей при старте приложения.
  2. jar-конфигурации будет зависеть от корректных версий составных частей приложения. То есть, всё приложение можно "вытянуть" за один jar-файл. Совместимость проверяется на этапе сборки — после успешной компиляции можно запустить интеграционные тесты.
  3. Отдельный jar для конфигурации будет, вероятно, не очень-то повторно используем. Сам микросервис, без конкретной конфигурации, — вполне себе повторно-используемый компонент. А конфигурация обычно — небольшой файлик. Просто компилируется отдельно.
Sign up to leave a comment.