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 webapplication best runs on m2 x large 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 ana is
therefore only done once per week.
Recently, a new chat feature has been implemented in nodejs and wails 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 Ops Works as an application life cycle
tool to simplify management of the application and reduce the deployment cycles.
What configuration in AWS Ops Works is necessary to integrate the new chat module in the most cost-efficient
and flexible way?
A.
Create one AWS Ops Works stack, create one AWS Ops Works layer, create one custom recipe
B.
Create one AWS Ops Works stack create two AWS Ops Works layers create one custom recipe
C.
Create two AWS Ops Works stacks create two AWS Ops Works layers create one custom recipe
D.
Create two AWS Ops Works stacks create two AWS Ops Works layers create two custom recipe
It is B
Can you explain why?
Any clue why its B ?
why is it B and not C?
c
Why is B suggested? C – create one recipe, two stacks and two layers.
I believe it is one Stack based on the Stack description giving in:
http://docs.aws.amazon.com/opsworks/latest/userguide/workingstacks.html
The stack is the top-level AWS OpsWorks entity. It represents a set of instances that you want to manage collectively, typically because they have a common purpose such as serving PHP applications. In addition to serving as a container, a stack handles tasks that apply to the group of instances as a whole, such as managing applications and cookbooks.
For example, a stack whose purpose is to serve web applications might look something like the following:
– A set of application server instances, each of which handles a portion of the incoming traffic.
– A load balancer instance, which takes incoming traffic and distributes it across the application servers.
– A database instance, which serves as a back-end data store for the application servers.
I like B on this one.
You only need one stack to contain two layers:
– one layer for the Java/Tomcat instances
– one layer for DynamoDB
You’d only need one custom recipe because the only OpsWorks Lifecycle Event that would be involved in rolling out the new chat feature would be “Deploy”. (Or you could implement it in “Setup” if you choose to make including the chat app a new baseline standard for your instances in that layer. But even then, you’d only have one custom recipe because there would be no need to customize the “Deploy” event to install the chat app if you already installed out the chat app in “Setup”.) So you’d need a custom recipe for that one lifecycle event. And it would only be used for the “Deploy” lifecycle event on the app layer, not on the DB layer.
If you look further down best practice is having multiple stacks:
A common practice is to have multiple stacks that represent different environments. A typical set of stacks consists of:
A development stack to be used by developers to add features, fix bugs, and perform other development and maintenance tasks.
A staging stack to verify updates or fixes before exposing them publicly.
A production stack, which is the public-facing version that handles incoming requests from users.
http://docs.aws.amazon.com/opsworks/latest/userguide/workingstacks.html
B
Go to B
c is correct – blue green transition…