AWS OpsWorks Overview - How Does It Work?

AWS OpsWorks is an implementation of Chef and Puppet. Chef and puppet are automated platforms that allow us to use code to automate the configuration of your servers. If we already use Chef and puppet within our on-premises environments, then OpsWorks can be a great way to reimplement infrastructure within AWS as part of the migration.

OpsWorks Vs CloudFormation Vs Elastic Beanstalk

Imagine a scale from left to right. Technology on the left side offers the most control but also has high admin overhead. Technology at the right is the opposite. It offers less control but also low admin overhead.

On the left, we can include tasks such as manually implementing infrastructure or using scripting. This offers the most control for sure, but that is because we have to do everything ourselves.

On the right, an example might be elastic beanstalk. With elastic beanstalk, we keep some control, but we can just upload the elastic beanstalk application, and the product would host it, creating an environment around our code in order to run that application. We do not have any control over the underlying implementation of the beanstalk.

Now moving slightly from left is cloud formation which is infrastructure as code. We still have to design and define our infrastructure, but cloud formation controls the implementation on our behalf.

In the middle of cloud formation and the elastic beanstalk, we have AWS OpsWorks. This means slightly less control than cloud formation but more control than beanstalk.

How OpsWorks Function

1. Puppet Enterprise
In Puppet mode, we can create an AWS-managed puppet master server. Now puppet is a configuration management system where we define how we want the state of resources to be, but we don't have much control over how that state is achieved.

For example: _If we want a user created or a web server to be installed and running, we simply specify that as our desired state, and puppet handles the exact implementation steps required to make that state happen.
_

2. Chef automate
Chef automate lets us create AWS-managed chef servers which include premium chef features, such as infrastructure automation, autoscaling, etc. If we compare Chef to puppet, puppet needs us to specify our desired state of infrastructure, and puppet will handle the implementation. Chef, on the other hand, is much more like infrastructure as code where we define in detail how to do things using Ruby or any other programming language, and Chef will automate that on your behalf. However, we are not always specifying the desired state as we do with puppet. We often specify a set of steps to make something happen.

3. OpsWorks Stacks
OpsWorks Stacks is an AWS implementation of Chef where we have no servers to manage. So basically, OpsWorks handles everything on our behalf. If we compare OpsWorks Stacks to Chef automate, it needs some manual intervention for layering up the development process, whereas Chef automate works automatically from the start.

So if we need Chef at a basic level with minimal admin overhead and do not need all the features, OpsWorks mode will be your best pick. Generally, we only choose to use one of these three modes when we have a requirement to use puppet or Chef in either of the two modes. We might also choose to use OpsWorks when we have a requirement to automate things, and either we want less admin overhead than cloudformation or more control than Elastic Beanstalk. So, in general, OpsWorks is more suited to infrastructure engineers, and elastic beanstalk is more suited to development teams.

Basic Components of OpsWorks

Stacks - Stacks are the core components of OpsWorks. We can think of stacks as similar to cloud formation stacks. They contain resources that share a similar function. We might have stacks for a single application, certain teams, or even a whole set of infrastructure. So stacks are the basic component of OpsWorks.

Layers – There are layers representing a specific function within a stack. We might have a layer with a load balancer, a layer with a database, or a layer with an EC2 instance that is running our web application. Generally, layers are functions - so if we have web servers and app servers, we generally have one layer for each of these. We can also add a database layer and a load balancer layer to run alongside them.

Recipes and Cookbooks - The reason why layers are functional is that we have Recipes and cookbooks, and both are generally applied to layers. Recipes take care of tasks like installing packages, deploying applications, running scripts, or performing reconfiguration. As they are applied to layers, they will do this against all instances within that layer.

Cookbooks are just a collection of recipes that can be stored on GitHub.

Life Cycle Events

We have five lifecycle events in OpsWorks:

1. Setup
2. Configure
3. Deploy
4. Undeploy
5. Shutdown

Setup

Setup occurs after a started instance has finished booting. When a physical server has loaded an operating system into its main memory and is ready to run applications, this event will be triggered. Behind the scenes, OpsWorks stack runs "setup recipes" that sets the instance up according to which layer the instance is in. Setup event can only be called when the instance is not in the online state. We can also trigger this event manually by using setup command.

For example: _If the instance is a member of .Net Application Server Layer, the setup recipe installs visual studio, .Net SDK and other important prerequisite packages.
_

Configure

This event occurs on all stack instances when one of the following occurs:

1. When the instance enters or leaves the online state
2. When we attach an elastic IP address to an instance or detach elastic IP from an instance
3. When we attach an elastic load balancer to a layer or reattach an elastic load balancer from a layer For example: Suppose that our stack has instances A, B, and C, and we start a new instance, D. After D has finished running its setup recipes, OpsWorks stack triggers the configure event on A, B, C, and D.

If we stop A, OpsWorks stack triggers the configure event on B, C, and D.

OpsWorks stacks respond to the configure event by running each layer's configure recipes, which update the instance's configuration to have a uniform and consistent configuration across all instances. This event is a good time to regenerate configuration files.

Deploy

This event occurs when we run a Deploy command, for example, to deploy an application to a set of application server instances. The instances run recipes that deploy the application and any related files from its repository to the layer's instances.

For example: _For a .Net Application Server instance, the Deploy recipes checks out a specified .Net application and tell kestral server to reload it. We can also run Deploy on other instances so they can, for example, update their configuration to accommodate the newly deployed app. _

Important Note: Setup event includes Deploy; it runs the Deploy recipes after setup is complete. The setup event includes the recipes that are specified to run for the deploy event - but do not actually issue a separate deploy event.

Undeploy

This event occurs when we delete an app or run an Undeploy command to remove an app from a set of application server instances. The specified instances run recipes to remove all application versions and perform any required cleanup.

Shutdown

This event occurs when we direct OpsWorks stack to shut an instance.

For example: When a shutdown event is called, before shutting down the instance, it first shuts down all the associated services, e.g., storage, and then the instance is terminated.

Sample OpsWorks Flow

Suppose we have a new instance, which is being added to a layer running our application servers on EC2 instances. When we add a new server to a layer, the configure event runs, and it runs on all instances within that stack. The configured event could run a series of recipes on all instances in that stack. Why this might be important is to reconfigure all of the instances in that stack to have an awareness of all the others, including the one instance that has recently been added. So the configure lifecycle event is generally executed whenever instances are added or removed from any layers in the stack. It's an effective way to perform reconfiguration on any instances which are part of the stack.

Conclusion

AWS OpsWorks is an important service from Amazon. Enterprises managing a large number of applications and infrastructure resources can greatly benefit from OpsWorks. It has excellent support for Chef and Puppet. Using OpsWorks lets you automate lot of configuration tasks, so you do not have to spend valuable time on manual configuration tasks.