In this video, get a high-level overview of the main OpsWorks concepts.
- [Instructor] AWS OpsWorks takes resource, provisioning and deployment in a somewhat different direction than Elastic Beanstalk. Where Beanstalk is heavily prescriptive, letting you use pre-defined 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 instances they describe. You may be familiar with the Prototypical N-Tier Architecture for web applications. Each tier in this diagram is sometimes called a layer.
For instance, you have a data layer consisting of perhaps, a MySQL or PostgreSQL database. That data layer is accessed by a layer of web application servers. Those host a prevision 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 host, 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 at 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 gives 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 My Ruby F 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 integer 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 could define a load balancing layer using something like AK proxy, 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 instances to ad hock, one at a time, on a 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 installed and configured.
That's where configuration management comes in. One of the more exciting trends that has come up along side shift to clad competing 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 instance, configuration is coded, 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 now have guessed, OpsWorks layers are defined using a configuration management language. OpsWorks started its life using Chef exclusively. Since then, AWS has also added support for puppet but chef remains the primary option and is the mode we'll explore in this chapter.
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. They also provide prebuilt 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, each 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 the initial package installation. For instance, in a ruby stack, this setup phase might install ruby, rails, unicorn and engine x.
Recipes associated with the configure phase run when any instance in a 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 instance in the layer ensuring that all the layers resources remain consistent. Scripts associated with the deploy phase run anytime 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 anytime 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 shutdown. If you have an elastic load balancer connected, the 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 shake the way your application runs in OpsWorks.
- 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
- Working with the Cloud9 cloud-based IDE
- Quickly setting up coding projects with CodeStar