Configuration Management common approach for the new systems Isa Goksu

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

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)

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)

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)

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

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