Меня зовут Аксёнов Вячеслав, я старший бэкенд Java/Kotlin разработчик в крупном энтерпрайзе. Однажды я попал на проект, полный микросервисов, в котором за конфигурацию отвечала такая штука как Spring Cloud. Чтобы разобраться как именно это работает я исследовал и прикрутил этот диковенный элемент к одному своему пет проекту. И в этой статье я пошагово покажу как я это сделал. А если точнее - как настроить Spring Cloud сервер конфигурации. В наше время программирование переросло из чего-то магического и таинственного в довольно прозаичное занятие. Построение бэкенд приложения перестало напоминать построение монолита с местными прикладными решениями разной степени понятности и магии. Место постройки собственных велосипедов заняло использование уже готовых решений, подходящих для конкретных задач.  Для бэкеда крупных систем прямо сейчас в преимуществе используется Java/Kotlin в качестве основного языка программирования. А там где есть Java и энтрпрайз, там рука об руку идет Spring Framework. И так как строить монолиты сейчас не модно, выбор делается в сторону микросервисов. (мое мнение, что делать микросервисы совсем уж микро  не стоит. Каждый сервис должен отвечать отдельной бизнес задаче. Но об этом я напишу в отдельной статье) И вот есть зоопарк сервисов - у каждого есть свои конфиги. И их нужно как-то менеджить. Вопрос - как это сделать? Итак, какую проблему решает Spring Cloud? Представим, что у вас есть 5 приложений на Java/Spring, каждое при старте подгружает разные конфиги (пароли/адреса для базы, внешних апи и тд). Есть разные окружения - test, dev, prod, stage и тд. Spring Cloud позволяет хранить все конфигурации для разных приложений и разных окружений в одном месте. Давайте разбираться как запускать эту систему на простом примере. Есть несложное приложение на Spring, которое нужно научить ходить в клауд за конфигами. В моем случае этим является бот для логирования рабочего времени в телеграме, который я написал для личных целей -  whid (what have I done). Но код открытый - кому интересно можете пользоваться моим, либо запустить для себя. На бизнес логику можно не обращать внимания, нас интересует только конфигурация для работы с Spring Cloud. Для этого в список зависимостей нужно добавить spring-cloud-starter-config и spring-cloud-starter-bootstrap: Версии зависимостей можно брать актуальные с https://search.maven.org/ Пример в pom.xml: https://github.com/v-aksenov/whid-bot/blob/master/pom.xml#L35-L44 Также application.properties заменяется на bootstrap.yml, в которой нужно указать название текущего приложения и адрес для подключения к спринг клауду.  В данном случае название приложения whid-bot, а адрес для клауда http://localhost:8888/ Этого достаточно - стартеры для spring-cloud уже включают в себя нужные настройки, которые позволят сервису при запуске правильно понять, что используется spring cloud и правильно сходить к нему по настройкам, используемым в bootstrap.yml.  Сам сервис конфигурации является отдельным спринг бут приложением. Для построения такого приложения требуются зависимость spring-cloud-config-server: А также остальные зависимости, которые потребуются для работы spring boot приложения, как пример мой pom.xml: https://github.com/v-aksenov/spring-cloud-public/blob/master/pom.xml Самое интересное начинается в конфигурации этого приложения. Что значит каждый параметр по порядку: server.port=8888 - указывает порт, на котором будет запущен клауд. Если не конкретизироваться, то поднимется на дефолтном спринговом 8080 spring.cloud.config.server.git.uri=https://github.com/user/repo.git - так как клауд удобнее всего использовать с конфигами, хранящимися в гите, то конечно ссылка на репозиторий с вашими конфигами, может быть как github, так gitlab, stash и тд. spring.cloud.config.server.git.username=v-aksenov spring.cloud.config.server.git.password=password spring.cloud.config.server.git.username, spring.cloud.config.server.git.password=password- соответственно логин и пароль для подключения к репозиторию с конфигами. spring.cloud.config.server.git.searchPaths={application} - это указатель того, что для поиска параметров будет использоваться значение из spring.application.name у приложения, которое обращается к клауду. Стоит держать в голове, что для разных профилей конфигурации нужно хранить в разных файлах. Например для профиля test - whid-bot-test.yml - для тестового окружения и для профиля prod - whid-bot-prod.yml для продового. Внутри моего приватного репозитория, где я храню конфиги для своих пет проектов лежит файлик с конфигурацией моего бота. Файл хранит в себе ровно то, что вы бы хранили в application.properties внутри основного приложения. whid.yml: Всего вышеописанного достаточно для того, чтобы запустить собственный сервис конфигурации spring cloud и настроить ваш сервис для хождения за конфигами в него. Эта статья была написана как для тех, кто только разбирается с разными элементами инфраструктуры, которые позволяет наворотить Spring Framework, а также для лично меня, который сейчас разобрался в теме и в будущем обязательно забудет, но сможет посмотреть здесь. Ссылки на проект бота Ссылка на проект кладуаНадеюсь, статья была для вас полезна, буду рад вашим комментариям о том как кто-то из вас готовит архитектуру собственных пет проектов. Будет здорово, если каждый сможет узнать для себя что-то новое.  Всем чистого кода и хорошего дня :) Фото обложки от: https://unsplash.com@pericakalimerica