Config Storage
Rigel is a store for configuration parameters, which may be edited by authorised administrators at runtime in a live system. Rigel stores the configuration names and values. Each parameter is typed. Common datatypes are supported, including integer, float, string, enum, etc.
Distributed DB Cluster
The configuration values are stored in etcd, a distributed database used for storage of small sets of key-value pairs. If one of the databases in the cluster fails, access is automatically redirected to an available member.
Secure Updates
Updates to the Rigel data store are done through web services from applications or from the admin interface. Rigel internally uses an IAM system for authentication and access control.
Full History of Changes
Rigel maintains a history of changes to each configuration parameter, with the user's identity and the timestamp of the change.
Realtime Changes Notification
The application code connects to the Rigel repository through the Rigel client library, which works as a layer on top of etcd. When etcd notes a change in the value of a parameter, it notifies all application instances connected to the repository in near real time, thus propagating changes through a cluster without any delay or application restart, configuration file reload. or Unix SIGHUP.
Client Libraries
Rigel offers client libraries for developers developing applications in Java and Go. Go is the native development language for the Rigel core, and client libraries are offered and fully supported in these two languages. One portion of an application may be written in Java and another in Go, and both may connect to a single Rigel configuration repository.
Containers
The Rigel service runs in a container, and requires no build from source when the application is built. Applications access the Rigel service through REST calls, and the Rigel service in turn uses an internal etcd repository for storing the key-value pairs. A cluster of containers may run the Rigel service, and these Rigel containers can in turn connect to a single instance of etcd or a cluster, providing fault resilience at each layer.
Admin interface
Rigel has a browser based interface which can be used for managing the value of configuration parameters. Rigel will support scheduled updates to the value of a parameter in a future release. In that case, an admin may connect on Friday evening and schedule that the value of a variable will change from 25 to 30 on Saturday morning at 5 AM.
Modern business applications do not run on a single server any more. They run on dynamic clusters, on virtual servers or in containers, locally or on the cloud. In the 20th century, server-side code would read a configuration file, e.g. the famous Java properties file, and get their configuration information. This has many problems for modern applications:
- Distributed applications do not have a cluster-wide file system for security and scalability reasons
- It is hard to edit the configuration information: dangers of data corruption if the system crashes while files are being written out
- The application does not reload the configuration after a file update
Some applications stored configuration parameters in a database instead of a file, which took care of data protection, but raised problems of bootstrapping (where is the configuration information for the database connection stored?) and increased the weight of the application. And it left unanswered the questions of propagating changes to values, and expected each application designer to design his own configuration management layer.
Rigel solves these problems by providing a small distributed database where a set of configuration values can be stored and accessed from anywhere in the cluster. The application bootstraps its configuration information off Rigel, and can be notified of changes to configuration parameters in real time if required.
Rigel comes with a user interface which may be used by an administrator to change values of configuration variables. The impact of the new value on the application is decided by the application designer.
The starting point where one can start further reading is the wiki of the main repository.
The main repository contains the Go code for the Rigel service. This code typically runs in a separate container, and does not need to be modified when the application code changes. This code also includes command-line tools to push new schema information to the Rigel service. This push is needed when a new release of the application is deployed. It also includes the client libraries for Go applications to access Rigel. These Go packages link with your Go application.
The Java code repository contains the Java client libraries which will link with your Java application and let your code access the Rigel service.
The UI repository contains the Angular code for the browser-based admin interface to let an authorised administrator view and edit values of parameters in a Rigel store.