0

I am trying to set up a spring-cloud-config-server for production. I want to read multiple git repos so I am providing following configuration in application.yml of config-server placed in src/main/resources

spring:
  application:
    name: config-server
  profiles:
    active: git
  cloud:
    config:
      server:
        git:
          uri: https://somedomain.com/project1/project1.git
          username: project1user
          password: project1password
          repos:
            project2:
              pattern: project2/*
              uri: https://somedomain.com/project2/project2.git
              username: project2user
              password: project2password
              searchPaths:
                - 'src/main/resources'

Now, I want to externalize this configuration of the config server.

I could provide main git repo (https://somedomain.com/project1/project1.git) properties by environment variables like following

spring.cloud.config.server.git.uri=https://somedomain.com/project1/project1.git
spring.cloud.config.server.git.username=project1user
spring.cloud.config.server.git.password=project1password

But what about other git repo properties. Passing complex map-like structure would be pretty tedious if passed via environment variables.

What is the best possible way to pass this configuration of other repos? Passing some configuration as an environment variable has other disadvantages like those properties could not be refreshed on runtime.

Is there any possibility that additional repo configuration is picked by from some configuration file in main git (https://somedomain.com/project1/project1.git) itself?

Dhruv
  • 10,291
  • 18
  • 77
  • 126

1 Answers1

0

The Spring Cloud Config Server provides a configuration with multiples repositories and they can be accessed by url like we do for one git repo. The config server will fetch each configuration by a pattern, so your label {application} in the path will be the key to find the correct repository. Like in mine I did:

spring: cloud: config: server: git: uri: https://github.com/solivaf/config-properties-foo

Now we should add our additional repositories as you can see below:

spring: cloud: config: server: git: uri: https://github.com/solivaf/config-properties-foo repos: appFoo: pattern: app-foo uri: https://github.com/solivaf/config-properties-bar

Restart the config server and perform the requests below.

    $ curl localhost:8080/fooapp/prod
{
  "name": "fooapp",
  "profiles": [
    "prod"
  ],
  "label": null,
  "version": "8686fb74f9af0aead98bd20d6e20e84a37028781",
  "state": null,
  "propertySources": [
    {
      "name": "https://github.com/solivaf/config-properties-foo/application-prod.yml",
      "source": {
        "bar.foo": "testProdPropertiesYml"
      }
    },
    {
      "name": "https://github.com/solivaf/config-properties-foo/application.yml",
      "source": {
        "bar.foo": "testPropertiesYml"
      }
    }
  ]
}

Now we can see the repository used to application fooapp, as we don’t have any pattern mapped to this application, the config server will use the default app, now if we specify the pattern app-foo which is mapped in our config-server property file we should get another repository as response.

   $ curl localhost:8080/app-foo/prod
{
  "name": "app-foo",
  "profiles": [
    "prod"
  ],
  "label": null,
  "version": "f34ced0565042be4cf87c937c1dab2703e0b8ed2",
  "state": null,
  "propertySources": [
    {
      "name": "https://github.com/solivaf/config-properties-bar/app-foo-prod.yml",
      "source": {
        "foo.bar": "testProdPropertiesYml"
      }
    },
    {
      "name": "https://github.com/solivaf/config-properties-bar/application-prod.yml",
      "source": {
        "foo.bar": "testProdPropertiesYml"
      }
    },
    {
      "name": "https://github.com/solivaf/config-properties-bar/application.yml",
      "source": {
        "foo.bar": "testPropertiesYml"
      }
    }
  ]
}

Now, we have the correct repository which was mapped in our property file and all files which represents our app-foo application. The response order represents the hierarchy of the file being the most priority the first file in the list.

borchvm
  • 3,533
  • 16
  • 44
  • 45