Recently I explained how to easily set up communication between a Puppet client and master. In this follow up post I’ll outline the steps involved in configuring the Puppet master to control the client machine.
Starting out with Puppet does not have to be a challenging experience. However, if you’re new to Puppet as a configuration management tool, the workflow may appear a bit complex. Understanding the basics of Puppet is key to making it an effective workflow. Let’s take the opportunity to review a setup that was discussed in my previous post. In that post, several servers were configured to communicate with the Puppet master. Here’s some additional steps to now give the administrator complete control through the Puppet master.
- Open /etc/Puppet/manifests/site.pp for writing and paste the code below into it. (And if you’d like you can verify that /etc/Puppet/manifests/site.pp is the main configuration file with the command “Puppet config print manifest.”)
package { ‘cowsay’:
ensure => installed,
}
- Save the file and then go back to the client machine and run “Puppet agent -t.” If that completes without error, then try running the following command.
/usr/games/cowsay hello world
- A talking cow appears on your screen.
You can try adding another entry in site.pp for another package you know isn’t installed on the client. If you wait for at least 30 minutes and then check back on the client machine, you’ll see that the package has been automatically installed.
Most of the time the Puppet master does not act like a ‘master’ but more like a ‘waiter’ and a ‘server.’ It waits for puppet clients to contact it. Every 30 minutes a puppet client will ask the puppet master if there’s anything to do, and the puppet master will respond by serving up instructions and files the client might need in order to carry out those instructions. You can manually force a Puppet client to do this by logging into the machine where it is running and using the “Puppet agent -t” command, but the Puppet master doesn’t initiate contact with the Puppet client and tell it what to do. This would be a “push” from the server. Ansible is a popular CFM that pushes changes out to clients from the master server. The communication path for Puppet always starts with a pull request from the client.
After reviewing the basics of Puppet, there should be a clearer understanding of how the master configuration works and how the client polls for requests. Your initial step in setting up Puppet is establishing the communication link between the master and the client. The next steps will be to configure the Puppet master, establishing all your servers with configured Puppet clients. Note that the Puppet Master did not have to be restarted in order for our configuration changes to be recognized. In most cases you will not need to restart the Puppet master after making changes to the configuration.
This quick setup guide gives you a small sample of what you can do with Puppet. You can build on this experience as you explore other features of Puppet. Besides automatic package installations, you can do things such also manage configurations files, ensure certain services are running or not running, and aid in automatic software deployment. With Puppet, the possibilities are endless.
You have the ability to automate/replicate on multiple servers as a Linux systems administrator with Puppet. You can also download modules created by others at the Puppet Forge, which at the time of this writing has over 4,483 modules available to choose from.
Clearly Puppet has positioned itself as one of the leaders when it comes to automation and the delivery of services. Getting the puppet master and clients setup and running is the first step in making Puppet part of your organization’s infrastructure.
