Cloud Automated Testing and Monitoring: DevOps for the Enterprise

http://www.cloudypoint.com/cloud-automation/automated-testing-monitoring-devops-enterprise/
Cloud Automated Testing and Monitoring: DevOps for the Enterprise
I'm using some cloud automation tricks. I use cloud-init to create a Puppet master service, and then the Puppet master will create the Apache service.

I put the instructions (the cloud-config data) in these two files.

p-master-user-data.yml - cloud-init information for my Puppet master.
p-agent-user-data.yml - cloud-init information for my Puppet agent.
Ubuntu uses an application called cloud-init to prepare a new cloud machine for use. Cloud-init can do all sorts of clever cloud instance initialization things when you fire up a new EC2 machine. Cloud-init instructions can be written in many formats such as cloud-config data, a shell script, or even python code.

The ephemeral drive /dev/xdb2

If you have started an Ubuntu-based cloud machine, you may have already noticed one of the things that cloud-init does. On the Trusty OS, cloud-init creates a second drive - an ephemeral one - called /dev/xdb2.

Ephemeral means short-lived; in the cloud world, ephemeral means "do not rely on this sticking around." This ephemeral drive and its contents disappear if the machine is stopped. And you ain't getting your stuff back.

Feeding cloud-init instructions to AWS EC2

The aws ec2 run-instances command -- the one that starts a new machine -- has an option called -user-data. If you give this option a bunch of cloud-init instructions, they are copied over to the new machine and carried out by cloud-init.

The cloud-init instructions that set up the Puppet master are whacky-looking YAML code. Every sysadmin since the UNIX epoch understands shell scripts, but few can look at cloud-config data without having palpitations. Here are both versions for installing a web server.