This project is a script/framework to create Amazon Machine Images (images that act as ‘blueprints,’ or a sort of ‘server factory,’ for Amazon’s EC2 service) of Arch Linux, a particularly elegant and powerful Linux distribution.
Arch Linux, a superlatively clean and elegant distro, generally follows ‘the Arch Way,’ a set of four core tenets governing the design of Arch, and its configuration system and package repository:
- Simple: without unnecessary additions, modifications, or complications
- Elegant: combining simplicity, power, effectiveness, a quality of neatness and an ingenious grace of design
- Versatile: capable of doing many things competently; having varied uses or many functions
- Expedient: easy, or quick; convenient
These AMIs are designed to be extremely light, and absolutely ‘Arch-y.’ As an example, the core ‘Nucleus’ AMI contains exactly twenty packages, one of which is the filesystem, and one of which is a licenses packages that I am legally required to distribute. That’s nineteen, or possibly less, pieces of software!
In some cases, one might even say I’ve gone too far. The Nucleus doesn’t even
contain a text editor! However, I am of the opinion that servers, even more
than minimalist desktops (and virtualized servers, like those on EC2, even
moreso than normal servers, as they can be instantiated by other machines and
may possibly never even have a human being
ssh into them, or indeed, touch
them in any way), should have absolutely no bloat, no unneeded software to
configure or daemons that may leave security holes; thus, I’m confident that
here, I’ve taken the right path.
These machines are built to take advantage of Amazon’s infrastructure where possible; in most cases, they will utilize features like your instance’s ‘ephemeral store,’ the EC2 public keys, and the powerful EC2 firewall, to your advantage.
This system is pre-configured to build several different types of AMIs. Each one is heavily based on the previous one, but with more functionality. They range from the exceedingly thin to the exceedingly functional.
The planned types of AMIs are described by this tree:
Nucleus: The thinnest possible system, capable only of booting, accepting SSH connections, and installing more packages. This is where to start if you don’t want any of the functionality provided by the fatter packages, and want to design yourself the lightest possible server image.
Atom: (not yet implemented) The basis of the rest of the system; the
AtomAMIs all have a a few admin amenities (like text editors, a daemon monitoring/management system), as well as instantiation magic left out of the
Web: (not yet implemented)
Ruby: (not yet implemented)
Passenger: (not yet implemented)
git: (not yet implemented)
Bundling: (not yet implemented)
Nucleus AMI does not have the instantiation magic provided
by the rest of the systems; you will have to configure your user accounts,
yourself, from the
root user account, your mirrors will not be ranked at
boot, and so on. Everything is left up to you.
The easiest way to use these AMIs is to instantiate one from the list of AMIs that I (elliottcable) have already built and registered. I won’t keep a list here yet; once I release stable AMIs, I may add them to this README. In the mean time, you can get a complete list of AMIs I have release with the following command:
ec2-describe-images --show-empty-fields \ --owner "316177411691" --executable-by all | less -S
I suggest, however, that, instead of using my AMIs, you simply build your own using this script; in general, you never know what an AMI published by somebody else contains. If you run this script yourself, after reading it, you can have a much more particular understanding of what, exactly, is in the machine that you’re running.
Not that that covers all of your bases; for instance, this script utilizes a ‘bundling host,’ and if that host was compromised, anything could theoretically be injected into your new AMIs… but it’s still generally a more intelligent course of action.
To get more information about building your own AMIs using this system, run
bundle.sh without any arguments:
This system is designed to be extremely flexible; there is really no reason for you to use the pre-built AMIs, or even run the script as-is; you can easily customize the script to build AMIs that exactly match your needs, either by creating new preparation scripts, or re-bundling the AMIs produced by this script. You could even use a combination of both techniques to produce a tree structure of personalized AMIs for various purposes; that aligns quite well with the intended usage scenario of EC2, after all.
bundle.sh script, in this directory, is the core of the system; it
builds and configures bundle host and kernel host machines, and is also
responsible for testing built AMIs against kernels in various availability
After a bundle host is prepared, and the kernel host is done with, execution
is passed (on the bundling host) to preparation scripts (in the
InstanceType/bundle.sh). These are entirely responsible for
actually installing and configuring all software to be packaged into the new
AMI. You can, therefore, write your own such scripts, to set up your AMI
however you desire.
I, personally, don’t generally re-bundle AMIs; I prefer to know exactly what’s going on, which is achieved by building them myself from scratch. However, it’s not a difficult task.
There is plenty of information on re-bundling AMIs in the [EC2 docs]; alestic also has tutorial on the subject. The AMIs created by this project are friendly to re-bundling; however, be aware that you need to clean out some files created, that inform the instance of its state (such as whether or not it has been instantiated yet; this is how these AMIs preform first-boot initialization when instantiated). This is fairly easy, simply run the following command:
rm -f /usr/aws/ec2/.*
This will clear out any files created by the hosts on boot, which will allow your bundled system to be initialized properly every time it is subsequently instantiated.