Menu
Puppet on AWS
Quick Start Reference Deployment Guide

Step 3. Configure Puppet Agents

You can follow this instructions in this section to test your Puppet setup on AWS. We’ll take a look at the module manifests for the Puppet agents, apply the configurations, and verify that the configurations were applied successfully.

Review Modules and Manifests

There are a number of ways to apply configurations to your agent nodes (see the Puppet Labs documentation). This Quick Start uses modules for each Linux and Windows node, and downloads these modules from Amazon S3 to the master during the bootstrapping phase.

Puppet programs are called manifests, which are developed using Puppet code. (For information about the Puppet language, see the Puppet Labs documentation.) The main manifest is called site.pp and is located on the master in the manifests folder. Figure 5 shows the site.pp manifest used by the master in this Quick Start.


                    The main manifest

Figure 5: The main manifest

This manifest includes three node declarations:

  • Line 1 – Defines a node block that can be applied by default to any system. We’re not performing any common configurations, so there’s no code within the curly braces.

  • Line 3 – Defines a node block for an agent named linuxagent.example.com. This is the Ubuntu agent launched by the Quick Start. Instead of placing resource definitions in this node block, we’re referencing a class from a module called lampserver. Using classes is a great way to reduce code duplication. In this case, when the Linux agent applies its configuration, it will use the code from the lampserver class to define the state of the system.

  • Line 7 – Defines a node block for an agent named windowsagent.example.com. This is the Windows Server 2012 R2 agent launched by the Quick Start. Instead of placing resource definitions in this node block, we’re referencing a class from a module called iisserver. When the Windows agent applies its configuration, it will use the code from the iisserver class to define the state of the system.

Next, let’s look at the lampserver and iisserver classes to see what they do.

The lampserver class is defined in a module called lampserver. The manifest file for the module is named init.pp and is located in /etc/puppet/modules/lampserver/manifests on the master.


                    The lampserver Class

Figure 6: The lampserver class

Note the following about the lampserver code shown in Figure 6:

  • Line 1 – This is the class definition for lampserver, which is referenced in our main manifest file.

  • Line 2 – The exec keyword defines a resource declaration. You use resources to describe the desired state of the system. Here we’re using the exec resource to execute the apt-update command on the node.

  • Line 6 – The package resource is used to install Apache 2 on the node. Notice that the require statement ensures that apt-update has already been run before this resource can be installed.

  • Line 11 – The service resource ensures that the Apache 2 service is running.

  • Line 15 – The package resource ensures that the MySQL server is installed, as long as apt-update has been executed successfully.

  • Line 20 – The service resource ensures that MySQL is running.

  • Line 24 – The package resource ensures that PHP 5 is installed, as long as apt-update has been executed successfully.

  • Line 29 – The file resource ensures that a new file called info.php is created in the default apache root directory. This requires Apache 2 to be installed. PHP code is added to the content of the file to provide an informational page about the web server when the user visits the site in a web browser.

The iisserver class is defined in a module called iisserver. The manifest file for the module is named init.pp and is located in /etc/puppet/modules/iisserver/manifests on the master.


                    The iisserver class

Figure 7: The iisserver class

Note the following about the iisserver code shown in Figure 7:

  • Line 1 – This is the class definition for iisserver, which is referenced in our main manifest file.

  • Line 15 – The windowsfeature resource leverages Windows PowerShell to ensure that all the required components for IIS and ASP.NET are installed.

  • Line 19 – The windowsfeature resource installs the management tools for IIS administration.

  • Line 25 – The file resource ensures that an informational ASP.NET web page called info.aspx is present in the web server root directory. The content of this web page is truncated in Figure 7 because of space constraints, but it contains a single page directive that provides information about the server, just like info.php on the Linux node.

In addition to creating your own modules, you can use manifests directly, or you can leverage pre-existing modules from the Puppet Forge. For details on writing modules and manifests, see Module Fundamentals and the training classes on the Puppet Labs website.

Connect to Puppet Agents

Now that you understand what the sample modules are intended to do, you’re ready to connect to your agents remotely.

Linux Agent

You’ll need to use SSH to connect to your Linux agent from outside the VPC. In the Amazon EC2 console, select the EC2 instance tagged LinuxAgent, as shown in Figure 8.


                        Selecting the LinuxAgent instance

Figure 8: Selecting the LinuxAgent instance

Retrieve the public DNS name for LinuxAgent, and follow the instructions in the Amazon EC2 User Guide for Linux Instances to connect your SSH client to the instance. You’ll need to have your key pair available to establish a remote SSH connection.

Windows Agent

You can use RDP to connect to the Windows agent over the Internet. In the Amazon EC2 console, select the EC2 instance tagged WindowsAgent, as shown in Figure 9.


                        Selecting the WindowsxAgent instance

Figure 9: Selecting the WindowsAgent instance

Retrieve the public DNS name for WindowsAgent, and follow the instructions in the Amazon EC2 User Guide for Microsoft Windows Instances to get connected. You’ll need to have your key pair available to decrypt the Windows administrator password and establish a remote connection.

Apply Configurations

In this section, you’ll apply node configurations and verify that everything was configured successfully.

Linux Agent

Once you’ve connected to your Linux agent via SSH, run the following command to apply the configuration in the lampserver module:

Copy
sudo puppet agent --test

You should see output similar to Figure 10, indicating that the configuration was applied successfully.


                        Linux Puppet agent output

Figure 10: Linux Puppet agent output

Next, open up a web browser and navigate to the info.php page. You’ll need to use the public DNS name of the LinuxAgent EC2 instance—for example, http://<public DNS name>/info.php.


                        Testing the Apache web server

Figure 11: Testing the Apache web server

You should see a PHP version page similar to the one shown in Figure 11. This indicates that you’ve successfully applied the configuration to your Linux agent.

Windows Agent

Once you’ve connected to your Windows agent via RDP, find the Start Command Prompt with Puppet shortcut in the Start screen. Open the context (right-click) menu for the shortcut, and then choose Run as administrator. Run the following command to apply the configuration in the iisserver module.

Copy
puppet_interactive.bat

You should see output similar to Figure 12, indicating that the configuration was applied successfully.


                        Windows Puppet agent output

Figure 12: Windows Puppet agent output

Finally, open up a web browser and navigate to the info.aspx page. You’ll need to use the public DNS name of the WindowsAgent EC2 instance—for example, http://<public DNS name>/info.aspx.


                        Testing the IIS web server

Figure 13: Testing the IIS web server

You should see an IIS version page similar to the one shown in Figure 13. This indicates that you’ve successfully applied the configuration to your Windows agent.