tags: [] --- :toc: :icons: font :source-highlighter: prettify :project_id: pat-external-configuration This pattern describes how to architect a centralized configuration for your application, which is external from the deployment package.
Some form of configuration is required by most production applications. Often, this configuration is deployed in the root of the application as a file or group of files which contain environment specific settings or profile information such as database connection credentials, third party API access tokens, environment specific URLs, etc.
A local configuration may require application downtime when publishing an updated configuration. Additionally, a local configuration cannot be used by multiple application instances. There is also a challenge of versioning a local configuration, which may require manual management.
Synchronizing configuration across multiple application instances or environments can be problematic. Instances may be using different configuration while the update is progressing. And there is always a risk of an instance not receiving an updated configuration.
The solution to each of the described problems is to store the configuration in an external location that supports versioning. By doing this, all application instances can utilize the same configuration, downtime is limited, and synchronization is no longer a risk.
The Pivotal Cloud Foundry Marketplace offers the Config Server for Pivotal CF as a service for providing externalized configuration to your applications running on PCF. The Config Server provides an HTTP, resource-based API for external configuration. The recommended location for the configuration is a Git repository. The URI of the Git repository is required to complete the setup of the Config Server service. It then propegates the resolved configuration to the associated client applications. The expected configuration is in the form of name-value pairs, or equivalent YAML content.
This diagram illustrates a deployment with three app instances configured to utilize a configuration server, which in turn is configured to read configuration from an external Git repository. The app instances and configuration server are all deployed within Pivotal Cloud Foundry.
Consider the following issues when using the external configuration pattern:
-
The external Git repository should be highly available to the Config Server. Regardless of whether the Config Server caches the configuration, the server hosting the git repository should be performant and available.
-
The backing store supports name-value pairs from properties files or YAML content. This provides for a flexible and extensible configuration schema.
-
Understand and test situations where the configuration may contain errors or is missing required information.
-
Limit who has access to make configuration changes. These changes can have a major impact on application stability and security, and it is prudent to establish procedures and protocols for making additions and changes.
-
All associated apps will receive configuration changes when introduced. This means there is a risk that a configuration change may have unintended effects on one or more applications.
The following list contains some examples regarding when to use the external configuration pattern:
-
Multiple applications or instances share configuration.
-
Operations team needs to change logging levels of a running application in order to debug a production issue.
-
Operations team needs to quickly change the number of threads receiving messages from a message broker.
-
Operations team needs to update the URL of a SaaS web service due to an outage or change in environment.
-
Operations team is required to produce a report of all the configuration changes that have been made to the production system in order to support Sarbanes-Oxley auditing.
-
Operations wants to be able toggle features on/off in a running application.