By Taos
With such a wide proliferation of configuration management tools, like Ansible, Chef, Puppet, Salt and a myriad of others, providing configuration packages for each OS distribution can provide lowest-common-denominator components to all of them (or none of them) for maximum portability and flexibility.
This article gives a brief overview on how configuration management packages work, what a configuration management package contains and what is required to build them.
CM Tool Feudalism or Anarchy
In today’s world of DevOps there is no shortage of choices when it comes to configuration management tools. It is ideal to be able to select and implement the single solution that is appropriate for all configuration management requirements within a service provider’s IT infrastructure; especially one that can configure a variety of platforms and infrastructure topologies: Microsoft Windows machines, Linux machines, public and private clouds, VM and bare metal. However, the experience of the CM engineer is often not ideal, especially with organizations that have been around awhile with aging and in some cases, antiquated infrastructure. The CM engineer may have been assigned this task in an organization that has had a history of failed or half-started attempts at implementing an automated configuration management strategy. There may be groups of hosts either on-premise or in the cloud that have poorly designed, dated or malfunctioning CM implementations in place. Perhaps, the target environment is one that is an amalgam of acquisitions, with little or no central management of infrastructure assets. The host groups for each of the acquired business units may themselves have varying levels of management with different strategies (or no strategies) and different inventories of tools use for configuration management.
In situations like those described above, relying on any single product from the list mentioned in the first paragraph will be futile. The CM’s favorite tool may not work on all or even most of the hosts, if the operating systems of those hosts lack the software stack or system interfaces needed to execute the automated requests. Worse, the desired tool may require an upgrade or installation of software that may conflict with or even break libraries or applications already installed.
Any enterprise that wishes to implement a comprehensive information security overhaul of its systems, faces a daunting challenge in such “feudal”, under-managed or unmanaged environments. Configuration management changes must be applied in many different ways: Ansible playbooks, Puppet manifests, shell scripts, even manually executed steps. Having to implement new standard security remediations or add the new configuration options to multiple provisioning methods is not only a costly proposition with no end date in sight, but it also multiplies the risk of error and inaccuracy. Any change to the CM requirements compounds the changes needed for the different implementation methods.
Configuration Management With Packages
However, an enterprise might be able to implement such an initiative utilizing automated components that all CM tools share in common, such as the software package. It is true that this does not completely eliminate variation of how a new configuration management problem is implemented across a variety of different hosts. But providing a configuration management software package does rely on what is a lowest common denominator component of all operating systems, the software installer. And any configuration management tool worth its — salt, must have some kind of package component.
Using the Configuration Management Package
To better illustrate how a configuration package would be used by a CM tool, consider the following Ansible task snippet.
- package:
name : cm-ntp
state: present
Or alternatively, this Puppet class code:class cm_ntp {
package { cm-ntp: ensure => latest }
}
In both examples above, the CM tool applies the necessary configuration management changes by simply installing the cm-ntp package, which itself would configure the /etc./ntp.conf file per the standard enterprise requirement and, if appropriate, install the ntp package, and restart the ntp service. The cm-ntp packages would be built for specific OS targets. For example, cm-ntp-1.0.rpm would be built for RedHat, CentOS and other RPM-based systems, while cm-ntp_1.0.deb would be built for Ubuntu and other Debian-based systems. The package cm-ntp-1.0.txz would be installed on FreeBSD hosts, etc.
And of course, one can choose not to use the config management tool at all and install the package as one would any other package at the command-line.
sudo apt-get install -y cm-ntp
Configuration Package Details
While use of software management packages in CM tools and as standalone solutions are stupid simple, there is a bit more required (though not much) in the package itself. Though, in terms what is actually needed in the package itself, it is still far simpler than a typical software package. It consists of the following items:
Configuration script: this should be written in what is considered a common-denominator interpreter language like sh, bash, perl or python.
Package Build Specs: Includes all the information needed to build and install this package for targeted platforms. Key for automation are linking the configuration script to the package post-install process and any packages that should be automatically installed if not present (like ntp if the package is configuring ntp). Though the names of these dependencies may differ (or even be unnecessary) on different systems.
Each package type requires its own build tools. Wherever the packages are built should have the requisite tools installed. For building and testing Linux packages on multiple distributions and versions, I would suggest utilizing Docker images built with the requisite build toolchain and environments matching their production target environments as closely as possible. Building and testing with containers provide convenient isolation for building and testing package installation. You can utilize mounted volumes to store the artifacts built in the container. And every test of a package installation in a container is a test in a re-initialized environment, with very quick startup and tear-down times. Also, to simplify building the package itself, I would recommend the FPM (https://github.com/jordansissel/fpm ) tool. FPM is an open source tool that allows you to build a variety of software package types, including RPMs, DEBs, Ruby Gems and even tar files. It also allows you to convert one package type to another.
Conclusion
Even if selecting the tool you want for a configuration management effort is not possible, it is still possible for you to implement a configuration management approach that leverages a capability all host operating systems must possess: the package installer. By bundling the configuration management details and tasks in software packages, you provide configuration management by install to anyone or anything that knows how to install a package, be it the system administrator, a Puppet manifest or Ansible playbook. In that case, tool selection is not important. You have provided a configuration management component that will work with any tool.
For Further Reading:
Debian Package Specs- https://www.debian.org/doc/debian-policy/
Building RPM Packages- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/rpm_packaging_guide/index
Building Packages for FreeBSD-https://www.freebsd.org/doc/handbook/pkgng-intro.html
FPM- https://fpm.readthedocs.io/en/latest/
Docker for Development- https://docs.docker.com/develop/