-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
)
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:
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.
- boot the AMI
- update, upgrade, dist-upgrade
- save the AMI
- specify the new AMI for future instances
You can do this manually or use Packer.
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.
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.
- How should Packer perform the edits to
/etc/cloud/cloud.cfg
? - and edits generally,
sed
? - Always own the entire file?