There has been a lot of excitement about microservices. So there should be. The serverless computing model is designed from the ground up to be "microservices-first", and help overcomes the hardships they inflict on teams working in traditional computing environments.
I have decided to rebrand to more accurately reflect the needs of organizations looking to develop cloud-native software. DevOps is no longer enough - only a combination of excellence in software engineering as well as infrastructure management can provide the edge needed to succeed.
Are containers the future? Everyone seems to think so. However, their development and popularity mirrors that of another technology that came before, which was eventually used to enable something even greater. Containers too will enable something greater - the serverless model.
I know what you're thinking. "I wish I could create my own AMIs (Amazon Machine Images). Not the traditional way - spawn an EC2 instance, make changes, then hit the EC2 API to use that instance to create a new AMI from it - but actually build a filesystem from scratch in an empty volume, and use that volume to create a bootable AMI."
I mean, who HASN'T thought that before.
On a serious note, there are a few reasons why the traditional process for creating AMIs may not be suitable:
- Shrinking AMI size - since the base AMIs provided by Amazon are 8GB big, the traditional process can only create AMIs of 8GB or larger - you can increase the size of the new AMI, but not shrink it. The problem with large AMIs is that they take a long time to spawn volumes from, and those volumes take a long time to turn into a new AMI.
- Using a new OS or distribution - what if you want to create an AMI for an operating system or Linux distribution that AWS does not provide a base AMI for, then you would have to create a new AMI.
- Fewer filesystem image "layers" - Every AMI can be created from another one, and can itself be used to create other AMIs. However Amazon does not create a brand new image for each one, rather it works out the changes between parent and child, and the child only has the 'changes' from the parent. Eventually, if you want to work out the actual data in your AMI that will become a new volume, you have to trudge your way through all of it's parents for the 'unchanged' bits that any AMI in the chain inherited and did not change. Creating a brand new AMI from an empty volume may be more efficient, but of course it will cost more, as you are no longer paying to store just the changes.
Shrinking an AMI might be a useful exercise for some, but has a few really annoying and obscure steps. One way to do it is described below.
Create a New EC2 Instance, Making Sure It Is Reachable By SSH
Create a new basic EC2 instance based on any Linux distribution you want (like Ubuntu). It will only be used to SSH into and copy files from one place to another.
Make ABSOLUTELY SURE you create it a subnet in the first availability zone, ending in the letter 'a'. Do NOT leave the 'Subnet' option set to 'No preference'. Also make sure you check the 'Auto-Assign Public IP' box. All volumes you create will have to be in the same availability zone, so choosing the first one ending in the letter 'a' makes sure of this.
Ensure you choose a suitable SSH key when asked, so that you can SSH to it. Also, create a new security group (or choose an existing security group) that allows you SSH access to it from your location (it is OK to use 0.0.0.0/0 as the source IP, as this instance will not be around for very long).
Create a New Volume From the AMI You Want To Shrink
We want to create a new volume from which to copy all our files from, so will create it from an existing AMI.
Create a New Empty Volume That Will Become Your New Shrunken AMI
copy Files From the Source Volume to the Target Volume Using the EC2 Instance
Repeat the above steps for the 'target-volume', but this time change Device to /dev/sdg .
Then, SSH into your instance, and mount both volumes:
$ sudo mkdir -p /mnt/source /mnt/target $ sudo mount /dev/xvdf1 /mnt/source $ sudo parted -s -a optimal /dev/xvdg mktable msdos mkpart primary 0% 100% toggle 1 boot # Partition target volume $ sudo mkfs.ext4 /dev/xvdg1 # Make filesystem on target volume ... Creating filesystem with 524032 4k blocks and 131072 inodes Filesystem UUID: 49c66eaa-2def-4689-bf18-4b8426ee6cb6 ... $ sudo e2label /dev/xvdg1 cloudimg-rootfs $ sudo mount /dev/xvdg1 /mnt/target
BE SURE TO TAKE NOTE OF THE FILESYSTEM UUID OF THE NEW PARTITION ON THE TARGET VOLUME, as printed out by mkfs.ext4! It is very important and we will need it later.
Copy Files Across To The New Volume
Copy across all files from the source volume to the target volume. Obviously, the target volume should be of sufficient size to accommodate all the files! If not, you will have to create a new one that does have space.
sudo tar -C /mnt/source -c . | sudo tar -C /mnt/target -xv
Now, we need to change the filesystem UUID in the copied files to the new one. Find the old one by inspecting the old filesystem, and then use sed to change that old one to the new one in /boot/grub/grub.cfg:
$ sudo blkid -s UUID -o value /dev/xvdf1 567ab888-a3b5-43d4-a92a-f594e8653924 # Note we use the new UUID here, as output by mkfs.ext4 above $ sudo sed -i -e 's/567ab888-a3b5-43d4-a92a-f594e8653924/49c66eaa-2def-4689-bf18-4b8426ee6cb6/g' /mnt/target/boot/grub/grub.cfg
Now we run 'grub-install' to install the boot loader on the volume:
$ sudo grub-install --root-directory=/mnt/target /dev/xvdg
Now we should remove the volumes from the instance. First we unmount them:
$ sudo umount /mnt/source /mnt/target
Then we remove them both from the instance from the Volumes page of the AWS console:
Create a New AMI From The Smaller Volume
Create snapshot from the target volume. Select it on the Volumes page, and choose Actions -> Create Snapshot. Enter 'smaller-ami' for Name, and leave Description blank. Click the snapshot ID link that now gets shown.
Once the snapshot finishes creating (the spinner next to it stops spinning), select the snapshot, and choose Actions -> Create Image. Choose 'Hardware-assisted virtualization' for 'Virtualization type', and fill in a name of your choice (such as 'smaller-ami' - we can reuse the name of the snapshot). Leave all other options as the defaults, and click 'Create'. The AMI ID should be displayed, clicking which will take you to the AMI page showing it's creation progress.
Now, if you create a new instance using that AMI, it should boot up start just like a normal instance, but with a smaller virtual disk attached to it by default!
These instructions are quite complex, covering a lot of topics from AWS volume and snapshot management, to Linux partition management, and quite frankly it is best to automate them as they are quite tricky to carry out. But sometimes there really is a need to shrink volumes, and hopefully you will find them helpful if you come across that need.
If you were following along to test the process out, please remember to delete all instances, AMIs, volumes, and snapshots created, as otherwise Amazon will continue to bill you.