Использование Spring Cloud Config без Git

1. Введение

Spring Cloud Config — это библиотека, упрощающая внешнюю настройку для приложений Spring. Это позволяет нам предоставлять данные конфигурации как службу, что упрощает их получение из любого другого приложения, имеющего HTTP-клиент.

В этом руководстве мы рассмотрим, как использовать Spring Cloud Config без git.

2. Обзор конфигурации Spring Cloud

Библиотека Spring Cloud Config представляет собой типичную клиент-серверную модель . Централизованный сервер (или серверы) считывает данные конфигурации из какого-либо внешнего источника данных. Эти серверы предоставляют различные конечные точки HTTP, которые позволяют любому другому приложению запрашивать данные конфигурации.

Обзор конфигурации Spring Cloud

Spring Cloud Config также позволяет очень легко автоматически подключаться из приложения Spring Boot к серверу конфигурации. Данные конфигурации, предоставляемые сервером, можно затем использовать так же, как и любой другой источник свойств внутри клиентского приложения .

3. Git-провайдеры

Самый распространенный вариант использования Spring Cloud Config — хранить данные конфигурации внутри репозитория git . Этот тип установки имеет ряд преимуществ:

• Гибкость: репозиторий git может содержать различные типы файлов, в том числе двоичные.
• Безопасность: легко контролировать доступ как для чтения, так и для записи на детальном уровне.
• Аудит. Надежное отслеживание истории позволяет легко отслеживать изменения конфигурации.
• Стандартизировано: операции Git являются стандартными независимо от поставщика, что означает, что мы можем самостоятельно размещать или использовать любое количество сторонних поставщиков.
• Распределенный: Git с самого начала разработан для распределенного использования, поэтому он отлично подходит для облачных и микросервисных архитектур.

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

В следующем разделе мы более подробно рассмотрим использование Spring Cloud Config без git.

4. Использование Spring Cloud Config без Git

Когда мы говорим об использовании чего-то другого, кроме git, с Spring Cloud Config, мы действительно имеем в виду серверный компонент. Наш выбор хранилища данных не влияет на клиентский компонент. Влияет только сервер.

Внутри библиотеки Spring Cloud Config Server есть единственный интерфейс с именем EnvironmentRepository , который определяет источник конфигурации. Все источники конфигурации, как git, так и другие, должны реализовывать этот интерфейс .

Давайте посмотрим на некоторые из предоставленных реализаций.

3.1. Файловая система

Spring Cloud Config поддерживает использование файловой системы в качестве источника конфигурации. Чтобы включить эту функцию, мы должны указать следующее значение в файле application.properties сервера конфигурации :

spring.cloud.config.server.native.search-locations=resources/other.properties

По умолчанию место поиска предполагает ресурс пути к классам. Если мы хотим использовать любой произвольный файл, мы просто включаем префикс файлового ресурса:

spring.cloud.config.server.native.search-locations=file:///external/path/other.properties

В дополнение к этому свойству сервер конфигурации должен работать с включенным собственным профилем:

-Dspring.profiles.active=native

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

3.2. JDBC

Spring Cloud Config также может использовать реляционную базу данных для загрузки данных конфигурации с помощью JDBC . Это достигается с помощью класса JdbcEnvironmentRepository . Чтобы включить этот класс, мы должны выполнить несколько шагов.

Во-первых, библиотека spring-jdbc должна присутствовать в пути к классам. Если мы уже используем Spring Data JDBC или другую зависимую библиотеку, она уже будет присутствовать. В противном случае мы всегда можем указать его вручную:

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-jdbc</artifactId>
</dependency>

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

spring.datasource.url=jdbc:mysql://dbhost:3306/springconfig
spring.datasource.username=dbuser
spring.datasource.password=dbpassword
spring.datasource.driver-class-name=com.mysql.jdbc.Driver

В данном случае мы используем MySQL, но подойдет любой JDBC-совместимый драйвер.

Затем база данных должна включать таблицу PROPERTIES со следующими столбцами:

• ЗАЯВЛЕНИЕ
• ПРОФИЛЬ
• ЭТИКЕТКА
• КЛЮЧ
• ЦЕННОСТЬ

И, наконец, нам нужно указать профиль JDBC для сервера конфигурации:

-Dspring.profiles.active=jdbc

3.3. Редис

Spring Cloud Config также поддерживает Redis в качестве источника конфигурации. Это достигается с помощью класса RedisEnvironmentRepository . Как и в случае с источником JDBC, нам нужно выполнить несколько шагов, чтобы включить его.

Во-первых, нам нужно добавить зависимость к Spring Data Redis :

<dependency>
    <groupId>org.springframework.data</groupId>
    <artifactId>spring-data-redis</artifactId>
</dependency>

Во-вторых, нам нужно установить некоторые свойства для подключения к Redis:

spring.redis.host=localhost
spring.redis.port=6379

Затем мы должны убедиться, что наши свойства правильно хранятся в Redis. Мы можем использовать команду HMSET для хранения некоторых свойств образца:

HMSET application sample.property.name1 "somevalue" sample.property.name2 "anothervalue"

Если бы мы повторили эти свойства, мы должны были увидеть следующие данные:

HGETALL application
{
    "sample.property.name1": "somevalue",
    "sample.property.name2": "anothervalue"
}

Наконец, мы должны включить профиль Redis для нашего сервера Spring Cloud Config:

-Dspring.profiles.active=redis

Использование Redis в качестве источника конфигурации также поддерживает различные профили. Для этого мы просто добавляем имя профиля в конец приложения:

HMSET application-dev sample.property.name1 "somevalue" sample.property.name2 "anothervalue"

В этом примере мы создаем новый набор свойств в профиле с именем dev .

3.4. Секреты

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

Spring Cloud Config обеспечивает поддержку множества различных поставщиков облачных секретов. Ниже мы рассмотрим AWS, который использует класс AwsSecretsManagerEnvironmentRepository для загрузки секретов AWS в источник свойств.

Этот класс использует класс AWSecretsManager для выполнения тяжелой работы по обмену данными с AWS. Хотя мы могли бы создать его вручную, более простым решением является использование стартера Spring :

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-aws-secrets-manager-config</artifactId>
    <version>2.2.6.RELEASE</version>
</dependency>

Этот модуль включает в себя автоматическую настройку, которая создаст для нас экземпляр AWSSecretsManager . Все, что нам нужно сделать, это указать набор свойств в нашем файле bootstrap.yml :

aws:
  secretsmanager:
    default-context: application
    prefix: /config
    profile-separator: _
    fail-fast: true
    name: ConfigServerApplication
    enabled: true

Теперь предположим, что мы хотим сохранить учетные данные нашей базы данных в секрете и сделать их доступными для сервера конфигурации. Мы бы просто создали новый секрет по пути /config/application/database_credentials . Внутри мы будем хранить необходимые пары ключ/значение, необходимые для подключения к базе данных.

Эта конструкция также поддерживает различные профили. Например, если у нас есть сервер базы данных разработки, мы также можем создать для него отдельный секрет. Мы бы назвали его /config/application/database_credentials_dev.

3.5. S3

Еще один удобный способ хранения конфигурации — облачные файловые сервисы. Давайте посмотрим, как мы можем использовать AWS S3 в качестве источника конфигурации.

Во-первых, нам нужно добавить AWS SDK в наш проект:

<dependency>
    <groupId>com.amazonaws</groupId>
    <artifactId>aws-java-sdk-s3outposts</artifactId>
    <version>1.12.150</version>
</dependency>

Затем нам нужно указать некоторые значения для настройки подключения к корзине S3, содержащей наши файлы свойств:

amazon.s3.access-key=key
amazon.s3.secret-key=secret

И нам нужно указать определенные свойства для поставщика конфигурации AWS S3:

spring:
  cloud:
    config:
      server:
        awss3:
          region: us-east-1
          bucket: config-bucket

Нам также нужно установить профиль, чтобы обеспечить загрузку источника конфигурации AWS S3:

-Dspring.profiles.active=awss3

Все, что осталось, — это создать нужные файлы свойств, включая любые файлы, относящиеся к профилю, внутри корзины. Обратите внимание, что если у приложения нет профиля, сервер конфигурации принимает значение по умолчанию . Поэтому мы должны включить файл с этим суффиксом вместе с любыми другими файлами, содержащими определенные имена профилей .

3.6. Пользовательский источник конфигурации

Если какой-либо из предоставленных источников конфигурации не соответствует нашим потребностям, у нас всегда есть возможность реализовать собственный. В общем, это включает в себя создание нового класса, который реализует как EnvironmentRepository , так и Ordered :

public class CustomConfigurationRepository implements EnvironmentRepository, Ordered {
    @Override
    public Environment findOne(String application, String profile, String label) {
        // Return a new Environment that is populated from
        // our desired source (DB, NoSQL store, etc)
    }

    @Override
    public int getOrder() {
        // Define our order relative to other configuration repositories
        return 0;
    }
}

Затем мы просто создаем экземпляр этого класса как новый bean-компонент Spring:

@Bean
public CustomConfigurationRepository customConfigurationRepository() {
    return new CustomConfigurationRepository();
}

4. Несколько источников конфигурации

В некоторых случаях может потребоваться запустить Spring Cloud Config с несколькими источниками конфигурации. В этом случае мы должны указать пару частей данных.

Допустим, мы хотим работать с JDBC и Redis в качестве источников конфигурации. Первое, что нам нужно сделать, это определить порядок каждого источника в нашем файле bootstrap.yml :

spring:
  cloud:
    config:
      server:
        redis:
          order: 2
        jdbc:
          order: 1

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

Кроме того, нам нужно определить оба профиля для сервера:

-Dspring.profiles.active=jdbc,redis

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

5. Вывод

В этой статье мы рассмотрели различные источники конфигурации, которые можно использовать с Spring Cloud Config. Хотя git является отличным исходным кодом по умолчанию для многих проектов, он не всегда может быть лучшим выбором. Мы видели, что Spring Cloud Config предоставляет несколько альтернатив, а также возможность создавать пользовательских поставщиков.