Configuration & Registry Microservice Deep Dive Tech Talks – Session 7

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

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 james_white2@dell.com

Big Picture and Config/Registry

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.

Configuration and Registry Makeup Consul - https://www.consul.io 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

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

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

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 Add @EnableDiscoveryClient to the microservice “main” app class You’ll see this in the documentation and in all microservices today See https://github.com/edgexfoundry/core-data/blob/master/docker-files/bootstrap.properties Versus https://github.com/edgexfoundry/core-data/blob/master/src/main/resources/bootstrap.properties

Configuration - How it works When the microservice starts, the @EnableDiscoveryClient 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

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=48080 (the global configuration) /config/core-data/server.port;dev=48080 (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 https://github.com/edgexfoundry/core-config-seed/tree/master/config

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 http://[consul host]:8500 Demo Time

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

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

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

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

Questions and Answer Time