In the first part of our tutorial we explored the anatomy of a Symfony2 deployment and how we can use Chef in Amazon OpsWorks to manage and deploy a Symfony2 application.
In this tutorial, we are going to explore OpsWorks' core concepts and deployment lifecycle.
OpsWorks is fully integrated with the majority of the Amazon Services such as the Elastic Load Balancer, CloudWatch and RDS. It provides a unified and flexible environment which enables you to use the aforementioned services with ease.
OpsWorks also introduces some new concepts around application management and deployment.
Stacks: A Stack represents the application and its resources as a single entity. It is comprised of many configurations and AWS resources. Stacks enable us to manage various heterogeneous applications within OpsWorks.
Layers: A Layer resides inside the Stack and contains the specifications of our instances. These specifications include information about the Chef recipes, the network and the security of our instance. A Layer serves the same purpose as a Chef role. We can have more than one Layer in our Stack.
Apps: An Application is the code that we want to deploy in our instances.
Instances: An instance is the actual EC2 instance that hosts our application. When an instance is created in OpsWorks, it inherits the specifications we set in our Layer and the instance is organized accordingly.
When the instance is either booted or stopped there is a series of events that take place inside the instance. During these events we can set which Chef recipes we would like to execute at each stage.
- Setup: The setup event is triggered after a new instance is booted.
- Configure: The configure event is triggered on all of the Stack's instances when an instance changes state.
- Deploy: The deploy event occurs when we deploy our application. When an instance is created for the first time, the deploy event will run after the setup event automatically. Afterwards, the deploy event can be triggered manually by the OpsWorks dashboard.
- Undeploy: As its name states, the undeploy event occurs when we delete an application.
- Shutdown: The shutdown event is triggered when we shutdown or stop an instance.
For example: We could install some general-purpose system packages during the setup event and configure and install our application during the deploy event. If the application leaves traces or temporary files we could also use the undeploy event to clean up those files.
Caveat: Since the configure event affects all of your instances you should be careful what you run during that event.
Let’s explore how we can create a Stack, a Layer and an Application inside OpsWorks.
As you can see, we can set the default operating system that we want to use in all of our instances along with much more information such as the Region, the Availability Zone and Chef-related configurations. We should also enable the custom Chef cookbooks option in order to add our own Chef repository. Although OpsWorks provides a variety of built-in cookbook it is always better to use your own custom repository for flexibility reasons.
At the bottom of the advanced settings there is a text area called Custom JSON. As we learned in the previous part of the tutorial, Symfony2 applications may require a variety of sensitive information such as passwords and database credentials. We make use of Chef attributes in order to define values dynamically and avoid hardcoding sensitive values inside the repository. By using CustomJSON we can override the dummy values of attributes and add our passwords and API keys. CustomJSON can be both Stack and Layer wise.
Since Stack is created successfully, let’s create a Layer.
We don't want to use any OpsWorks' built-in Layer, so we go with the Custom Layer. As a short name we should add our cookbook's name.
At this point we should set which recipe we want to execute at specific events. Once the Layer is created, go to Layer's settings at the Recipes section.
We have set the setup and deploy recipes to run at the setup and deploy events. OpsWorks also maintains some custom recipes that run during the events by default.
As a final step, we should specify information about our Symfony2 application in Apps section.
This was pretty straightforward. If you keep your application in a private repository you will have to add an SSH key to your repository to allow the OpsWorks to fetch the repository. If application supported HTTPS, we could also add the SSL certificates in order to be deployed with our application.
We can now go at the Instances section and create our first instance. Note that all of these operations could be handled via the awscli or the AWS API.
Once we start the instance a label will be displayed with the current status of the instance.
If our instance completes all the events successfully the label will turn green stating that the instance is 'online'. Otherwise it will turn red and it will return a full log with the errors.
That's all folks.
This was an overview of how things are operating in OpsWorks in conjunction with Chef and Symfony2.
If you found OpsWorks interesting you could start by reading the official documentation provided by Amazon.