Before we get started, here are a couple of loose concepts:
-
Launch Configurations are a blueprint for how you want to make your instances. This means that you configure it in the same way that you would configure an EC2 instance, with the difference that you're not actually making one - you're making a plan for your instance.
-
Autoscaling Groups dictate how many instances you want to run. It has many mechanisms for doing so - via manual intervention or system checks, but combined with Launch Configurations, you can automate the process of making instances.
Now that's out of the way, let's get started!
In this practical session, we will:
-
Create a Launch Configuration
-
Specify UserData as we did with EC2 earlier
-
Create an Autoscaling Group
-
Configure Autoscaling group so it attaches instances to the ELB
-
Test scaling up or down
Go to Services > EC2, then look for Launch Configurations on the left-hand side. Click on Create Launch Configuration
We will configure your Launch Configuration in the same way we configure your instance - with the following parameters:
- AMI: Amazon Linux AMI
- Instance Type: t2.micro
We'll then set your Launch Configuration details. Name your Launch Config myname-launchconfig.
Note that this IAM role only allows read-only access to the contents of the S3 bucket you've placed your Wordpress package in - and nothing else.
In the same panel, click on Advanced Details. In the User Data field, paste the following in:
#!/bin/bash
yum install -y mysql php php-mysql httpd
aws s3 cp s3://devopsrep-training/firstname.lastname-wordpress.tgz /var/www/wordpress.tgz --no-sign-request
tar xvfz /var/www/wordpress.tgz -C /var/www/html/
chown -R apache /var/www/html
service httpd start
Make sure you change firstname.lastname-wordpress.tgz to your name, or the filename of the Wordpress package you sent over. And change the S3 bucket name to your specific account.
In the same panel, select Do not assign public IP. This is an important security measure, and separates the instances from the public web - all interaction is via your Load Balancer.
Go to the next page afterwards.
We don't need to modify the storage, so we'll leave everything in Add Storage as default for now.
We'll do the same thing that we did with your previous EC2 instance. In Protocol, select HTTP - then set Source to "Custom IP". If you type out the name of the Load Balancer you created earlier, it should show up on the list.
The good thing about this is that for any instances we're creating, we're only ever expecting HTTP traffic only from your Load Balancer. This is a good thing.
We'll finish up with a review of your Launch Configuration. Check that everything is valid, then click on Create Launch Configuration
As with creating EC2 instances, this will ask you to specify a Key Pair. Specify the one you created earlier.
Once you click Create Launch Configuration, you should see another button called Create an Autoscaling Group using this Launch Configuration. Click on it.
In the next panel, specify the GroupPame as myname-asg. Set Group Size to 2 instances.
For this exercise, we'll use the VPC marked default. If you click on the Subnet input box, you should be given two to three subnets to choose from. Select all of them as destinations.
Subnets essentially set which Availability Zones to deply your instances under. Think of Availability Zones as datacenters - separate locations in Sydney where your instance will live. You'll want a good spread - this protects your service from outages if say, a datacenter in one Sydney location goes down.
If you click on Advanced Details under the same pane, you should see a tickbox called Load Balancing. This allows you to register the server as live and attaches it to the Load Balancer you created earlier.
An additional set of options should appear. If you click on the input box for Classic Load Balancers, you should be able to select the Load Balancer you created earlier.
We're not going to be playing with Scaling Policies for the time being - so choose Keep this group at its initial size. Just keep in mind that you can use policies to watch for the CPU or memory use of your instances - so for example, if the CPU ever goes over 70% usage, you can choose to add more instances automatically.
We'll choose not to send notifications at this time. Think of this as a way of notifying someone if an event occurs - if say, an instance is launched or deleted.
As with anything that we do, it's iportant to tag our to-be-created instances as soon as they're created. Set a Key of Name, and set the Value to your name.
You should be met with a section where you can review the changes that have occurred. Click Create Auto Scaling Group once you're ready, and it should kick things off.
Now, everything should be ready! We have our blueprint for creating instances, and we have a count of instances to create, so let's see if it's working!
Go to Services > EC2 > Load Balancers. Select the Load Balancer you created previously (myname-elb), then look for the description.
Copy the DNS name (similar to below), and paste it on another tab. You're effectively looking at any of your four instances.
Go to Services > EC2 > Instances. In the search box above, you should be able to type your name - allowing you to search any instances you tagged with your name.
For all of your four instances, Right-Click > Instance State > Terminate.
Check the browser tab where you pasted your Load Balancer's DNS name. It should be return with a problem shortly.
In the AWS console, check under Services > EC2 > Instances every minute or so. What you should see is that eventually, new instances with your name should be created.
Now that we know that your instances are getting automatically replaced, we can see what happens when we change the number of instances in your Autoscaling Group.
Go to Services > EC2 > Autoscaling Group. Look for the Autoscaling Group you created.
Once you highlight the Autoscaling Group you created, go to the bottom panel and click on Edit. Set your Desired Instances to 3 and your Max Instances to 3. Click on Save.
In the AWS console, check under Services > EC2 > Instances every minute or so. What you should see is that eventually, new instances with your name should be created.
Congratulations! You have an automated scaling service!
Now that you've done everything to make a self-healing scaling group, it's time for you to deploy it all as code. Infrastructure-as-code is an important idea within DevOps - this makes sure that your infrastructure is repeatable, and is easy to collaborate on.
Download the cloudformation template here. You can open it with your text editor (Notepad, or something similar).
What you're going to notice is that everything you've made is basically declared line by line if you scroll down. I know it looks intimidating, but don't worry! This is just a declaration of what things you want build.
Go to Services > Cloudformation. Click on Create Stack.
This will point you to a page where you can upload your template file. Click on Next.
Set the DevopsRepresentUser parameter. Use your firstname.lastname format for this.
Change WordpressS3Bucket to the name of your S3 bucket name - for example devopsrep-training-2 or devopsrep-training-3 depending on which account you were setup in.
Click through the rest of the dialogs until you get to the Review section. On the text box at the bottom that says "I acknowledge that AWS CloudFormation might create IAM resources", tick the boxes.
Click on Create.
Go to Services > Cloudformation and look for the stack name you set earlier. On the dialog box at the bottom, click on Events. Refresh it every now and then - and watch as your environment gets created!
Congratulations! Now you've deployed things with code!