Scentralizowana konfiguracja za pomocą Config Server

In a microservice architecture, you might have many services, each with its own configuration files. Managing these files individually can become a huge challenge.

Imagine updating a database connection string across 20 different services! It's prone to errors and time-consuming.

• Decentralized configs: Hard to manage at scale.
• Inconsistent configs: Different services might have slightly varied settings.
• Manual updates: Tedious and risky.

Spring Cloud Config Server provides a centralized externalized configuration service for distributed systems. It's built on Spring Boot and can easily integrate with various backend storage options.

Think of it as a central hub where all your application's settings live. Your services (clients) then fetch their configurations from this hub.

• Centralized storage: One place for all configurations.
• Version controlled: Configurations stored in Git (or similar).
• Environment specific: Easily manage configurations for different environments (dev, prod).

To create a Config Server, you first set up a basic Spring Boot application and add the spring-cloud-config-server dependency. Then, you enable it with the @EnableConfigServer annotation.

Here's the main class for our Config Server:

The Config Server needs to know where to find your configuration files. Typically, these are stored in a Git repository.

You configure the Git repository URI and search paths in your application.properties or application.yml file:

server.port=8888
spring.cloud.config.server.git.uri=https://github.com/your-org/config-repo.git
spring.cloud.config.server.git.search-paths=configs

This tells the server to run on port 8888 and fetch configurations from the specified Git repository, looking inside the 'configs' folder.

Inside your Git repository (e.g., config-repo.git), you'll create configuration files for each service. The naming convention is {application-name}-{profile}.yml or .properties.

For our Spring Cloud Gateway, let's assume its spring.application.name is gateway-service. A basic configuration file in your Git repo (e.g., configs/gateway-service.yml) might look like this:

spring:
  cloud:
    gateway:
      routes:
        - id: example_route
          uri: http://example.org
          predicates:
            - Path=/example/**

Now, let's configure our Spring Cloud Gateway to act as a client and fetch its configurations from the Config Server. You'll need the spring-cloud-starter-config dependency.

Instead of application.properties, the client uses bootstrap.properties (or .yml) to connect to the Config Server *before* the main application context loads.

spring.application.name=gateway-service
spring.cloud.config.uri=http://localhost:8888

The spring.application.name helps the Config Server find the right config file (e.g., gateway-service.yml).

Once configured, your Gateway service will automatically connect to the Config Server at startup, fetch the configurations (like routes, predicates, filters), and apply them.

This means you can define all your gateway's routing rules, global filters, and other settings in the Git repository, managed by the Config Server, rather than directly in your gateway's code.

For example, a route defined in gateway-service.yml in your Git repo will be applied by your gateway.

Config Server excels at managing environment-specific configurations. You can create files like gateway-service-dev.yml or gateway-service-prod.yml in your Git repo.

Your gateway client can then specify its active profile in bootstrap.properties:

spring.application.name=gateway-service
spring.cloud.config.uri=http://localhost:8888
spring.profiles.active=dev

The Config Server will prioritize gateway-service-dev.yml, overriding any properties in the base gateway-service.yml.

One powerful feature is the ability to refresh configurations without restarting your Gateway service. This is achieved using Spring Cloud Actuator and the @RefreshScope annotation.

1. Add spring-boot-starter-actuator dependency to your Gateway.

2. Enable the /actuator/refresh endpoint in your application.properties:

management.endpoints.web.exposure.include=refresh

3. Annotate any beans in your Gateway that use configuration properties with @RefreshScope.

After updating your Git config and pushing changes, you can send a POST request to /actuator/refresh on your Gateway, and it will pull the new configs!

Which of the following are key benefits of using Spring Cloud Config Server for a microservices architecture?

You've learned how Spring Cloud Config Server tackles the challenge of managing configurations in distributed systems. It acts as a central hub, typically backed by a Git repository, to store and serve configurations.

Key takeaways:

• Config Server: A Spring Boot app with @EnableConfigServer.
• Config Client: Your Gateway (or other services) connecting via bootstrap.properties.
• Git Integration: Configurations stored as {application}-{profile}.yml.
• Dynamic Refresh: Update configs on the fly using Actuator's /refresh endpoint and @RefreshScope.

This centralized approach brings order and efficiency to your microservice configuration management!