AWS OpsWorks

• AWS OpsWorks is a configuration management service that helps to configure and operate applications in a cloud enterprise by using Chef
• OpsWorks Stacks and AWS OpsWorks for Chef Automate allows using Chef cookbooks and solutions for configuration management

OpsWorks Stacks

• OpsWorks Stacks provides a simple and flexible way to create and manage stacks, groups of AWS resources like load balancers, web, application and database servers, and application deployed on them
• OpsWorks Stacks helps deploy and monitor applications in the stacks.
• Unlike OpsWorks for Chef Automate, OpsWorks Stacks does not require or create Chef servers; and performs some of the work of a Chef server itself
• OpsWorks Stacks monitors instance health, and provisions new instances, when necessary, by using Auto Healing and Auto Scaling
• OpsWorks Stacks integrates with IAM to control how users can interact with stacks, what stacks can do on the users behalf, what AWS resources an app can access etc
• OpsWorks Stacks integrates with CloudWatch and CloudTrail to enable monitoring and logging
• OpsWorks Stacks can be accessed globally and can be used to create and manage instances globally

Stacks

• Stack is the core AWS OpsWorks Stacks component.
• Stack is a container for AWS resources like EC2, RDS instances etc that have a common purpose and should be logically managed together
• Stack helps manage the resources as a group and also defines some default configuration settings, such as the instances’ OS and AWS region
• Stacks can also be run in VPC to be isolated from direct user interaction
• Separate Stacks can be created for different environments like Dev, QA etc

Layers

• Stacks help manage cloud resources in specialized groups called layers.
• A layer represents a set of EC2 instances that serve a particular purpose, such as serving applications or hosting a database server.
• Layers depend on Chef recipes to handle tasks such as installing packages on instances, deploying apps, and running scripts
• Custom recipes and related files is packaged in one or more cookbooks and stored in a cookbook repository such S3 or Git

Recipes and LifeCycle Events

• Layers depend on Chef recipes to handle tasks such as installing packages on instances, deploying apps, running scripts, and so on.
• OpsWorks Stacks runs the recipes for each layer, even if the instance belongs to multiple layers for e.g. instance hosting both the application and the mysql server
• AWS OpsWorks Stacks features is a set of lifecycle events – Setup, Configure, Deploy, Undeploy, and Shutdown – which automatically runs specified set of recipes at the appropriate time on each instance
  • Setup
    • Once a new instance has booted, OpsWorks triggers the Setup event, which runs recipes to set up the instance according to the layer configuration for e.g. installation of apache, PHP packages
    • Once setup is complete, AWS OpsWorks triggers a Deploy event, which runs recipes to deploy your application to the new instance.
  • Configure
    • Whenever an instance enters or leaves the online state, AWS OpsWorks triggers a Configure event on all instances in the stack.
    • Event runs each layer’s configure recipes to update configuration to reflect the current set of online instances for e.g. the HAProxy layer’s Configure recipes can modify the load balancer configuration to reflect any added or removed application server instances.
  • Deploy
    • OpsWorks triggers a Deploy event when the Deploy command is executed, to deploy the application to a set of application servers.
    • Event runs recipes on the application servers to deploy application and any related files from its repository to the layer’s instances.
  • Undeploy
    • OpsWorks triggers an Undeploy event when an app is deleted or  Undeploy command is executed to remove an app from a set of application servers.
    • Event runs recipes to remove all application versions and perform any additional cleanup tasks.
  • Shutdown
    • OpsWorks triggers a Shutdown event when an instance is being shut down, but before the underlying EC2 instance is actually terminated.
    • Event runs recipes to perform cleanup tasks such as shutting down services.
    • OpsWorks allows Shutdown recipes a configurable amount of time to perform their tasks, and then terminates the instance.

Instance

• An instance represents a single computing resource for e.g. EC2 instance and it defines resource’s basic configuration, such as OS and size
• OpsWorks Stacks create instances and adds them to a layer.
• When the instance is started, OpsWorks Stacks launches an EC2 instance using the configuration settings specified by the instance and its layer.
• After the EC2 instance has finished booting, OpsWorks Stacks installs an agent that handles communication between the instance and the service and runs the appropriate recipes in response to lifecycle events
• OpsWorks Stacks supports instance auto-healing, whereby if an agent stops communicating with the service, OpsWorks Stacks automatically stops and restarts the instance
• OpsWorks Stacks supports the following instance types
  • 24/7 instances – launched and stopped manually
  • Time based instances – run on scheduled time
  • Load based instances – automatically started and stopped based on configurable load metrics
• Linux based computing resources created outside of the OpsWorks stacks for e.g. console or CLI can be added, incorporated and controlled through OpsWorks

Apps

• An AWS OpsWorks Stacks app represents code that you want to run on an application server residing in the app repository like S3
• App contains the information required to deploy the code to the appropriate application server instances.
• When you deploy an app, AWS OpsWorks Stacks triggers a Deploy event, which runs the Deploy recipes on the stack’s instances.
• OpsWorks supports the ability to deploy multiple apps per stack and per layer

OpsWorks Deployment Strategies

Refer to OpsWorks Deployment Strategies blog post for details

AWS Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. You are working with a customer who is using Chef configuration management in their data center. Which service is designed to let the customer leverage existing Chef recipes in AWS?
   1. Amazon Simple Workflow Service
   2. AWS Elastic Beanstalk
   3. AWS CloudFormation
   4. AWS OpsWorks
2. Your mission is to create a lights-out datacenter environment, and you plan to use AWS OpsWorks to accomplish this. First you created a stack and added an App Server layer with an instance running in it. Next you added an application to the instance, and now you need to deploy a MySQL RDS database instance. Which of the following answers accurately describe how to add a backend database server to an OpsWorks stack? Choose 3 answers
   1. Add a new database layer and then add recipes to the deploy actions of the database and App Server layers. (Refer link)
   2. Use OpsWorks’ “Clone Stack” feature to create a second RDS stack in another Availability Zone for redundancy in the event of a failure in the Primary AZ. To switch to the secondary RDS instance, set the [:database] attributes to values that are appropriate for your server which you can do by using custom JSON.
   3. The variables that characterize the RDS database connection—host, user, and so on—are set using the corresponding values from the deploy JSON’s [:deploy][:app_name][:database] attributes. (Refer link)
   4. Cookbook attributes are stored in a repository, so OpsWorks requires that the “password”: “your_password” attribute for the RDS instance must be encrypted using at least a 256-bit key.
   5. Set up the connection between the app server and the RDS layer by using a custom recipe. The recipe configures the app server as required, typically by creating a configuration file. The recipe gets the connection data such as the host and database name from a set of attributes in the stack configuration and deployment JSON that AWS OpsWorks installs on every instance. (Refer link)
3. You are tasked with the migration of a highly trafficked node.js application to AWS. In order to comply with organizational standards Chef recipes must be used to configure the application servers that host this application and to support application lifecycle events. Which deployment option meets these requirements while minimizing administrative burden?
   1. Create a new stack within Opsworks add the appropriate layers to the stack and deploy the application
   2. Create a new application within Elastic Beanstalk and deploy this application to a new environment (need to comply with chef recipes)
   3. Launch a Node JS server from a community AMI and manually deploy the application to the launched EC2 instance
   4. Launch and configure Chef Server on an EC2 instance and leverage the AWS CLI to launch application servers and configure those instances using Chef.
4. A web-startup runs its very successful social news application on Amazon EC2 with an Elastic Load Balancer, an Auto-Scaling group of Java/Tomcat application-servers, and DynamoDB as data store. The main web application best runs on m2.xlarge instances since it is highly memory- bound. Each new deployment requires semi-automated creation and testing of a new AMI for the application servers which takes quite a while and is therefore only done once per week. Recently, a new chat feature has been implemented in node.js and waits to be integrated in the architecture. First tests show that the new component is CPU bound Because the company has some experience with using Chef, they decided to streamline the deployment process and use AWS OpsWorks as an application life cycle tool to simplify management of the application and reduce the deployment cycles. What configuration in AWS OpsWorks is necessary to integrate the new chat module in the most cost-efficient and flexible way?
   1. Create one AWS Ops Works stack, create one AWS Ops Works layer, create one custom recipe
   2. Create one AWS Ops Works stack, create two AWS Ops Works layers create one custom recipe (Single environment stack, two layers for java and node.js application using built-in recipes and custom recipe for DynamoDB connectivity only as other configuration. Refer link)
   3. Create two AWS Ops Works stacks, create two AWS Ops Works layers create one custom recipe
   4. Create two AWS Ops Works stacks, create two AWS Ops Works layers create two custom recipe
5. You company runs a complex customer relations management system that consists of around 10 different software components all backed by the same Amazon Relational Database (RDS) database. You adopted AWS OpsWorks to simplify management and deployment of that application and created an AWS OpsWorks stack with layers for each of the individual components. An internal security policy requires that all instances should run on the latest Amazon Linux AMI and that instances must be replaced within one month after the latest Amazon Linux AMI has been released. AMI replacements should be done without incurring application downtime or capacity problems. You decide to write a script to be run as soon as a new Amazon Linux AMI is released. Which solutions support the security policy and meet your requirements? Choose 2 answers
   1. Assign a custom recipe to each layer, which replaces the underlying AMI. Use AWS OpsWorks life-cycle events to incrementally execute this custom recipe and update the instances with the new AMI.
   2. Create a new stack and layers with identical configuration, add instances with the latest Amazon Linux AMI specified as a custom AMI to the new layer, switch DNS to the new stack, and tear down the old stack. (Blue-Green Deployment)
   3. Identify all Amazon Elastic Compute Cloud (EC2) instances of your AWS OpsWorks stack, stop each instance, replace the AMI ID property with the ID of the latest Amazon Linux AMI ID, and restart the instance. To avoid downtime, make sure not more than one instance is stopped at the same time.
   4. Specify the latest Amazon Linux AMI as a custom AMI at the stack level, terminate instances of the stack and let AWS OpsWorks launch new instances with the new AMI. (Will lead to downtime)
   5. Add new instances with the latest Amazon Linux AMI specified as a custom AMI to all AWS OpsWorks layers of your stack, and terminate the old ones.
6. When thinking of AWS OpsWorks, which of the following is not an instance type you can allocate in a stack layer?
   1. 24/7 instances (24/7 instances are supported and started manually and run until you stop them)
   2. Spot instances (Does not support spot instance directly but can be used with auto scaling Refer link)
   3. Time-based instances (Time-based instances are run by AWS OpsWorks on a specified daily and weekly schedule)
   4. Load-based instances (Load-based instances are automatically started and stopped by AWS OpsWorks, based on specified load metrics, such as CPU utilization)
7. Which of the following tools does not directly support AWS OpsWorks, for monitoring your stacks?
   1. AWS Config (Refer link)
   2. Amazon CloudWatch Metrics (AWS OpsWorks uses CloudWatch to provide thirteen custom metrics with detailed monitoring for each instance in the stack)
   3. AWS CloudTrail (AWS OpsWorks integrates with CloudTrail to log every AWS OpsWorks API call and store the data in an S3 bucket)
   4. Amazon CloudWatch Logs (You can use Amazon CloudWatch Logs to monitor your stack’s system, application, and custom logs.)
8. When thinking of AWS OpsWorks, which of the following is true?
   1. Stacks have many layers, layers have many instances.
   2. Instances have many stacks, stacks have many layers.
   3. Layers have many stacks, stacks have many instances.
   4. Layers have many instances, instances have many stacks.

References

• AWS_OpsWorks_User_Guide