Configuration Management

Various configuration needs and how to solve them in the enterprise, including app specific configurations, environment specific configuration, network related configurations, etc.

1. Configuration Management common approach for the new systems Isa Goksu
2. Configuration Types •  Apps –  Sandboxed app specific (max-retries, ids, thresholds, etc) –  Apps with external dependencies (db, service, etc) –  Apps in Different Environments (local, dev, test, dr, etc) •  Machines –  OS-specific settings (ntp, mount points, etc) –  Service level settings (ssh, mongod, iptables, etc) •  Clusters –  Coordination & Consensus (service discovery, service registration, etc) –  Hardware Firewalls –  Network device configuration
3. Apps •  Sandboxed app specific configurations –  In-app settings •  Usually never good •  Can be accepted if the configuration requires re-write in the app –  Configuration files •  Excellent for I18N •  Excellent for sandboxed settings (port number to open, maximum retry, timeouts, etc) •  Excellent for startup settings –  Central database •  Excellent for replicated configuration (queue size, order limit, etc) •  Excellent for frequently used configuration values (# of tasks in parallel)
4. Apps •  Apps with External Dependencies –  In-app settings •  Should not be allowed –  Configuration files •  Should not be allowed where possible •  Automated propogation should be guaranteed (puppet, chef, etc) –  Central database •  Nice and clean solution •  Single point of failure •  Watch-out (Performance, DR strategy, etc) –  Distributed coordination & consensus •  Apache ZooKeeper (no-brainer)
5. Apps •  Apps in Different Environments –  Configuration Files •  Local –  There should be a template file with reasonable defaults in it –  Every dev should use a copy of it and configure the way they want •  Rest (dev, test, uat, pre-prod, prod) –  Should never be configured manually –  Deployment system (TeamCity or a script) should override the defaults with environment specific settings during deployment –  Database •  Should be separated by domain/namespace in the configuration db –  Consensus •  Should be prefixed with the environment (i.e dev/app-id/max-retry, etc)
6. Machines •  OS-specific –  VMs •  Start with Golden Images •  Take snapshots as much •  Service-level Settings –  Infrastructure as code (Puppet, Chef, Ansible, etc) –  Use of enterprise repos (prod vs rest) –  Signed Code & Package
7. Clusters •  Coordination & Consensus –  DNS for service discovery –  ZK for serialization (sequential access), syncronization and coordination •  Hardware Firewalls –  Puppet can manage firewalls including ASA –  Zero configuration mistake