In this video, Jeff Winesett demonstrates how to launch an EC2 instance using cloud-int user data to bootstrap the instance as a LAMP stack server.
- [Instructor] With a key pair created and security groups in place, I can launch an EC2 instance. So from the console, I'll look in, navigate to EC2, and click Launch Instance. The first thing it's asking me to choose is which AMI I want to use. For this demo, I'm gonna use one of the quick start ones which are prepackaged by Amazon, and I'm gonna go with Amazon Linux. The next option I have to make is to choose my instance size.
In this case, I'm gonna stick with the default choice which is a t2 micro and it's available in the free tier. Amazon gives a few resources for free when you first sign up and I'll take advantage of that, so I'll go down here and Configure Instance Details. Now here's a lot of details that we can set. We can launch multiple instances at once, we can request different Purchasing options, if I had a custom VPC setup, I could choose something other than the default VPC, which I don't, so I'll just stick with default.
The Subnet, it tells me the default is no preference, which is usually fine, in this case, I'm gonna be setting up a load balancer to balance between two availability zones, so I actually want to make sure that this instance gets launched into an availability zone that I'll be choosing for the load balancer. So let me just make the explicit choice of zone a. The rest of these defaults are for the most part, just fine, you can always hover over the tool tips to get more information about each one. Let me scroll down here a little bit though 'cause I do want to show something down here in the Advanced Details.
Here is where I can supply the user data. I'm going to take advantage of this user data and demonstrate cloud-init to bootstrap the instance by setting up the initial configuration needed for a LAMP stack server, that is a Linux, Apache, MySQL, and PHP server. This way, as soon as the instance launches, it will already be configured as a web server. So cloud-init here will execute Bash scripts on start up and I can add Bash commands directly into this user data. Anything that follows the shebang symbol and then /bin/bash, will be executed as a Bash script.
Okay, let me demonstrate. I have this Bash script, and it's available in the exercise file as user-data.txt, and I can paste in as text, the commands that I want to run. Anything that follows this symbol, followed by /bin/bash -ex will run as a Bash script. Basically, these few lines of Bash commands are updating the yum package manager to ensure we have the latest options, using the convenient groupinstall option to install the Apache Web Server, PHP, and MySQL, starting Apache Web Server and ensuring it autostarts upon server reboot, and then changing the config to allow the EC2 user to manipulate files in the web root directory by adding www group, and giving that group ownership of the var www directory, and then adding the EC2 user to that group.
Any members of this www group will then be able to add, delete, and modify files for the web server, and that'll make things easier when we ssh into this instance and add a couple files for our web application. Great, with this in place, I can go on to adding storage. Here is where I can add additional storage if needed. I don't need any additional storage right now, so I'm gonna move on to add tags. I'm gonna add a tag and I'm gonna give it a name, and I'm gonna call this web-server, web-server-1, it's the first one we're creating.
I'm gonna add another tag here and I'm gonna give it an environment name, env, stands for environment, and this is a test environment, so I'll call it test. I'll add another tag here for the cost-center. Maybe I want to ensure that the marketing department is going to be paying for this particular resource. There are many things that can be done with tags to help manage resources, and it's a good idea to take a little time to come up with some conventions and consistently use this tagging feature.
Next, I can choose a security group. Now I've already gone ahead and created a security group for the web-tier, this particular instance is gonna be launched as a web server, so it makes sense for me to choose that web-tier security group that we already have setup with the rules needed for our application. The next step is to Review and Launch, and now I'm met with a warning that's just telling me that the instance requires port 22 to be open if I'm gonna ssh into it. I can go ahead and Continue if want.
In this case, I'm gonna go ahead and Continue, I realize that port 22 isn't open, and I'm gonna move forward anyway. We get a final step here that we can review the details that we've made, they're all looking pretty good, and finally I Launch the instance. The last thing that I need to do is choose the key pair that I want to be associated with this instance. In this case, I've already created an existing key pair, so I'm going to use that one, test-3-17. I'll acknowledge that I do have access to this key pair, and I'll Launch the instance.
Great, now it tells me that my instances are launching, it gives me a little bit of launch status, I can view the launch.log if I want, and I can go directly to the instance that's been created with this Instance ID. If I go here, I see more information about the instance that's launching. I can initially see that in the Status Checks, they're initializing, the instance is running, but it still needs to go through some Status Checks before it's fully available for us to use. While we're waiting, we can show some of the information that's down below here.
The Description gives all of this great information about the instance that's being created. Things like the Instance ID, the Instance type, the Security group that I associated with it, the Key pair name that I associated with it as well. I can also take a look at the Status Checks to see that it's initializing both the system status checks and the instance status checks, so we'll need to wait for that. There's a Monitoring tab that gives us some insight's into some of the metrics on the instance, and then I can see the Tags that I setup, the name, the env, the cost-center.
Launching an instance can take a few minutes, so we'll need to wait for all of the system checks to pass before we can access the instance. After a little time, our Status Checks have passed. We can also check the tags, system status checks passed, instance status checks passed. This means that our instance is available to be accessed. Because I took advantage of the cloud-init, and I added Bash commands to add user data to configure this instance as an Apache Web Server, I expect to see the default Apache test page when attempting to access the instance via HTTP.
I'm gonna try to do that, and because this instance was launched into a public Subnet of the default VPC, it has an associated DNS endpoint. I can grab that right here, copy, go into a new tab, paste that in, and see if I can hit the instance. Okay, that didn't work, and I think I know why. I associated the web-tier security group with this instance upon launch, and if you recall, the web-tier security group only allows HTTP on port 80 in from the load balancer, not from the public Internet, so in this case, I would expect this to fail.
It does sort of tell me that the security rules are in place and working. So the next step is what I need to do is get this instance behind a load balancer. So in the next video, we're gonna create a load balancer and put this instance behind it.
- Benefits of cloud services
- Making architectures scalable
- Examining cloud constraints
- Virtual servers, EC2, and Elastic IP
- Using the Amazon machine image
- Elastic load balancing
- Using CloudWatch for monitoring
- Security Models
- Elastic block storage
- S3, CloudFront, and Elastic Beanstalk
- Handling queues, workflows, and notifications
- Caching options and services
- Identity and access management
- Creating a custom server image
- Application deployment strategies
- Serverless architectures