This chapter will be about getting started with Puppet 3.1. We will begin at the beginning by explaining some background on software configuration management tools, then move on to how to get Puppet running on your system and finally how to get it setup to start working with. At the end of this chapter you should understand why Puppet is around, why you should use it and you should be all setup to do so.
What is software configuration management, and why should you care? Software configuration management (SCM) refers to any strategy for tracking and controlling changes to the configuration of a software system. This includes the most basic style of simply keeping backups of configuration files at every change all the way up to centralized, role-based systems combined with version control systems (VCS) like Git; parallel job execution systems like Mcollective; and in some cases full lifecycle configuration management (CM) systems like The Foreman to track and deploy software configurations and even provision virtual machines.
In many situations, administrators manage their systems by tweaking and changing configurations as needed directly in production, or on a test system before copying into production. Administrators use this approach because it requires no additional infrastructure or procedure: at the very most, they may make a backup copy of files before modifying them.
Manual configuration management has many, many drawbacks. The short list includes:
- A potential for error when the administrator doesn't always make backup files
- Documentation going out of sync with actual system state
- Replicated work with many similar servers
- For that matter, replicating work incorrectly
- Difficulty restoring service in catastrophic failure situations
To deal with some of these issues, some administrators track changes in a VCS such as Git. Polymaths versed in both system administration and programming have developed systems for managing their configurations better. Early attemts included systems such as etckeeper, which simply stores /etc in a Git repository and keeps track of file permissions. Debian still ships etckeeper, although Ubuntu modifies the default configuration to use Bazaar instead of Git.
Simply versioning /etc does not solve many of the problems of configuration management in general. For one thing, /etc only contains configuration files, and not the entire system configuration. Further, many configuration files remaini n a default state after system configuration and are installation-specific, making the full backup of /etc at any given time a poor reflection of specific configuration. Finally, package installation, cron tabs, and other major system changes made after installation fall outside the realm of what tools like etckeeper can manage.
Automated installation provides a more complete solution to the task of configuration management than simply vesioning the /etc directory or other system files. Tools like Anaconda's kickstart and Debian's preseed provide administrators with a means to produce a tailored installation process including predefined system settings and package installations. This solves a number of the above problems:
- Freshly installed systems are consistent, always
- The
kickstartorpreseedprovides a concise explanation of the full system configuration immediately following installation - Many similar servers or repeated installations install almost if not completely unattended
- Administrators can restore backups of data onto a functional base system in the event of catastrophic failure
Unfortunately, automated installation doesn't provide a way to manage configuration throughout a system's lifecycle. Updates and configuration changes still rely on tools like git and etckeeper, as well as manual replication across many nodes when many systems require identical configuration changes. Further, the installation systems do not function as current documentation until someone folds the changes back into the kickstart or preseed files; and sometimes the changes are per-system specific and do not belong in the install automation files.
For enterprise configuration management needs, full SCM systems have arisen. These include tools such as Puppet, Chef, cfengine, Ansible, and so on. Full CM tools such as The Foreman have built on this foundation, using Puppet along with a host of other components to provide complete provisioning, configuration, and monitoring for full lifecycle management. In basic use, system administrators often utilize a VCS with an SCM system to keep a versioned, documented history of configuration changes.
SCM provides solutions to many of the earlier encountered problems, including:
- Documentation: Configuration for each system resides in the SCM, allowing for the easy idenitfication and auditing of configurations, individual configuration components, and baselines.
- Replication: Dister recovery or the creation of similar systems requires little more than the reuse or modification of existing configuration components. The work always remains largely consistent, with comparatively small, highly-visible configuration changes.
- Change management: The use of access controls and a version control system supply a rudimentary change management system.
Complete CM solutions such as The Foreman provide additional benefits, such as:
- Automated provisioning: The CM handles the definition and creation of resources, including virtual machines and in some CM systems documented requests for physical servers.
- Automated installation: The CM will generate automated installation profiles for
kickstart,preseed, or similar systems, automating the installation of the operating system and SCM. - Monitoring: Some CM systems provide a monitoring solution to give greater insight into necessary configuration changes, such as performance tuning, expansion of a cluster, or provisioning new hardware.