[DISCUSSION]: Evaluating configuration management options

[JimMadge]

:scroll: Description

This issue is for building an evaluation for each configuration management language/system we will consider.

Contributes to (supersedes?) #28 Related to #836

:strawberry: Desired behaviour

We are able to make a decision to adopt one of the proposals or to keep the status quo.

:page_facing_up: Tasks

Options we should consider, and write a report for in this issue's comments

• [x] Ansible
• [x] Chef
• [x] Puppet
• [x] Salt/SaltStack

Definitions

Client/controlled node

A system which is being managed by the configuration management software.

Agentless

Some systems require that a daemon is running on controlled nodes. Agentless systems, like Ansible, do not. This has the advantage that you do not need to install or manage the configuration management software on each client.

Idempotent

In this context, applying the same operation repeatedly results in no change.

[JimMadge]

Ansible

• Actively developed/maintained
• Can manage Linux, Windows, BSD, ...
• Agentless, no client software/daemon
• Minimal client requirements
  • Linux: OpenSSH, Python
  • Windows: Powershell 3.0, .NET 4.0, WinRM
• Does not run on Windows
• Uses OpenSSH for communication (hence can use any(?) SSH authentication for example public key, LDAP)
• YAML playbooks with support for Jinja2 templating
• Can be idempotent (when taking some care to write playbooks)
• Consistency (desired state) checking should be possible with check and diff modes
• Can write modular, reusable tasks
• Community contributed tasks/modules
• Logging possible to both client and 'command' machines

[martintoreilly]

I like the agentless feature of Ansible. From the sounds of it, we could have an Ansible config server, with NSG rules allowing only one-way connections from the config server to all the VMs it is enforcing the config for.

[martintoreilly]

I think we should carefully consider what we want in terms of desired state configuration. Is idempotency enough or do we also want to be robust to changes in the client configuration (e.g. made by system updates or malicious actors)?

[JimMadge]

I think we should carefully consider what we want in terms of desired state configuration. Is idempotency enough or do we also want to be robust to changes in the client configuration (e.g. made by system updates or malicious actors)?

This is a really good point. You could even imagine a regular consistency check being part of our security procedures (in fact, do any of the certifications require this?).

When we have had a chance to assess each option, perhaps we should have a summary table outlining the features that are important or critical to us.

[JimMadge]

Chef

• Actively developed and maintained
• Client-server architecture. Clients are managed/configured by a single(?) server. Cookbooks, secrets, etc. can be uploaded to the server by (registered?) workstations.
• Daemon must be installed on clients
• Can managed Linux and Windows
• Chef workstation can run on Linux, Windows, OSX
• Complex with difficult to navigate documentation (might be a personal opinion)
• Cookbooks/modules are written in Ruby (presumably very flexible, but might require good familiarity with the language)

[JimMadge]

Puppet

• Actively developed and maintained
• Client-server architecture
• Daemon must be installed on clients
• Can manage Linux, Windows
• Custom, JSON-like, declarative language
• Idempotent

[JimMadge]

Salt/SaltStack

• Actively developed and maintained
• Agentless or Client-server architecture
• Can manage Linux, Windows
• YAML syntax
• Jinja templating
• Uses ZeroMQ (or SSH when agentless)
• Logging appears to be focused on warning/error level rather than state changes

[JimMadge]

Closing as stale. Would be better placed in a discussion if this becomes relevant for v4.