Now that you know about fractions and ways to explicitly configure Swarm, it’s a good idea to revisit the configuration options. We are already using a large number of system properties (i.e. bind address, port, etc) and some configuration values are hard coded within your custom Main() (i.e. service names, log level, etc). Let’s move all this into a separate file to make it more manageable.

In Swarm we use project stages (project-stages.yml) to differentiate between environments (i.e. consul URL, etc) and to capture configuration values that change when moving from one environment to the next (i.e. from local development > continuous integration > production)

These configurations can then easily be switched by using the system property -Dswarm.project.stage=<STAGE_NAME>

step 4.png
Figure 1. Stage specific configuration

Here’s an example for service “user”

service:
   user:
       service-name: "user-SNAPSHOT"
swarm:
   port:
       offset: 0
   consul:
       url: "http://<CONSUL_IP>:8500"
---
project:
   stage: <STAGE_NAME>
service:
   user:
       service-name: "user"
swarm:
   port:
       offset: 50
   consul:
       url: "http://<CONSUL_IP>:8500"

Concepts

  • Environment specific changes: configuration: project-stages.yml

  • Continuous delivery (in a wider context)

Tasks

  • Add a project-stages.yml to your sources (src/main/resources)

  • Use it to configure the service-name, port and consul-url

  • Make it to properly set the <CONSUL_IP> for property swarm.consul.url

  • Introduce a default stage and one called “production”

  • Remove any remaining configuration from the Swarm plugin

Outcome

  • You can run each service using different configurations, i.e. java -Dswarm.project.stage=<STAGE_NAME> -jar target/order-swarm.jar

  • The service name in project-stages.yml allows you to easily advertise a service that’s currently in development (i.e. for testing. Canary, A/B)