Configuration in the 12factor app spirit. Microservices influence on how to tackle system & application configuration

1. Configuration
How To

2. The problem
Company Goal
To Deliver Software more
frequently with high
quality
Context
Configuration
Immutability
Problem statement
Configuration is by
definition mutable.
How do we maintain
software immutability yet
manage runtime
configuration changes?

3. Challenges deep-dive
Challenge 1
Immutable infra
solved with containers
for software deployment
Challenge 2
Configuration
Legacy arrangements:
Each kind
(build/deploy/runtime)
had suitable location:
some in local files, some
in database, LDAP, other
kinds of storage (e.g.
Memcache, Redis)
Challenge 3
Settle them together
So what needs to
change?
How do we keep
immutability yet
introduce configuration?

4. Solution
Environment & Distributed
12 Factor App approach: if it is
Environment related - inject it
through environment (variables).
Otherwise?
Distributed Cluster to the rescue

5. Implementation

6. Distributed Configuration Clusters
Environment:
- SOLR_HOST=...
- ZK_HOST=...

7. Orchestration Example - Env
nodejs:
image: 'tutum.co/tpaz/nodejs:latest'
environment:
- NODE_ENV=production
- REDIS_HOST=redis
links:
- redis
restart: always
tags:
- nodejs
- production
target_num_containers: 8
volumes:
- '/var/log/nodejs:/var/log'
analytics:
image: 'tutum.co/tpaz/analytics:latest'
command: '-p analytics'
environment:
- DATABASE_HOST=somewhere.aws.com
- ANALYTICS_ENV=production
restart: on-failure
tags:
- analytics
- production
volumes:
- '/var/log/analytics:/var/log'
haproxy:
image: 'tutum.co/tpaz/node_haproxy:latest'
links:
- nodejs
ports:
- '80:80'
- '443:443'
restart: always
roles:
- global
tags:
- load-balancer
- production
redis:
image: 'redis:latest'
expose:
- '6379'
ports:
- '6379:6379'
restart: on-failure
tags:
- nodejs
- cache
- production

8. Distributed Conf Example: clusters
You already done it or are already using it!
TAS POC: used sky-dns for service discovery. Host names and IPs were on etcd (could be
done on Consul the same) instead of host files.
REST API to update, DNS client reads from Sky-DNS as normal DNS. Registrator, an
agent container, updates on containers change in state. Sky-DNS reads configuration from
cluster.
HyBrid for interim period
Examples for Hybrid solutions (apps reading from local files as used to, a 3rd-party updates
the local files from cluster and ‘Refresh’ the application):
● Consul Template
● confd

9. Did someone mention State, Version Control?
hmm… either:
1) Always be backward/future compatible
2) Add versioning in-to configuration hierarchy
3) Both
Best Practice: used to be #2 (as was for REST APIs, e.g. /api/1.0/blabla/…). However! no longer so,
trend is towards #1, gradually (Canary) or Blue/Green replace SW version at production, roll
forward…
There are other important means to know what has changed and react accordingly, e.g. audit event
log. It’s more a matter of how you design your system for maintainability than configuration store

10. Impact
Immutability maintained,
Manageable Configuration
max growth