For now, we are only adding the single EC2 instance we created earlier. Select the instance, and make sure that Enable Cross-Zone Load Balancing is enabled. If this is enabled, your load balancer can route traffic to instances in multiple availability zones. We have already discussed the advantages of allocating resources across availability zones, so we definitely will want to balance traffic across EC2 instances in different availability zones. Click Continue and proceed to the Add Tags step.
Add Tags
By now, you’ve probably realized that you can very quickly accrue a large number of resources in AWS, some of which are named automatically by AWS and others following your own naming conventions. It can be difficult to track all the moving parts. One way that AWS helps alleviate this problem is through the use of tags. Tags are simply key-value pairs that you can create for many resources in AWS.
Note
■
the complete list of taggable resources is available at
http://docs.aws.amazon.com/AWSEC2/ latest/UserGuide/Using_Tags.html#tag-restrictions.
Each resource, be it an EC2 or RDS instance, etc., can have up to ten tags. This can help you organize your resources and can make it easier to keep your billing organized. For instance, if you host the infrastructure for multiple clients on your AWS account, you could tag your assets by client name or client
87
Perhaps you were running a production and development stack, and you wanted to determine the cost of spawning additional development environments for longer-term development cycles. You could tag your production resources with “Environment” = “Production” and your dev resources with “Environment” = “Development,” to project the cost of additional development environments.
These are just a couple examples. While AWS billing management is outside the scope of this book, it’s better to explain what Tags are than to ignore them entirely. Let’s add two tags to our ELB, for the sake of getting familiar with them. In the first tag field, type in Environment as the key and Production as the value, as in Figure 3-26. Then click Create Tag and add the key Stack with the value Photoalbums. Click Continue to proceed to the Review step.
Figure 3-26. Add ELB tags
Review
Amazon conveniently allows us to review all our choices before creating the load balancer (see Figure 3-27). Take a moment to review everything, and make sure it looks correct. If you made a mistake, there’s an Edit button, which can take you back to each individual step to fix the problem. When you’ve finished reviewing, click Create. In a few seconds, you will see a confirmation that your load balancer was created, and when you dismiss it, you will see your load balancer alone in a table.
When you select your load balancer, a tabbed detail view appears below the list, as shown in Figure 3-27. The Description tab gives you an overview of your load balancer. Front and center, you’ll see a Status field, which quickly tells you how many of your instances are in service. It should read “1 of 1 instances in service.” If your instance becomes unhealthy, this will change from 1 to 0, the point being that in service is a euphemism for healthy. You can also revisit any of the customizations you made to your load balancer. You can add/edit the tags, open/close ports, and change the configuration of the health check.
You can also manage the instances attached to your load balancer in the Instances tab. However, we will not be doing this here. If we are going to use a load balancer in our OpsWorks stack, we don’t want to manually add/remove instances to the load balancer in the EC2 dashboard. Instead, we want to handle load balancing the same way we did the database: by adding an ELB layer in OpsWorks.
OpsWorks ELB Layer
Return to OpsWorks and open the Photoalbums stack. Using the Navigation menu, head to the Layers view and select the Node.js App Server layer. In the layer subnavigation, select Network. Right at the top, you should see an Elastic Load Balancing header, under which you will see that no ELB has been added. Click Add an ELB to attach your ELB to the App Server layer.
The page will refresh, and the Elastic Load Balancer field will now show a drop-down from which you can select photoalbums-elb. When you do this, a warning will appear, informing you that OpsWorks configuration will now supersede changes made in the EC2 dashboard. This means that if you went back to EC2 and added more instances, the changes would be ignored, because OpsWorks commands will take
89
Click the ELB layer (ELB: photoalbums-elb) and you will see the detail view for the layer (see Figure 3-29). First, you will see a public URL next to the DNS Name. If you click this, you’ll be brought to the Hello World page of our application! You will also see a warning regarding all of your instances being in one availability zone. As discussed previously, it is best practice to duplicate resources in other availability zones. In this case, it’s a moot point, because we only have one instance in the App Server layer right now.
Figure 3-28. ELB, App Server, and RDS layers
Figure 3-29. ELB layer view in OpsWorks
At the bottom of the page, you will see a table of all the instances registered with your load balancer, organized by availability zone, and with status indicators to the right of each instance. Because we only have one instance in one availability zone (in this case, us-east-1a), there isn’t much information here. But once we’ve added more instances and availability zones, this section will give you a bird’s-eye view of the status of your App Server and a starting point to assess performance problems.
Note
■
In the last few minutes, we’ve seen eC2 instances described as healthy, in service, and Inservice.
these are all variations of the same meaning.
So far, we’ve accessed our application via the static IP address of the EC2 instance in our App Server layer. That was only a temporary step in the evolution of our application, as we will never want users to have control over which instance they connect to when using our application. Next, we will add an instance to our stack and interact with both instances via the load balancer.