Learn about an Amazon Machine Image (AMI), and learn about what is possible in terms of bootstrapping on launch.
- [Narrator] Amazon Machine Images, or AMI's are a foundational component to understand when designing highly available systems. AMI's are the templates from which EC2 instances can be launched. The minute an AMI is built, the software it contains starts to go stale. This applies regardless of whether you build your own AMI's, source them directly from AWS or get something from the AWS marketplace. You certainly don't want to launch production instances with old software. To address this challenge, AWS provides the ability to inject instructions into the AMI on launch, before the instance is available for use.
You can provide input directly via the user data field in the console or as a file. If you are using Amazon Linux, AWS lets you pass directives via the cloud-init package. If you are using Windows, you can specify PowerShell commands. You are only limited by your imagination. Anything you can script without user interaction, you can accomplish on start-up. You may want to apply the latest OS patches or download the latest version of your software from a source code repository like GitHub. On Linux, keep in mind that user data scripts run as the root user.
If there are processes you want to start as the non-root user, you'll have to account for that in your script. Finally, you need to remember that user data scripts are only applied the very first time the instance is booted. If there are processes you want to start when an instance is re-booted, user data is not the place to add these instructions. The ability to take a known, good image and automate changes on Startup is a key underpinning of highly available systems. To explore how this works, I'm going to fire up a couple of machines, using the AWS command line interface, or CLI.
The command I'm going to use is the AWS EC2 run-instances command. While it is a powerful command, with many available parameters, I'm going to use a minimal subset of them. The first parameter I'm going to pass in is the --image-id. And --image-id is the internal ID, uniquely identifying a specific AMI. The second parameter I'm going to use is --count. - -Count specifies the number of instances I want to start. The third parameter is the -- instance-type. This lets me specify how powerful the instance will be in terms of compute, memory and network.
The fourth parameter I'm going to use is --key-name. - -Key-name indicates the key pair that I'm going to use when launching the instance. This is the key pair I will use when I connect to the instances. The fifth parameter is the --subnet-id. Here, I'll specify the unique ID of the subnet into which I want an instance launched. The sixth parameter is --security-group-ids. Capable of taking multiple values, this allows me to specify the unique ID of the security groups I want to attach to this new EC2 instance. The seventh parameter is --user-data.
Finally, here is where I can specify the commands I want to run on boot. The eighth parameter I'll be using is --profile. An optional parameter, --profile is what lets me use named profiles when using the CLI.
This course is also part of a series designed to help you prepare for the AWS Certified SysOps Administrator – Associate certification exam.
- What is high availability?
- Designing for failure
- Exploring Route 53
- Working with machine images
- Setting up load balancing
- Creating groups
- Working with auto scaling
- Improving relational database availability
- Setting up an elastic file system