1. Configuration & Registry Microservice Deep Dive
Tech Talks – Session 7

2. Agenda C&R general purposes C&R makeup - Consul and additions
Config Seed
Config Watchers
Integration with other micro services
How micro services bootstrap with C&R
Configuration in micro services
Default settings in development versus deployment (docker)
Configuration data organization and naming conventions
key/value pairs
association to microservice id namespace
profiles
Consul Web Interface
Registry and service health
Dynamic reloading of config data
Watchers
Future Considerations and additions
registry
more with watchers
Consul or ? (Consul's architecture)
Q&A

3. Jim White Dell Distinguished Engineer & Senior Software Architect
From Dell End User Computing (EUC) CTO
Chief Architect and lead developer of Fuse
I wrote code line #1 
Fuse => EdgeX Foundry

4. Big Picture and Config/Registry

5. Configuration and Registration’s Role
Provides centralized management of
Configuration and operating parameters for any and all EdgeX Foundry microservices.
The location and status of EdgeX Foundry microservices
It provides configuration information to each microservice at startup.
This configuration information overrides any built-in configuration the microservice might have
Provides a means to meet the dynamic nature of microservice architectures.
Example: specify a different port number than what is provided in the service’s default configuration
Provides the means to notify EdgeX Foundry microservices of a change to its configuration
Allows other microservices to react dynamically to changes in environment
The registry subsystem knows the location and operating status of all the EdgeX Foundry microservices.
As each EdgeX Foundry microservice starts, it is requested to register itself with the Configuration and Registry microservice.
The Configuration and Registry microservice then periodically "pings" the microservices to keep an accurate picture of the health of the microservices.
This can provide other EdgeX Foundry microservices, system management systems, and 3rd party applications with a single authoritative place to get EdgeX Foundry status.

6. Configuration and Registry Makeup
Consul -
This is an open source project provided by Hashi Corp
Mozilla Public License, version 2.0
You will find NO configuration and registry repos in EdgeX Github!!
There is a Docker container (docker-core-consul) with Consul for your convenience
The core-config-seed repos contains code for initializing the microservice.
Java/Spring Boot application
It loads the default configuration from property or YAML files, and push values to the Consul Key/Value store.
It runs only once in the life of the EdgeX instance.
It has also been containerized (core-config)
The core-config-watcher repos contains code for watching config changes and notifying other microservices
Java/Consul API
Works by way of registration and callbacks
Not used today, but stands ready to be used

7. Bringing Config/Registry Up via Docker
In the documentation, note that the first three containers to start in EdgeX are:
edgexfoundry/docker-edgex-volume
edgexfoundry/docker-core-consul
edgexfoundry/docker-core-config-seed
First, lays down the file system used by Consul and other elements
like the database and logging system
Second, stands up Consul instance
Third, initializes Consul with EdgeX config and then exits
And never restarts!
Demo Time

8. Microservice Integration with Config/Reg
Spring provides convenience libraries to allow services to register with Consul and get config info from Consul
Other languages may have libraries or use Consul REST APIs to do the same

9. Java Microservice Integration with Config/Registry
Add spring-cloud-consul-dependencies to the project’s pom.xml
Add a bootstrap.properties file to the project
Does differ in dev versus Docker runtime environments
Note the bootstrap.properties in src/main/resources versus dockerfiles folders
spring.application.name=edgex-core-data
spring.cloud.consul.host=edgex-core-consul
spring.cloud.consul.port=8500
spring.cloud.consul.config.profileSeparator=;
spring.cloud.consul.enabled=true
spring.profiles.active=docker
to the microservice “main” app class
You’ll see this in the documentation and in all microservices today
See
Versus

10. Configuration - How it works
When the microservice starts, annotation gets the service connected and activated with Consul
Based on the bootstrap properties, if enabled, the projects local configuration files (application.properties for example) are overridden by what is in Consul
All before the application starts
In development
Consul is not enables
No registration occurs
The microservice just uses what is in its local file properties
Consul
Register & get config
microservice
microservice
Local file props
Config data
Local file props

11. Configuration Data Organization and Naming
Applications traditionally use key/value pairs to provide configuration data often located in files
Example: server.port=48080
This does not change in Consul
What changes is that Consul allows for multiple “namespaces” of config
Consul uses namespaces to identify the associated microservice config
Example:
/config/core-metadata/server.port=48081
/config/core-data/server.port=48080
Additionally, Consul allows for profiles to further distinguish between conditional or environmental configurations
/config/core-data/server.port= (the global configuration)
/config/core-data/server.port;dev= (the development configuration)
/config/core-data/server.port;docker=48080 (the Docker configuration)
In core-config-seed, you’ll see this convention used to specify the various configurations Consul is initialized with (and uses when running)
The microservices don’t have to worry about this except abiding by the naming conventions
See

12. Consul Web Interface
Perhaps the best way to explore Consul config data and understand the conventions used by EdgeX is by Web UI.
Consul comes with a default user interface to explore (and change) the configuration data
host]:8500
Demo Time

13. Config Watchers
Updates to the configuration data in Consul can trigger REST notifications (callbacks) to the associated microservice
Health checks can also result in callbacks to report an issue with a microservice
Consul provides “Watchers” to register for interest to particular configuration settings
This functionality is wrapped by core-config-watchers
Requires microservices implement registration and callback handling code
This functionality is not being used by microservices (or other applications) today, but could be utilized going forward
Would allow for more dynamic updates during runtime

14. Registry – How it works
When the microservice comes up, it registers with Consul
Done automatically with Spring libraries and coding already discussed
Languages with such libraries can use Consul REST API
Once registered, Consul periodically pings the microservice for a status check
Remember all the “ping” APIs in the other services?
Consul uses them!
A health check path is set to /api/v1/ping for each

15. Future of Config & Registry Microservice
EdgeX is not using all of Consul’s power today
We don’t have other microservices use the Registry to discover another service
Although we do use the dynamic config data to provide the address of the other services to any microservice
We don’t utilize the watchers
Could tie this into system management health checks
Could tie this into broader notifications/alert service
We don’t utilize the leader/follower/follower capability of Consul
We have just one instance
Would allow for failover, scale and distribution of Consul abilities
These services might be helpful in the future but may also add overhead not needed today (architectural questions going forward)
Should we explore simpler alternatives or start to use more of Consul

16. Upcoming Tech Talks Export micro services & rules engine
Using the SDK to generate a device service
Supporting services (logging, notifications)
me other suggestions

17. Questions and Answer Time