====== 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//." ===== Motivation ===== * 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 [[cs_471_-_software_management#maintaining_a_lab_or_a_large_group_of_machines|simple scripts]] or [[https://docs.google.com/document/d/1S-GZoZJgHPi7Wdksuv91pyGjFPh-Z8KAQ2DW9n9-D5s/edit#bookmark=id.v1xwxovrvvbb|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. ===== Description ===== * 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. ===== CM Elements ===== ==== Operations and parameters ==== * 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 ==== * 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. ==== Facts ==== * 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. ==== Change handlers ==== * 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 ==== * 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. ==== Bundles and bundle repositories ==== * 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. ===== Popular CM Systems ===== * Ansible, Salt, Puppet and Chef (textbook, Table 23.1) {{:cs471:popular_cm_1.png?400|}} * Can all configure Windows as well as Linux and macOS systems * Each implement the CM elements differently. (textbook, Table 23.2) {{:cs471:popular_cm_2.png?400|}} ----