In this video, Jeff Winesett introduces the application and deployment management tool OpsWorks. Opsworks can be used for any application platform and uses Chef configuration management software for configuration management.
- [Instructor] OpsWorks is one of several full application management and automation services offered by AWS that sits somewhere in the middle of the spectrum between convenience and control. It allows for management and automation of very customized applications of most any shape or size. OpsWorks has two offerings, AWS OpsWorks for Chef Automate, and AWS OpsWorks Stacks. The focus here is on AWS OpsWorks Stacks.
In AWS OpsWorks Stacks, things are conceptually divided into stacks and layers. A stack is a group of servers that solve a certain problem for you. The stack organizes all of the needed infrastructure to serve a similar purpose. For example, in thinking of the different environments needed for application software development such as test, staging, and production environments. These can be thought of separate OpsWorks stacks.
In terms of a traditional three tier application architecture, each stack would contain the needed web application, app servers, and database servers to run your application. The servers within these stacks get grouped into roles called layers. A layer is a sort of blueprint for a set of instances specifying information such as the instance settings, resources, and security groups. Examples are things like a DB layer, caching layer, application layer, web server layer.
Every server within a layer should be configured as a defined role. And OpsWorks takes care of launching the server into that role. The configuration in OpsWorks is done by writing Chef recipes. Chef is a well-known and popular open source configuration management tool. Chef configuration recipes are run on the server and can be triggered and executed during specific server lifecycle events that OpsWorks exposes. There are two important and primary parts to what the OpsWorks service provides, the OpsWorks provisioning engine and the OpsWorks agent.
The provisioning engine is responsible for the backend integration with other AWS services. It launches EC2 instances, attaches EBS volumes, configures ELBs, configures auto scaling, and handles auto healing. It's the provisioning engine that allows OpsWorks to automate the full application infrastructure. The OpsWorks agent is software that runs on the instances and is responsible for executing all of the on host configuration.
OpsWorks uses Chef for this and it is installed on every instance. It executes different commands on the instance that get defined by the Chef recipes. It sends keep alive messages for auto healing, which is a feature OpsWorks provides that can replace a failed instance within a layer if it is determined to be unhealthy based on these keep alive messages. This agent can also help to monitor host level metrics to be sent to CloudWatch.
The OpsWorks agent will execute different Chef configuration recipes at different times using a set of lifecycle events provided by OpsWorks. Set up, configure, deploy, undeploy, and shut down. Specifying which recipes are associated with which lifecycle events is part of configuring OpsWorks. Once defined, OpsWorks takes care of running them at the appropriate time.
The set up OpsWorks lifecycle event occurs once on a new instance just after successfully booting up. The configure event occurs on all of the stacks instances when any one of the stacks instances enters or leaves the online state. For example, the configure event is used when building distributed systems for any system that needs to be aware of when new instances are added or removed from the stack. You could use this event to update a load balancer when new web servers are added to the stack.
The deploy event occurs whenever you deploy an app. An app represents code that you want to run on an application server and part of what OpsWorks provides is managing the complexity of app deployments to the multiple servers within your stacks and layers. The undeployed event occurs when you delete an app from a stack and the shut down event occurs when an instance is stopped. Putting all of these concepts together, here is a high level overview of using OpsWorks.
First, a stack is created. Then, one or more layers are defined. Then, the application code to be run and launched into a layer is configured. Then, a Chef cookbook is created and recipes written. These recipes are then associated with specific OpsWorks event lifecycles such as setup, configure, shut down, etc. Then instances are launched into the defined layers. Finally, the applications are deployed onto the servers defined at each application hosting layer.
So, implementing elasticity rule number five, when dealing with an application architecture that is more complex than what Elastic Beanstalk supports, or simply, if more granular deployment and setup control is desired, consider using OpsWorks. OpsWorks helps manage the complexities of the application architecture, configuration management, and deployment management, and eases the ability for AWS applications to take advantage of the elastic nature of the Cloud.
- Benefits of cloud services
- Making architectures scalable
- Examining cloud constraints
- Virtual servers, EC2, and Elastic IP
- Using the Amazon machine image
- Elastic load balancing
- Using CloudWatch for monitoring
- Security Models
- Elastic block storage
- S3, CloudFront, and Elastic Beanstalk
- Handling queues, workflows, and notifications
- Caching options and services
- Identity and access management
- Creating a custom server image
- Application deployment strategies
- Serverless architectures