Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

Basics of Microservices -Part 2: The Spring Cloud Configuration Server

The first part of « Basics of Microservices » (http://nicolasduminil.blogspirit.com/archive/2018/05/25/basics-of-microservices-with-spring-boot-3106415.html) shown how to develop and deploy a complex microservice with Spring Boot. In this part we’ll show how to use Spring Cloud Configuration Server in order to segregate the property management process from the core microservice.

Our sample microservice presented in the first part used a property file to define its configuration. This property file belongs to the JAR or WAR archive hosting the microservice itself and, hence, in order to modify properties, one needs to rebuild the archive. Another point is that, while a majority of a microservice properties can be defined in property files, there are always properties which cannot, because they aren't known at the design/development time. Take for example a password. A developer cannot know it such to define it as a property in a property file. It is only known at the deployment time and it's the deployer responsibility to define it. But the build process is not the responsibility of the deployer, who even doesn't have the required tools.  Hence Spring Cloud provides a configuration server, in the form of a standalone microservice, which defines configuration properties.

The Spring Cloud Config Server supports a large variety of repositories, including file system based or GIT. In our sample we're using a GIT repository as the backend for the properties definition.

In order to look at the provide samples, you need to clone the GIT repository, as follows:

mkdir ms-core-config
cd ms-core-config
git clone https://github.com/nicolasduminil/micro-services.git
git checkout config 

The GIT repository above is the one hosting the project. You also need to clone the GIT repository hosting the configuration: 

mkdir spring-config
cd spring-config
git clone https://github.com/nicolasduminil/spring-config.git

Now let’s look at the code. The core microservice and the associated test is the same as previously. The only new part is the ms-config maven module. In order to use Spring Cloud we need this dependency:

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

Notice that the required dependency has been added to the ms-config maven module itself, as opposed to all others dependencies that has been defined in the parent POM and inherited by all the modules POMs. This is because, for some reason, including this dependency in the parent POM like all the others prevent the configuration microservice to start normally. This might be due to some issue in the current release of Spring Cloud. Here is the main class: 

package fr.simplex_software.micro_services.config; 

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.config.server.EnableConfigServer; @SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication
{
  public static void main(String[] args)
  {
    SpringApplication.run(ConfigServerApplication.class, args);
  }
}

That’s all we need. This code will run an embedded tomcat container having deployed in it a microservice named ConfigServerApplication. This microservice is our configuration service, the one that our core microservice will use in order to get its properties. Here is how: 

server:
  port: 8888
spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/nicolasduminil/spring-config
          searchPaths: hml-core
          username: nicolasduminil
          password: … 

The code above is the file application.yml found in ms-config/src/main/resources. It states the following:

  • The TCP port on which the config service will be listening is 8888
  • The back-end used for the propertis definition is a GIT repository
  • The GIT repository’s URL is https://github.com/nicolasduminil/spring-config
  • The path inside the repository to the properties set is hml-core.
  • The credentials required to access the GIT repository are given by the username and password fields.

Notice that the password should be given in an encrypted form. But for simplicity sake we used it in clear text. This is all we need here. There is a bootstrap.yml file which only defines the name of the microservice which will be used as the config service, as follows: 

spring:
  application:
    name: ms-config 

That’s all. Of course, our core microservice stays exactly the same as previous, we only have to add to its src/main/resources the following bootstrap.yml file: 

spring:
  application:
    name: hml-core
  profiles:
    active:
      default
  cloud:
    config:
      uri: http://localhost:8888

This file only states the name of the current microservice (hml-core) and the URL of the configuration service from where it will take its properties (http://localhost:8888). In order to build and run the project you need to perform the following operations: 

mvn –DskipTests clean install
docker-compose –f docker/common/docker-compose.yml up 

Here you’re using directly the docker-compose command to orchestrate the docker containers. This is as opposed to the first part where you were using the docker-compose plugin for maven. The reason to that is that we have now several docker-compose.yml files, one for each profile we defined. There are currently three profiles named common, dev and prod. They are all the same here, for simplicity sake but, in a real case, they will certainly be different. The command above builds with the common profile, which is the default one. Of course, we could have used maven profile here, with the docker-compose maven plugin, but it probably would have been a bit more complicated. Once the build has finished, we’ll find ourself with the following three docker containers running:

  • A container named active-mq running the ActiveMQ broker, like previously
  • A container named ms-core running our core microservice, as previously.
  • A container named ms-config running the Spring Cloud config service.

The three containers start in order, first active-mq, then ms-config and at the end ms-core. They wait for the previous one to start completely using the same technique as presented in the part one. You may now run the test, as you did previously, such that to check that everything behave as expected. You may directly fire you browser at http://localhos:8888/hml-config/<profile-name> to see the JSON payload of the defined properties. 

Again, just by running a simple command line, you got and even more complex environment, running three docker containers, each one hosting a full Linux OS. Enjoy !

Les commentaires sont fermés.