Real world Ubuntu example

The purpose of this page is to work through a real-world example that touches on different cloud and Linux technologies.

Start with: Official Ubuntu 14.04 AMI

Complaints:

• on first boot, apt is not updated or upgraded or dist-upgraded
• /etc/hosts is not managed (try: sudo true)

Package updates

AMIs become stale moments after they are created. At the very least, you will want to make sure security updates are applied before any machine goes into production. This is not a big problem, and it is solved in many ways:

Scripted on first boot

There are many ways to script a freshly booted AMI:

• cloud-init
• aws cli
• chef
• etc

This works but it means that package upgrades take longer over time as the AMI gets stale.

New AMI

1. boot the AMI
2. update, upgrade, dist-upgrade
3. save the AMI
4. specify the new AMI for future instances

You can do this manually or use Packer.

Both

Let's use Packer to both update the AMI, and make the AMI tell the new instance to update its packages on first boot. As above, run update upgrade dist-upgrade but include an edit to /etc/cloud/cloud.cfg to also perform this on first boot.

/etc/hosts

If a machine's hostname is not present in /etc/hosts, then some system utilities will complain or even misbehave (block for long timeouts, or worse). The default Ubuntu 14.04 AMI does not automatically manage /etc/hosts for the user, expecting the user to make manual edits to match the expected environment: sudo true complains, if not on first boot then at least after a reboot.

We want cloud-init to add an entry for 127.0.1.1 with the machine's hostname to /etc/hosts. This is accomplished by setting manage_etc_hosts: true at the toplevel in /etc/cloud/cloud.cfg. Of course, we need to capture a new AMI with this configuration.

Open Questions

• How should Packer perform the edits to /etc/cloud/cloud.cfg?
• and edits generally, sed?
• Or always own the entire file?