This article is the first part of a series on AWS OpsWorks, an application management service that provides a simple way to manage stacks and applications. A stack is made up of different resources that are based on different AWS services (i.e. EC2 instances, EBS volumes). OpsWorks supports a standard set of components which have a standard configuration. However, the user is not limited to only these predefined components.

VMware Training – Resources (Intense)

In the first part of the series we will:

  • Discuss the basics of AWS OpsWorks.
  • Create an OpsWorks stack.
  • Deploy a template app.

Let’s discuss the components of the AWS OpsWorks.

The core component is the stack. Its purpose is to act as a container for other AWS resources that have the same purpose. Using a stack, one can manage all the resources as a group.

Another component is the layer, a blueprint that defines how to configure a set of EC2 instances for a common purpose. An instance is assigned to at least one layer and this determines what kind of package is installed on that instance. There are multiple built-in layers.

Recipes and LifeCycle events are other components. Chef recipes are used to handle package installations, app deployments and others. LifeCycle events, Setup, Configure, Deploy, Undeploy and Shutdown are stages that determine automatically what recipes should be run on each instance.

Instances are EC2 instances where the applications are installed.

The app specifies the application type and has the information that is needed to deploy the application from the repository to the instances.

For the purpose of this demonstration, we will install a Rails photo sharing app. As you will see, we will use a lot of predefined components to deploy this app. Going through the tutorial, we will see the logs of the instances and the command for each step at one point.

A setup event is when an instance is launched. It starts the process that installs and configures the instance. After a successful setup, OpsWorks triggers a configure event that checks whether the configuration of the instance is correct or not and if not, adapts it. Another event is deploy. This will start a process on the instance that retrieves the source code of github and configures the Rails environment and web server that will be used by the app.

Let’s take a look at how you can deploy an application using AWS OpsWorks.

From the AWS Console Management, under the “Deployment & Management” section, choose “OpsWorks”. Then click on “Add Your First Stack”:

On the next step, fill in the name of the stack. You can leave everything else at default. Once you are done, click on “Add Stack”:

After the stack is created, you can proceed further with any of the following: add a layer, add an application or add an instance.

Let’s go ahead and create the first layer, by clicking on “Add a layer”:

On the “Layer Type” choose “Rails App Server” and everything else can be left at default. Click on “Add Layer” once you are done.

You will be redirected to the list of layers that are created. Next we add an instance to this layer. Click on “Add instance” to be redirected to the instance properties:

Fill in a name for your instance and you can leave the other properties as they are already predefined by AWS and click on “Add Instance”:

You will be redirected to the list of instances. As you can see, you have one instance which is currently stopped. Click on the “start” button corresponding to the instance that you just created:

The instance will move to different states until it reaches the online mode.

It’s time to add another layer for MySQL. From the left menu, click on “Layers” and then on the “+ Layer” button. On “Layer Type” select “MySQL” and then choose the root password for MqSQL root account. I chose “password”. Then you can go ahead and click on “Add Layer”:

As before, add an instance to this newly added layer:

Before you can click on “Add Instance”, you need to specify a hostname for this instance:

It will take a while before the instances become online (around 5-7 minutes):

You can see these two as EC2 instances in the EC2 Dashboard:

Each instance has its own properties. You can check them by clicking on their hostnames from “Instances” menu. This is for the “rails-app1” instance:

“Public DNS” is interesting for us as it will be the link used to access the application later. Also you have the states from the creation and configuration of the instance.

This is for the “db_master1” instance:

It’s time to add the application. From the left menu, choose “Apps” and then click on “Add an app”:

Fill in the name of the app (photo_app in this example), then fill in the details about the application source. Use “Git” as repository type and http://github.com/awslabs/opsworks-demo-rails-photo-share-app.git as URL. On the “Branch/Revision” put “version3”. Then click on “Add App”.

Once you create the app, you need to deploy it by clicking on the “deploy” button:

You will be redirected to the app deploying page, where you will need to choose “Yes” for the “Migrate database” option. The rest can remain the same:

After a couple of minutes, the app will be deployed as you can see below:

Remember what we mentioned before about the public DNS of the app rail instance. After the app was deployed, you can click on the link and a new tab will be opened with your application. Upload a new photo to confirm that the application is working:

And it’s working:

We have reached the end of the first part of the series. You now know what AWS OpsWorks is and how you can deploy stacks, layers, instances and apps. A practical example of deploying a photo share application was shown as well.

In the next part we will discuss high availability, scaling and monitoring of AWS OpsWorks.

References: