Join Brandon Rich for an in-depth discussion in this video OpsWorks key concepts, part of Amazon Web Services: Deploying and Provisioning.
- [Teacher] AWS OpsWorks takes resource provisioning and deployment in a somewhat different direction than the Elastic Beanstalk. Where Beanstalk is heavily prescriptive, letting you use predefined infrastructure choices, OpsWorks lets you describe your architecture in a more granular fashion. Let's take a look at the basic concepts of OpsWorks: stacks, layers, and the instances they describe. You may be familiar with the prototypical n-tier architecture for way of applications. Each tier in this diagram is sometimes called a layer. For instance, you have a data layer, consisting of perhaps of MySQL or Postgres database.
That data layer is accessed by a layer of web application servers. This have to provision with certain software, say an application server and a web server on top of that. Sometimes, app servers and web servers are separated into their own layers with their own hosts, sometimes not. Another layer app, your traffic is distributed to the app servers by a load balancer. This whole picture, the contents and configuration of each layer and how they relate to each other is called a stack. Stacks and layers are the the heart of AWS OpsWorks, whereas Elastic Beanstalk being platformed as a service takes care of most of the stack decisions for you, OpsWorks hands over the reins and give you more control.
In OpsWorks, you define a stack in a certain region. This is just a container for the app you'll build. It has a name like MyRubyApp. Then we define layers. In OpsWorks, a layer is really a set of rules or instructions for how to configure resources, and they tend to map well to the idea of layers in the n-tier architecture. For instance, in the Ruby example, you might have an application server layer that handles the app, and a Ruby On Rails server like Unicorn or Passenger. In OpsWorks, you can define a layer like this and add it to your stack.
Later on, you'll associate actual EC2 instances with this layer. You might have other layers, for instance, a database layer. The load balancing layer is a bit different. Although you couldn't define a load balancing layer using something like HAProxy, typically, in OpsWorks, you simply attach an EOB to an existing layer. Layers by themselves do nothing; they're just definitions. Only when you add EC2 instances to your layers do they become useful. When you add them, their provision, with the software and configuration described by the layer definition.
You can add instance ad hoc, one at a time, on schedule, or in response to load. So how are layers actually defined? As I said, layers specify how the resources they contain are actually configured. For example, any instance that belongs to a database layer should have a database installing configured. That's where configuration management comes in. One of the more exciting trends that has come up alongside to shift to cloud computing is the idea of configuration as code. Any good system administrator knows that you want to script as many server configuration and maintenance tasks as possible.
In this sense, configuration is coding; it's nothing new. What is new are the various technologies that now exist to make it even easier to write, manage, share and execute this kind of code. Frameworks like Puppet, Chef and Ansible are some of the most prominent configuration management tools. Each one provides a domain-specific language for doing things like installing packages, writing files, creating users, and setting system permissions. Each one has a community of open source users that help create and maintain common scripts to share.
As you may not have guessed, OpsWorks layers are defined using a configuration management language; specifically Chef. Chef scripts, or recipes, are written in Ruby, making it a very friendly tool for any developer already versed in that language. OpsWorks lets power users define their own layers using their own Chef code, but they also provide pre-built recipes that define the layers of some common stacks, such as the Ruby On Rails stack we want to build. One important thing to remember is that a layer consists of not just one Chef recipe, but of a collection of recipes, which of which executes at a certain time in the OpsWorks life cycle.
These are the phases of an OpsWorks stack deployment: setup, configure, deploy, undeploy and shutdown. Chef recipes associated with the setup phase run when a new instance in the layer boots, or when the user manually triggers a setup event. This is the step where recipes would run and do initial package installation. For instance, in a Ruby stack, the setup phase might install Ruby, Rails, Unicorn and Nginx. Recipes associated with the configure phase run when any instance in the layer goes online, such as after setup, or when an elastic IP or elastic load balancer is attached or detached.
Configure recipes also run on every layer in the instance, ensuring that all the layers' resources remain consistent. Scripts associated with the deploy phase run any time you want to deploy a new version of an application. They also run after the setup phase completes for a new host. Recipes associated with undeploy run any time a manual undeploy is triggered or when you delete an app from the stack. Scripts associated with the shutdown phase run when any instance on a layer gets shut down. If you have an elastic load balancer connected, a shutdown phase allows time for user requests to finish before shutting down the instance.
Note that shutdown scripts do not run on reboot. What about the applications you want to run on an OpsWorks stack? Applications can be sourced from S3, Git, SVN, or even from a url on the public Internet. If you store your application in S3 or on the web, it must be zipped. When you define an application, you must specify the source location. You may optionally include an SSL cert to serve https traffic. You can set environment variables, and you make decisions about platform-specific settings.
For instance, with Ruby, you'll specify whether Bundler should automatically run on each deployment. Later, when we perform deployments, these decisions will shape the way your application runs in OpsWorks.
This course is also part of a series designed to help you prepare for the AWS Certified SysOps Administrator – Associate certification exam.
- Understanding AWS EC2
- Creating an EC2 instance
- Provisioning with CloudFormation
- Architecting apps for horizontal scaling
- Creating an Elastic Beanstalk environment and app
- Using OpsWorks
- Deploying apps with CodeDeploy