Как стать автором
Обновить

Как я запускал Spring Cloud

Время на прочтение5 мин
Количество просмотров12K

Меня зовут Аксёнов Вячеслав, я старший бэкенд 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:

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-config</artifactId>
  <version>3.0.5</version>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bootstrap</artifactId>
  <version>3.0.4</version>
</dependency>

Версии зависимостей можно брать актуальные с https://search.maven.org/

Пример в pom.xml: https://github.com/v-aksenov/whid-bot/blob/master/pom.xml#L35-L44

Также application.properties заменяется на bootstrap.yml, в которой нужно указать название текущего приложения и адрес для подключения к спринг клауду.

spring:
	application:
  	name: whid-bot
  config:
  	import: http://localhost:8888/

В данном случае название приложения whid-bot, а адрес для клауда http://localhost:8888/

Этого достаточно - стартеры для spring-cloud уже включают в себя нужные настройки, которые позволят сервису при запуске правильно понять, что используется spring cloud и правильно сходить к нему по настройкам, используемым в bootstrap.yml. 

Настройка на стороне spring cloud:

Сам сервис конфигурации является отдельным спринг бут приложением. Для построения такого приложения требуются зависимость spring-cloud-config-server:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
    <version>3.0.5</version>
</dependency>

А также остальные зависимости, которые потребуются для работы spring boot приложения, как пример мой pom.xml: https://github.com/v-aksenov/spring-cloud-public/blob/master/pom.xml

Самое интересное начинается в конфигурации этого приложения.

spring.application.name=spring-cloud-name
server.port=8888
spring.cloud.config.server.git.uri=https://github.com/user/repo.git
spring.cloud.config.server.git.username=git_user
spring.cloud.config.server.git.password=*******
spring.cloud.config.server.git.searchPaths={application}

Что значит каждый параметр по порядку:

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:

bot:
  username: whiddy_bot
  token: *******
  active: true

spring:
  datasource:
    url: jdbc:h2:file:./h2-data/whid-bot
    username: *******
    password: *******
    driverClassName: org.h2.Driver
  jpa:
    spring.jpa.database-platform: org.hibernate.dialect.H2Dialect
    hibernate.ddl-auto: update
  h2:
    console:
      enabled: true
      path: /h2-console

logging:
  level:
    root: INFO
  file:
    name: ./logs/whid-bot-logs.log

Итог

Всего вышеописанного достаточно для того, чтобы запустить собственный сервис конфигурации spring cloud и настроить ваш сервис для хождения за конфигами в него. Эта статья была написана как для тех, кто только разбирается с разными элементами инфраструктуры, которые позволяет наворотить Spring Framework, а также для лично меня, который сейчас разобрался в теме и в будущем обязательно забудет, но сможет посмотреть здесь.

Ссылки на проект бота

Ссылка на проект кладуа

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

Всем чистого кода и хорошего дня :)

Фото обложки от: https://unsplash.com@pericakalimerica

Теги:
Хабы:
Всего голосов 15: ↑13 и ↓2+12
Комментарии13

Публикации

Истории

Работа

Java разработчик
296 вакансий

Ближайшие события

28 ноября
Конференция «TechRec: ITHR CAMPUS»
МоскваОнлайн
2 – 18 декабря
Yandex DataLens Festival 2024
МоскваОнлайн
11 – 13 декабря
Международная конференция по AI/ML «AI Journey»
МоскваОнлайн
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань