Any application requires specific sets of resources like load balancers, web and application servers, and a database server. These resources must be managed as a whole. Furthermore, you must place your application to the application servers, manage security and resource permissions, and monitor the performance of the solution.
This paper details how to use AWS OpsWorks to manage applications and their related resources and offers guidance to help deliver these solutions. That is what we here at Myrtec do, we are a specialist provider of Managed IT and Cloud Services set on changing the nature of IT service delivery in Australia. Don’t hesitate to contact us for any questions you have with regards to these services. We should be able to explain to you in full detail, the contents of this paper.
AWS OpsWorks provides a flexible way to create and manage resources for your applications. It supports standard components such as application servers, database servers, and load balancers, as well as custom components such as search tools and messaging systems. AWS OpsWorks also provides tools to customize the standard package configurations, install additional packages, automate run books, and manage users’ OS-level permissions.
Before you get started using AWS OpsWorks, it’s helpful to understand some key concepts.
A stack is a set of AWS resources that are managed together—for example, Amazon EC2 instances, Amazon EBS volumes, and Elastic Load Balancing load balancers. AWS OpsWorks helps you manage these resources as a whole and also defines some default configuration settings. You can create separate stacks for different environments—e.g., one stack for QA/testing and one for production—and for different applications.
Each stack contains one or more layers. A layer specifies how to configure a set of Amazon EC2 instances for a specific purpose such as hosting a web server.
AWS OpsWorks provides a set of built-in layers that support a variety of standard packages, including application servers such as Tomcat and Node.js, MySQL and Amazon RDS database servers, Elastic Load Balancing and HAProxy load balancers, and so on. AWS OpsWorks allows you to customize or extend the built-in layers by modifying default configurations and adding custom Chef Recipes. You can also create a fully custom layer, which gives you complete control over the layer configuration and setup.
You represent your application within AWS OpsWorks by defining an app, which specifies the application type and contains the information needed to deploy the application from its repository to your application server instances. When deploying an app, AWS OpsWorks runs the Deploy recipes on all of the stack's instances, which allows instances such as database servers to modify their configuration as appropriate. AWS OpsWorks supports the ability to deploy multiple apps per stack and per layer. Amazon Web Services – Managing Multi-Tiered Applications with AWS OpsWorks January 2015
Life Cycle Events
Each layer within an AWS OpsWorks stack has a set of life cycle events that correspond to different stages in an instance's life cycle, such as setup or app deployment. Each life cycle event has an associated set of Chef Recipes that are executed on each of the layer's instances to perform the required tasks. AWS OpsWorks provides built-in recipes to perform basic management, and you can add custom recipes to any life cycle event to script any configuration change that your application needs.
Once a new instance has booted, AWS OpsWorks triggers the Setup event, which runs recipes to set up the instance according to the layer configuration. For example, if the instance is part of the PHP App Server layer, the Setup recipes install the Apache and PHP packages. Once setup is complete, AWS OpsWorks triggers a Deploy event, which runs recipes to deploy your application to the new instance.
Whenever an instance enters or leaves the online state, AWS OpsWorks triggers a Configure event on all instances in the stack. The event runs each layer's configure recipes to update the configuration to reflect the current set of online instances. For example, the HAProxy layer's Configure recipes modify the load balancer configuration to reflect any added or removed application server instances.
AWS OpsWorks triggers a Deploy event when you run a Deploy command, typically to deploy your application to a set of application servers. The event runs recipes on the application servers to deploy the application and any related files from its repository to the layer's instances. You can trigger Deploy on other instances so they can, for example, update their configuration to accommodate the newly deployed app.
AWS OpsWorks triggers an Undeploy event when you delete an app or run an Undeploy command to remove an app from a set of application servers. The event runs recipes to remove all application versions and perform any additional cleanup tasks.
AWS OpsWorks triggers a Shutdown event when an instance is being shut down, but before the underlying Amazon EC2 instance is actually terminated. The event runs recipes to perform cleanup tasks such as shutting down services. AWS OpsWorks allows Shutdown recipes a configurable amount of time to perform their tasks, and then terminates the instance.