Microservice Advance: Centralized Configuration Server using GitHub

Introduction#

Centralized Configuration Servers have become crucial components for microservices architecture by letting services dynamically fetch configuration properties from a centralized repository like GitHub through Spring Cloud Config Server. This guarantees consistency, scalability, security, and flexibility among various services and environments.

As a mediator between multiple microservices and the GitHub repository for fetching configuration properties to serve different client applications, it will ensure any update that needs to be done on the configuration is reflected instantaneously without redeployment of services efficiently and smoothly with configuration management and constraint on the services.

Real-life Analogy#

The Centralized Configuration Server in a microservices architecture is an electronic recipe book for restaurant chains stored on GitHub. Each restaurant branch (microservice) retrieves the latest recipes and pricing (configurations) from the common source rather than adhering to an outdated copy of hard-coded instructions. This dynamic update takes place seamlessly, with different branches having different menus based on their locality (environment profile). In doing this, the above contributes toward consistency, agility, and scalability for all services.

Centralized Config Server#

An example of an approach taken by users of architecture microservices isolating a configuration server is having dedicated services, which is a central repository with configuration properties for multiple microservices, instead of letting microservices-based services, like other services, store their configuration designs individually and only during runtime access the configuration needed for both the client and the service from a dedicated config server.

Cloud-based on feature:#

• Centralized Management: Bring consistency through sole storage of all the configuration properties in one.
• Dynamic Updates Forms: Microservices self-serve updated configuration environments while at the same time sustaining the older self-service that requires no redeployment.
• Multiple Environment Configuration: Environment-specific, environment-agnostic specificity, props that can be different in dev, test, and prod environments, and individual profiles (like separate databases for separate environments or API keys).

This enhancement of microservice architecture further increases the scalability and flexibility of the architecture's security and makes configuration management such and such reliable.

Configure the Config Server#

1. Create a Spring Boot Application (Maven) for Config Server#

Add the 'Config Server' dependency.

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

Except for the 'Discovery Server,' all other applications should be registered as 'Discovery Clients' as needed. After extracting, try to add it as a Maven project and reload it.

2. Enable the Config Server#

In the main application class, add @EnableConfigServer

3. Create a GitHub Repository for Configuration#

1. Create a public or private repository on GitHub (e.g., config-repo), using the main or master branch as the default.
   1. Step 1:

1. Step 2:

• Step 3:

• Step 4:

• Step 5:

• Step 6:

1. Just copy the page URL. It should look like this: https://github.com/<User name>/<User repository name>.
2. Since I created a private repository, we need a password or authentication token to pull all values.
   1. Step 1:

• Step 2:

• Step 3:

• Step 4:

• Step 5:

• Step 6:

• Step 7:

• Step 8:

The access token is used as a password.

4. Configure GitHub as the Backend#

Add the following in application.properties (or application.yml):

spring:
  cloud:
    config:
      server:
        git:
          uri: <https://github.com/><user name>/ecommerce_config_server
          username: <user name>
          password: <user access token>
          default-label: main

server:
  port: 8888

eureka:
  client:
    service-url:
      defaultZone: <http://localhost:8761/eureka>
  instance:
    prefer-ip-address: true

5. Run the Config Server#

• Start the Spring Boot application (Start the Discovery Server first, then the Config Server and other clients).
• Verify by accessing: http://localhost:8888/<any name>/default
• (Replace <any name> with the actual service name.) It basically tries to find the profiles and all details of that particular service.

If the Spring Cloud Config Server returns an empty"propertySources": [], it means no configuration was found for the corresponding service request. It could be an incorrect repository URL, missing configuration files, mismatched profiles, or even authentication issues for private repositories. To correct the above, proceed by checking the GitHub repo URL and ensuring that the said config files exist. Then the service name and profile should be checked, and finally authentication should be configured, if necessary, after all these. Thereafter, restart the Config Server following the amendment of changes.

Configure the Config Client#

1. Add Dependencies#

In all the microservices that you want to configure as a client (Config Client), add the following dependencies in pom.xml:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-config</artifactId>
</dependency>

2. Configure application.properties or application.yml#

spring.config.import= configserver:http://localhost:8888

3. Remove all configurations from application.properties and move them to a GitHub configuration file, keeping only the application name.#

4. Create a GitHub file for Configuration (inventory-service)#

5. Run the Config Client after starting the Discovery Server and Config Server (http://localhost:8888/inventory-service/default)#

You can also hit the API for the dev or prod profiles."

6. Profile to fetch (e.g., dev, prod, default)#

Create a GitHub file for Configuration for dev, prod, and default (application.properties)

spring.profiles.active=dev/prod

Inside GitHub you can set my.variable=default/prod/dev .

1. Access Configuration Properties in the Application

Use @Value to inject properties from the Config Server:

import org.springframework.beans.factory.annotation.Value;

@RestController
@RequestMapping("/products")
public class ProductsController {

    @Value("${my.variable}")// Fetching property from Config Server
    private String message;

    @GetMapping("/config")
    public String getConfigMessage() {
        return "Config Message: " + message;
    }
  }

1. Run the Config Client after starting the Discovery Server and Config Server (http://localhost:9020/inventory/products/config)

In Postman, when requesting to inventory-service without setting any active profile, it defaults to the 'default' profile.

• In the IDE console of inventory-service logs: After setting the active profile as 'dev', first run it with the default profile, then with 'dev'.

Postman:

Benefits of a Centralized Config Server in Microservices#

A Centralized Config Server streamlines microservices configuration by providing a single source of truth, enabling dynamic updates, ensuring environment-specific settings, and enhancing security through version control with Git. It reduces maintenance overhead, ensures consistency, and improves scalability.

For API Gateway management, it allows real-time configuration updates, secures sensitive credentials, centralizes routing, authentication, and rate-limiting rules, and minimizes manual updates. This approach makes microservices architectures more efficient, secure, and easier to manage.

Conclusion#

This article explores the Centralized Configuration Server using GitHub in a Microservices Architecture. It highlights how Spring Cloud Config Server enables microservices to dynamically fetch configurations, ensuring consistency, scalability, and real-time updates across different environments.