{"id":8347,"date":"2013-02-04T22:54:37","date_gmt":"2013-02-04T22:54:37","guid":{"rendered":"https:\/\/gosqeng.test\/?p=186"},"modified":"2019-11-28T12:35:07","modified_gmt":"2019-11-28T12:35:07","slug":"how-we-use-ec2-instance-tags","status":"publish","type":"post","link":"https:\/\/www.gosquared.com\/blog\/how-we-use-ec2-instance-tags","title":{"rendered":"How we use EC2 Instance tags"},"content":{"rendered":"

Amazon EC2 conveniently offers the ability to associate (currently) up to 10 key-value “tags” to EC2 resources like instances and EBS volumes, containing any information you like. This is particularly useful for custom server nomenclature, data assignment, grouping, identification and so on, to help you organise and work with your instances conveniently.<\/p>\n

Naming<\/h3>\n

The most commonly used instance tag is one with the key “Name”. AWS seems to encourage the use of this themselves with widespread support for displaying the Name tag in the Management Console. Wherever possible\/implemented, the console will show you the Name tag instead of just the instance ID, saving you the trouble of looking up the nondescript instance ID to ensure you’re working with the right server.<\/p>\n

Here’s an example of what the Name tag looks like for one of the many instances busily working away on the analytics you love:<\/p>\n

nginx-1\n  ^   ^\n  |   |\nname  ID\n<\/code><\/pre>\n
 <\/p>\n
The two-part tag contains a name and a unique ID, delimited by a single hyphen. The name portion indicates what cluster, or “role”, the instance is assigned. The ID portion is a numerical ID to uniquely identify that instance.<\/p>\n
When you have a large number of instances to manage, identifying instances in this way is an essential part of the ops process. The real magic happens when you start using the EC2 API to query and minipulate instances based on their tags. It helps us classify instances, perform cluster-wide operations on related instances, deploy services to a target portion of instances, along with many other benefits.<\/p>\n
Hostnames<\/h3>\n
Now that all our instances have name tags, we can make use of these tags for server identification in a way that’s useful for our applications and services. We’ve built a tool in Ruby that makes use of the AWS API<\/a> to load a list of instances, their internal IP addresses and their Name tags. Using Ghost<\/a>, it then writes this information to the \/etc\/hosts file as host records, like this:<\/p>\n
127.0.0.1 localhost\n\n# ghost\nnginx-1 10.100.83.239\nnodejs-1 10.100.30.24\nnodejs-2 10.100.16.87\n# end ghost\n<\/code><\/pre>\n
 <\/p>\n
This service continually runs via upstart<\/a> on every instance, so that they each have up-to-date internal IP addresses mapped to a readable hostname for every other instance we own. As a result, there’s always a predictable*<\/a>, standardised way for instances and services to communicate with each other via readable, identifiable hostnames.<\/p>\n
This is great because it means you don’t need as much isolated logic to resolve and connect IP addresses in your applications. It also makes configuring distributed services, such as monitoring, logging, and load balancing tools less of a headache. This is because hostnames for these programs tend to be hard-coded in config files, and this way they’ll change less often.<\/p>\n
Notes<\/b><\/p>\n