Pro tip: Create a Puppet agent in AWS EC2

Get the steps for building a Puppet agent machine and starting your web service. Nick Hardiman also explains why this cloud automation work is worth the extra effort in the long run.


This is the last post in a cloud automation series to build a simple web service. This article builds the Puppet agent machine and starts the service, completing the chain of Amazon Web Services (AWS), cloud-init, and Puppet.

This procedure is similar to launching the Puppet master in the last post.

1. Find your p-agent-user-data.yml user data file for the Puppet agent.

2. Edit this file and change the IP address to match your Puppet master.

 - grep puppet /etc/hosts || echo puppet >> /etc/hosts

3. Stick the file contents into a variable.

4. Launch the Puppet master.

aws ec2 run-instances --image-id ami-50b64527 --count 1 --instance-type t1.micro --key-name p-keypair --security-groups p-master-group --user-data "$my_user_data"

5. Check your work.

aws ec2 describe-instances 

6. Wait five minutes for the new machine to get going.

7. Find the SSH host key fingerprint of the Puppet agent.

8. Look around the Puppet agent.

Test your work

You should always test your work. When it comes to building a new system, computers are less predictable than toddlers.

If you are a fan of Deming's PDCA (Plan, Do, Check and Act) cycle, you are about to start the "check" phase.

Check Apache

1. Find the public host name of the Puppet agent. This is another field of the AWS CLI aws ec2 describe-instances command.

2. Copy this name.

3. Open a web browser.

4. Paste it in the address bar. A web page appears (Figure A).

Figure A


Clean up

Don't leave services running on your cloud provider if you can help it. These systems cost money to rent.

Delete the AWS things. You can always re-create them later.

aws ec2 terminate-instances --instance-ids i-7febb93e i-821944c3
aws ec2 delete-security-group --group-name p-master-group
aws ec2 delete-security-group --group-name p-agent-group
aws ec2 delete-key-pair --key-name p-keypair

This seems hard just to fire up a web server

This automation work took a lot longer than the manual build would have done. What was the point of all that extra effort?

Have you ever asked your virtualization team for two new servers and received two slightly different machines? Two sysadmins, manually building two machines to the same specification, always build two different machines. Trying to avoid this manual build problem is like trying to avoid gravity -- it's a fundamental property of the IT world. Later in the operational lifecycle, when one server is acting strangely, support staff will waste time scratching their heads in confusion.

One good reason to go to all this automation trouble, even when the manual build can be done in a fraction of the time, is to get consistent build quality. Once you automate the build of one server, the virtualization team can build many more truly identical machines. You will be able to rely on the build of each server being the same.

You can also scale out more easily -- how many sysadmins would it take for 100 manual builds, or even (if business is good) 1,000? The automation work saves you time here, and it may reduce cost, centralize configuration, and increase productivity.

Where do you go from here?

Learn how to create your own installation packages. Package deployment is a big part of automating your infrastructure. Rolling out an off-the-shelf package from a distributor's repository only gets you part of the way to business value. You know how to get the rest of the way.

Watch the great talk Michael Stahnke, software engineering director at Puppet Labs, gave at PuppetConf 2013: "Getting started with Puppet." Not only will you find out why getting started by automating Puppet is a bad idea, you will also find out why getting started with syslog is a good idea.

If you had to follow this procedure again, what would you do differently? Do you think you can do better?

Sure you can. Get automating and make our cloud world better.

Catch up on previous installments in this cloud series