AWS OpsWorks – Flexible Application Management in the Cloud Using Chef
Its been over six years since we launched Amazon EC2. After that launch, weve delivered several solutions that make it easier for you to deploy and manage applications.
Two years ago we launched AWS CloudFormation to provide an easy way to create a collection of related AWS resources and provision them in an orderly and predictable fashion and AWS Elastic Beanstalk that allows users to quickly deploy and manage their applications in the AWS cloud. As our customers run more applications on AWS they are asking for more sophisticated tools to manage their AWS resources and automate how they deploy applications.
AWS OpsWorks features an integrated management experience for the entire application lifecycle including resource provisioning, configuration management, application deployment, monitoring, and access control. It will work with applications of any level of complexity and is independent of any particular architectural pattern.
AWS OpsWorks was designed to simplify the process of managing the application lifecycle without imposing arbitrary limits or forcing you to work within an overly constrained model. You have the freedom to design your application stack as you see fit.
You can use Chef Recipes to make system-level configuration changes and to install tools, utilities, libraries, and application code on the EC2 instance within your application. By making use of the AWS OpsWorks event model, you can activate the recipes of your choice at critical points in the lifecycle of your application. AWS OpsWorks has the power to install code from a wide variety of source code repositories.
There is no additional charge for AWS OpsWorks. You pay only for the AWS resources (EC2 instances, EBS volumes, and so forth) that your application uses.
AWS OpsWorks is available today and you can start using it now!
AWS OpsWorks Concepts
Let’s start out by taking a look at the most important AWS OpsWorks concepts.
An AWS OpsWorks Stack contains a set of Amazon EC2 instances and instance blueprints (which OpsWorks calls Layers) that are used to launch and manage the instances. Each Stack hosts one or more Applications. Stacks also serve as a container for the other user permissions and resources associated with the Apps. A Stack can also contain references to any number of Chef Cookbooks.
Each Stack contains a number of Layers. Each Layer specifies the setup and configuration of a set of EC2 instances and related AWS resources such as EBS Volumes and Elastic IP Addresses. We’ve included Layers for a number of common technologies including Ruby, PHP, Node.js, HAProxy, Memcached, and MySQL. You can extend these Layers for your own use, or you can create custom Layers from scratch. You can also activate the Chef Recipes of your choice in response to specific events (Setup, Configure, Deploy, Undeploy, and Shutdown).
AWS OpsWorks installs Applications on the EC2 instances by pulling the code from one or more code repositories. You can indicate that the code is to be pulled from a Git or Subversion repository, fetched via an HTTP request, or downloaded from an Amazon S3 bucket.
After you have defined a Stack, its Layers, and its Applications, you can create EC2 instances and assign them to specific Layers. You can launch the instances manually, or you can define scaling based on load or by time. Either way, you have full control over the instance type, Availability Zone, Security Group(s), and operating system. As the instances launch, they will be configured to your specifications using the Recipes that you defined for the Layer that contains the instance.
AWS OpsWorks will monitor your instances and report metrics to Amazon CloudWatch (you can also use Ganglia if you’d like). It will automatically replaced failed instances with fully configured fresh ones.
AWS OpsWorks in Action
Let’s take a quick look at the AWS OpsWorks Console. The welcome page provides you with a handy overview of the steps you’ll take to get started:
Start out by adding a Stack. You have full control of the Region and the default Availability Zone. You can specify a naming scheme for the EC2 instances in the Stack and you can even select a color to help you distinguish your Stacks:
AWS OpsWorks will assign a name to each EC2 instance that it launches. You can select one of the following themes for the names:
You can add references to one or more Chef Cookbooks:
Now you can add Layers to your Stack:
When you add a Layer of a predefined type, you have the opportunity to customize the settings as appropriate. For example, here’s what you can customize if you choose to use the Ruby on Rails Layer:
You can add custom Chef Recipes and any additional software packages to your Layer. You can also ask for EBS Volumes or Elastic IP Addresses and you can configure RAID mount points:
You can see the built-in Chef recipes that AWS OpsWorks includes. You can also add your own Chef Recipes for use at various points in the application lifecycle. Here are the built-in Recipes included with the PHP Layer:
Here’s what my Stack looks like after adding four layers (yours will look different, depending on the number and type of Layers you choose to add):
Applications are your code. You can add one or more Applications to the Stack like this. Your options (and this screen) will vary based on the type of application that you add:
With the Stack, the Layers, and the Applications defined, it is time to add EC2 instances to each Layer. As I noted earlier, you can add a fixed number of instances to a Layer or you can use time or load-based scaling, as appropriate for your application:
You can define time-based scaling in a very flexible manner. You can use the same scaling pattern for each day of the week or you can define patterns for particular days, or you can mix and match:
With everything defined, you can start all of the instances with a single click (you can also control them individually if you’d like):
Your instances will be up and running before long:
Then you can deploy your Applications to the instances:
You have the ability to control exactly which instances receive each deployment. AWS OpsWorks pulls the code from your repository and runs the deploy recipes on each of the selected instances to configure all the layers of your app. Heres how it works. When you deploy an app, you might have a recipe on your database Layer that performs a specific configuration task, such as creating a new table. The recipes on your Layers let you to simplify the configuration steps across all the resources in your application with a single action.
Of course, there are times that you may need to get onto the instances. AWS OpsWorks helps here, too. You can configure SSH keys for each IAM user as well as configure which IAM users can use sudo.
At the top level of AWS OpsWorks, you can manage the entire Stack with a couple of clicks:
I hope that you have enjoyed this tour of AWS OpsWorks. I’ve shown you the highlights; there’s even more functionality that you’ll discover over time as you get to know the product.
AWS OpsWorks Demo
Watch this short (5 minute) video to see a demo of AWS OpsWorks:
Today, OpsWorks provides full control of software on EC2 instances and lets you use Chef recipes to integrate with AWS resources such as S3 and Amazon RDS. Moving forward, we plan to introduce integrated support for additional AWS resource types to simplify the management of layers that dont require deep control. As always, your feedback will help us to prioritize our development effort.
What Do You Think?
I invite you to give AWS OpsWorks a whirl and let me know what you think. Feel free to leave a comment!
PS – Don’t forget to read Werner’s take on OpsWorks – Expanding the Cloud – Introducing AWS OpsWorks, a Powerful Application Management Solution.