Browse Prior Art Database

Configuration Management of Containerized Applications Disclosure Number: IPCOM000245777D
Publication Date: 2016-Apr-07
Document File: 4 page(s) / 138K

Publishing Venue

The Prior Art Database


This proposal, targets the fundamental problems of configuration information management (set, update, etc.) in containerized application, by assuming in future cloud environments, all configurations should be managed by a Configuration Information DataBase (CIB), rather than single configuration file per application. This disclosure describes a system and apparatus to manage the application configuration insides containers, and at the mean time keeps transparent for inside applications. In this disclosure, we claim: 1) A system that can package the configuration information with the application using container technologies; 2) Method to generate and manage the configuration of inside applications. 3) Inside application aware metadata (configuration format, application type, etc.) into the container layer. Mechanism to update application configuration inside container without restarting the entire container.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 01 of 4

Configuration Management of Containerized Applications

Before the emergence of cloud computing, applications run in hosts or virtual machines directly. The only way to control the application behavior is the configuration file way. For example, if we want to change the service port for an Apache instance, we have to set the port value in the Apache's configuration file, and try to reload or restart the application instance.

During those operations, service errors are easy to happen due to mistakes in the configuration file, even because of improper formatting.

In order to help manage configuration files and reduce the risks, there're several tools such as Ceph and Puppet, who can deploy applications' configuration file in central management with predefined templates.

However, this way is still focusing on files management, not the configuration files. The problem will become more difficult to overcome when various applications have different types of configuration files.

Hence, Devopers still need to handle lots of works, such as writing Ceph/Puppet templates for different types or versions of applications, and manage them manually.

We believe in the times of cloud computing:

1) All applications should be run inside containers, such as Docker [1] and LXC [2].

2) All configuration information can be abstracted as key-value pairs, possible in hierarchical structure. For example, the configuration item of a web service can be "server1.port.default = 80".

3) It is easy to maintain all applications' configuration information inside a centralized database (EtcD [3]), which can be accessed through some standard ways such as RESTful [4] API and ProtoBuf [5].


1) Docker:

2) LXC:

3) EtcD:

4) RESTful:

5) ProtoBuf:


Page 02 of 4

1. Architecture Overview

TODO: Multiple containers.

1.1. Container Layer

1.1.1. DB Proxy

DB Proxy will connect to remote DB, to get the configuration information from DB, and send the information to the Config Manager .

1.1.2. Client Proxy

Receive the operation request from the Clients CLI or UI tools, and convert them into inherent RPC call for the Operation Agent .


Page 03 of 4