Configuration Management

UNIX and Linux System Administration Handbook (5th Ed., chapter 23, p. 833):

“Configuration management software automates the management of operating systems on a network. Administrators write specifications that describe how servers should be configured, and the configuration management software then brings reality into conformance with the specifications.”

• When all your systems are running the same OS on similar or same hardware, and these systems are always powered on and network connected, then solutions like simple scripts or clusterssh might be sufficient.
• But when dealing with a “heterogeneous fleet of systems and networks in various states of health”, then a more disciplined approach might be needed.

• Configuration management (CM) captures desired state in the form of code.
• The code acts as informal documentation of a network.
  • Any administrator or developer can read the code to determine how the system is configured.
  • The code isn't necessarily program code.
  • Most configuration management code uses a declarative (as opposed to procedural) idiom.
  • Rather than writing scripts, you describe the state you want to achieve.
  • The configuration management system then uses its own logic to adjust target systems as necessary.
• “Ultimately, the job of a CM system is to apply a series of configuration specifications, aka operations, to an individual machine. Operations vary in granularity, but they are typically coarse enough to correspond to items that might plausibly appear on a sysadmin’s to-do list: create a user account, install a software package, and so on. A subsystem such as a database might require anywhere between 5 and 20 operations to fully configure. Full configuration of a freshly booted system might entail dozens or hundreds of operations.” (textbook)
• CM does not free the admin from having to run commands or from having to know how to program (write scripts).
  • CM is not always the right tool for the job.

• Some admin operations that all CM systems can handle:
  • Create or remove a user account or set its attributes
  • Copy files to or from the system being configured
  • Synchronize directory contents
  • Add a new line in a configuration file
  • Restart a service
  • Schedule a periodic process, e.g., cron job
  • Run an arbitrary shell command
  • Create or remove a database account
  • Set database operating parameters
  • Many more…

• These operations are usually implemented using scripts, usually written in the implementation language of the CM system itself and exploiting the system’s standard tools and libraries.

• A well-behaved operation knows nothing about the host or hosts to which it might eventually be applied.
  • The implementation is written to be relatively generic and OS-agnostic.

• Operations differ from typical UNIX commands:
  • Most operations are designed to be applied repeatedly without causing problems.
  • Operations know when they change the system’s actual state.
  • Operations know when the system state needs to be changed.
    • If the current configuration already conforms to the specification, the operation exits without doing anything.
  • Operations report their results to the CM system.
  • Operations strive to be cross-platform.

• Just as UNIX commands accept arguments, most operations accept parameters.
  • A package management operation would accept parameters that specify the package name, version, and whether the package is to be installed or removed.
  • Parameters vary according to the operation and usually have default values that are suitable for the most common use cases.

• An admin can edit the operations of a CM system and can even add their own operations, if they are familiar with the underlying programming language.

• Variables are named values that influence how configurations are applied to individual machines.
  • They commonly set parameter values and fill in the blanks in configuration templates.

• CM systems investigate each configuration client to determine descriptive facts such as the IP address of the primary network interface and the OS type.
  • The facts are then accessible from within the configuration base through variable values, which can then be used to define parameter values or to expand configuration templates.

• Handlers are operations that run in response to some sort of event or situation rather than as part of a baseline configuration.
• In most systems, a handler runs whenever one or more of a designated set of operations reports that it has modified the target system.

• Bindings associate specific sets of operations to specific hosts or groups of hosts.
• A given host can match criteria for many different bindings.
  • For example, a node might be on a sub network, be managed by a particular department, or fill an explicitly designated role (e.g., web server).
  • The CM system takes account of all of these factors and activates the operations associated with each binding.

• A bundle is a collection of operations that perform a specific function, such as installing, configuring, and running a web server.
• CM systems let you package bundles into a format that is suitable for distribution or reuse.
• In most cases, a bundle is defined by a directory, and the name of the directory defines the name of the bundle.
• CM vendors maintain public repositories that include both officially blessed and user-contributed bundles.

• Ansible, Salt, Puppet and Chef (textbook, Table 23.1)

• Can all configure Windows as well as Linux and macOS systems

• Each implement the CM elements differently. (textbook, Table 23.2)