Automate AWS AMIs

Bring Out the DevOps

Earlier, I mentioned that when I was first experimenting with Automation documents, I struggled with the IAM roles (mostly the two IAM entries in Figure 5, it turned out). I went around in circles for a while and ultimately started also adding a SubnetId explicitly when I ran my Automation document because of slightly odd virtual port channel (VPC) errors that seemed intermittent (even though I hadn’t deleted my default VPC, which the docs said caused this error).

Long story cut in half: Declaring the SubnetId is optional, but it meant that all of my VPC errors went away. I mentioned that Automation documents run one per AWS region; well, by stating the SubnetId , you simply choose where to run your Automation document when it executes. Obviously, make sure it exists in that region. The VPC error explanation and the standard sample AWS-UpdateLinuxAmi Automation document can be found online.

To be completely clear, the AWS-UpdateLinuxAmi Automation document on that docs page DOES include the otherwise optional SubnetId change, which means you need to populate run-time parameters with a new value or two:

"SubnetId":{
         "type":"String",
         "description":"(Required) The subnet that the created instance will be placed into."
      },

Just to keep you on your toes, however, to encrypt the AMI, I’ll add a little bit more code to that sample Automation document and look at populating the Subnet ID and other parameters when I run it. Rather than go into massive amounts of detail here, the full Automation document, including the encryption step, can be downloaded.

IAM What IAM

I’ve spent an inordinate amount of time in the IAM section of the AWS console until now, but I’m going to jump back to the good old EC2 section. It struck me initially that the links at the foot of the EC2 navigation pane on the left-hand side of the screen were misplaced, but actually there’s quite a lot in that pane I hadn’t really appreciated before. Spend a moment looking through the sections for your own personal edification.

The first of two steps before everything is up and running is to create the document. In Figure 8, the Documents link is selected. Follow that link and then click another oversized blue Create Document button at the top of the resulting page. Give it a name (e.g., ChrisBinnie-LinuxAMI ) and paste in the JSON with your desired default values for the AWS region. Getting the details correct at this stage will save you a lot of time changing your “default version” settings and editing the original Automation document.

Figure 8: The Automations link is in the EC2 section of the AWS console.

Take it slowly at this stage, and it will make much more sense when you execute the Automation document in a moment, especially when initially using the GUI and not the CLI. Get used to clicking across the Parameters , Permissions , Contents , and Versions tabs on this page for further enlightenment.

Run for the Hills

Once content with life, the universe, and everything, click on the Automations link (Figure 8) and then the big blue Run automation button. The very latest edit of the Automation document should be your default version (or at least you’ve selected the one you definitely want to run correctly), so it’s easier to follow. I find selecting Owned By Me is the route of least resistance to finding my custom Automation document (Figure 9).

Figure 9: Identify your customized Automation document speedily by choosing Owned By Me.

With one final step, I’m about to pass Go and watch with bated breath as my Automation document runs through its step-by-step execution. Remember to look in Table 1 if you’ve forgotten what should be achieved on a per-step basis.

This final step from the AWS GUI console is to look over the variables (Figure 10). Remember the defaults that were set up when I created the Automation document? They should display now.

Figure 10: Some of the input needed by the Automation document is shown on the right. I’ve deleted some entries for privacy.

Clearly the parameters noted as “(Required)” need to be populated with sensible values. The ami- entry in the top parameter should obviously say something, as should the InstanceRole name, if you happened to change the name; make sure the region and other values are correct, too.

After hitting Run , you can look at instances running in the EC2 section of the AWS console and flick back to the step-by-step progress on the Automations page. (Simply select the latest Execution ID to monitor progress.)