This is the second part of the series discussing AWS OpsWorks. In the first part, we looked at OpsWorks in general and we deployed a photo sharing application based on Rails.

VMware Training – Resources (Intense)

In the second part we will discuss:

  • High availability
  • Scaling the resources
  • Monitoring the resources

High availability is achieved by using a load balancer. Once the ELB is created, the ELB URL is used to access the application.

You should already know how to create an ELB. If not, go through this article: How to deploy high availability and load balancing in Amazon AWS. Everything is the same, except for a few minor things like “Ping Path” :

From the list of instances used for the load balancer, we will use the instance for the “rails-app1” :

Once the ELB is working, go to AWS OpsWorks and select “Layers” from the left menu. From the “Rails App Server” layer, click on “Network”:

Then click on “Add an ELB” and select the ELB that you created. When you are done, click on “Save”.

The ELB will be created and you can now access the application by using the DNS name that ELB provides:

So far, we have an ELB with only one instance which doesn’t provide too much resiliency. Let’s add another instance to the ELB in another Availability Zone.

Select “Instances” and then from the “Rails App Server” click on “+ Instance” and once you’ve chosen another AZ, click on “Add Instance”:

The new instance will be stopped so click on “start” to power it up.

Now, if I click on the URL provided by the ELB, I would get the same output as clicking on the URL from a particular Rails app server:

We are now done with high availability. It’s time to configure the application to be ready to scale in case of high traffic. We have two options: “Time-based” and “Load-based”.

From the left menu of your OpsWorks stack, from under “Instances”, select “Time-based”:

We will see how it’s done for one of the instances. Click on “Add a time-based instance” and then click on “Add Instance”:

Then click on the square below the green arrow to start the instance at the current time or select additional squares to increase the number of hours that you want the instance to run every day. In this case, I want the instance to run every day between 15:00 and 20:00 UTC:

Because I selected the current time, the instance is started as you can see in the “Instances” menu:

The same thing should be done for MySQL as well.

Let’s move further to “Load-based” scale. Select “Load-based” from the “Instances” menu and then click on “Add a load-based instance”. Check the configuration and then click on “Add Instance”:

Click on “edit” to see on what parameters another instance was started and click on “Show” to see the instances:

As you can see, the instance is stopped because the load of the current instances is not at 80%. Also, the new instance is created but it’s stopped:

Now that we’re finished with configuration, it’s time to monitor the instances. Select “Monitoring” from the left menu:

There are different metrics that are monitored. These metrics track CPU, memory, load and the number of processes.

Let’s view the “Rails App Server” layer by clicking on it. You will see the metrics for each individual instance:

To see a specific instance, click on it. I changed the refresh interval to 1 hour (top right) and used the first instance:

The last thing that we should do is find out where MySQL is keeping all the data, in this case the photos that we uploaded.

The volume used by MySQL is an EBS which means that it’s persistent and the data will remain on it even if the MySQL instance stops.

You can check this by using the “Resources” button from the OpsWorks stack menu:

As you can see, you have access to Elastic IPs and RDS as well.

In case you don’t need the stack anymore, you first need to stop the instances and delete them. You will also need to delete the app. Once all this is done, you can delete the OpsWorks Stack.

We reached the end of the tutorial. In this tutorial, we created an ELB for high availability, played with scaling options during high usage and monitored the resources.

We have pretty much outlined what you can do with AWS OpsWorks. Actually the challenge here is creating the applications. Importing them in AWS is made easier through AWS OpsWorks by using templates for the most common apps.

I hope you found the series useful and now it should be easier to import applications in AWS.