Configuration Management

Pithy

Configuration management software automates the management of many operating systems on a network.
Administrators write specifications that describe how servers should be configured, and the configuration management software then does their bidding.

Elements of configuration management

I haven’t included all the parts but theres more and some I already know well

Facts

CM facts are auto-discovered, per-client system attributes (e.g. primary NIC IP, OS type) exposed as variables in the config base for use in parameters and template expansion.

Change Handlers

If you change a web server’s configuration file, you had better restart the web server. That’s the basic concept behind handlers, which are operations that run in response to some sort of event or situation rather than as part of a baseline configuration.

Bundles and bundle repositories

A bundle is a collection of operations that perform a specific function like install and configuring a web server. Bundles can be packaged nicely for sharing and reuse.

An example is anisble’s role which defines the role of the bundle like jeff geerling’s docker role for ansible.

Configuration management software options

The core options are:

SystemCreatedImplConfigServerClient
Ansible2012PythonYAMLNoNo
Salt2011PythonYAMLOptionalOptional
Puppet2005RubycustomOptionalOptional
Chef2009RubyRubyOptionalYes

chef

chef is designed for large infrastruture with lots of machines. It will work on a single machine but it comes with complexity, only use with 100’s or 1000’s of machines.

puppet

puppet comes with baggage and has a small standard library, you’ll need to quickly use user shared packages.

ansible and salt

both good systems and work for the majority of sites

  • Large deployments are a comparative weak spot for Ansible
  • Ansible is an order of magnitude slower than Salt
  • Ansible gives you both more options and more opportunities to shoot yourself in the foot. It’s more securable, but that doesn’t necessarily mean that it’s more secure

CM Best Practices

  • Sensitive data (keys, passwords) should not be put under version control unless encrypted, even in private code repositories. Git in particular is not designed to maintain security.
  • Subdivide configurations ruthlessly. Every file should have a clear and single purpose.
  • In elastic cloud environments where computational capacity is added in response to real-time demand, the time that it takes for a new node to bootstrap through configuration management can be agonizingly slow. Optimize by including packages and long-running configuration items within the baseline machine image rather than downloading and installing them at boot time.