Disclaimer
This post is part of a weekly writing challenge. Two of my friends and I agreed on holding a writing challenge in order to gain the writing habit as well as improving our writing skills.
Introduction
In the age of cloud environments and microservices architecture, a need to different way to mange the configurations for application/application instances has appeared.
For that purpose, software architects have many options to choose from. In this article we will talk briefly about some of the available options. In the next parts of this article we will go through each option in some details.
The solutions we will talk about are
- Spring cloud config server
- Central Dogma
- Consul
- Kubernetes ConfigMap and Secrets
Spring cloud config
Spring cloud config is part of spring cloud tools that provides the ability to externalize the configurations in a distributed systems. The project consists of two parts, a config server and a config client.
The config server is a simple spring boot application. It reads the configuration from a configuration repository and provides it to clients. The configuration server can be a directory on your file system, a git repository, or the HashiCorp Vault tool.
You can store the configuration in either yaml or .properties and read it in yaml, properties, or json.
Spring cloud config server also provides a REST API for the configuration, hence you can use it from any other technology.
Central Dogma
Central dogma is an open source configuration server based on git and zookeeper.
Central dogma works almost the same way as spring cloud config server. It reads the configurations from a configuration repository (git in this case) and provides them via REST Api, client library, and command line tool.
Central dogma has some features that (in my opinion) makes it better than spring config server.
Some of these features are
- The command line tool
- User interface.
- Access control and per-repository permission. (This part is achieved in spring config server via the Vault tool)
- high-availability.
Consul
Consul is a big tool provided by HashiCorp. It is known as a service discovery tool. It is much more comparable to Eureka than to config server tools but it also provides a key/value store which can be used as an external configuration server.
Consul allows the users to store indexed objects (configuration objects) and it also replicate the data across multiple server which provide a high availability feature.
The key/value store in Consul is very simple. It is not intended to be used as a replacement to key/value stores like Redis.
Kubernetes ConfigMap and Secrets
Kubernetes ConfigMap is much like Consul key/value store. Pods can consume the configuration from the ConfigMap as environment variables, command line arguments, and configuration files.
The problem with config map is that it does not provide secrecy or encryption. So, if you need to store sensitive configurations, it is advised to use Kubernetes Secrets instead.
In the next parts we will get into more details about each option.
Top comments (0)