Well, there’s not much left to do besides deploy your app! Before we can do this, we have to start one of our instances. Click Navigation at the top left and select Instances to return to the Instances view. At the top right, click Start All Instances. You will see the Status field next to your instance change to requested, then pending, booting, running_setup, and, finally, online. The whole process should take a few minutes.
Now that we have an instance online, we can deploy. Under Navigation, select Apps to return to the Apps view. You’ll see the deploy button in the Actions column on the right side of the Photoalbums row. Click it, and you should now find yourself in the Deploy App view, as shown in Figure 2-22.
Figure 2-21. The Apps view
58
You’ll see that there are other commands besides Deploy available in this view. You can un-deploy your app, roll back to a previous version, start, stop, or restart the app. For now, we will use the Deploy command. The Comment field below is for your own internal notes about the deployment.
The Instances header below this informs you that the deployment will occur on one of one instances. You can only deploy to an instance that has been started. This is because a stopped instance, for all intents and purposes, does not exist. You don’t pay for the resources, so none is provisioned in an AWS data center. You cannot interact with a stopped instance beyond starting it. If you click Advanced, you can see a list of instances to which you are deploying.
If, for some reason, you wanted to deploy to only specific instances, you could select/deselect them here. One such scenario would be that one of your instances is in error (crashing), and you have a fix to deploy to resolve the issue. You deploy to the instances that are currently online, while you’re trying to bring the problematic instance back online. Once it’s online, you run the deployment again, but only on the instance that just recovered from an error. You may never encounter this use case, but it’s nice to know that OpsWorks can handle it!
Click Deploy and you will be brought to the Deployment view, shown in Figure 2-23.
While the deployment is running, you will see a few activity indicators spinning. When it finishes, the Status at the top will change to successful, and a green check mark will appear next to your instance. You’ll notice a few interesting features here. Under the SSH column, you can choose to connect via SSH directly to any of your running instances. You may never need to do this, but it’s good to have it. In the Log column, you can click Show to see the deployment logs for your instance.
These logs may be a bit overwhelming at first; they are the output of all the Chef recipes that are executed to deploy your app. They should mostly look like this:
[2014-10-26T18:48:44+00:00] INFO: Chef-client pid: 3167 Figure 2-23. Deployment view
If you see any log types besides INFO and WARN, you may want to investigate further. If you’re feeling adventurous, you can sort of follow the logs to get an understanding of what’s happening under the hood. A few of the major events in broad strokes follow:
The
• opsworks_custom_cookbooks::load and ::execute commands are run. A list of additional cookbooks based on the configuration and language of your app
•
are executed.
Your code is copied via SSH and validated.
•
Your code is deployed to
• /srv/www/photoalbums, and the Node.js environment is configured.
Your
• package.json file is detected, and node_modules is installed. Your app is started (or restarted).
•
This is a simplification, but it should give you an idea of what happens behind the scenes to make your code run in the cloud. Now it’s time for the moment of truth. Open the OpsWorks Navigation menu and choose Instances. In the Public IP column, you should see the IP address of your single instance. Click it, and you should see our welcome screen, shown in Figure 2-24.
Figure 2-24. Welcome to Photoalbums!
Can you believe it? We finally got our app up and running in the cloud! Because we haven’t configured a load balancer or added a domain, we’re just looking at the app on a single instance. This is not our intended use of OpsWorks—we do not want our users to directly access an EC2 instance. We will be remedying this soon.
Summary
Congratulations, you have an application residing on the Web, in the cloud! Sadly, it’s still basically useless until we have configured our database at the very least. You’ve covered a lot in this chapter, from exploring the major concepts of AWS architecture to creating our application stack from the ground up and deploying our code. In the next chapter, we will use Amazon RDS to host our database, and our application will become usable for the first time. By learning how to use OpsWorks, you have also learned a lot about the paradigms and vernacular of AWS in general and a lot about Identity and Access Management and EC2 in particular. This was a big step on the way to architecting and developing for the cloud.