So you’re setting up a fabulous new cloud-based compute infrastructure. It probably requires some software agents, at least for configuration management and monitoring. In a traditional enterprise on-premise setting, the agents would be identified by their hostname, such as “erpdb01.ca.purplefishfood.com”.
The nice thing about using hostnames is that they are unique and easy to figure out. Enterprises have been working with DNS servers for decades and have taken great care to ensure that hostnames are well-managed.
But what happens when you go to the public cloud? In Amazon EC2, hostnames have an odd-looking format derived from their private IP address, such as ip-172-39-0-172.ec2.internal
What’s so strange about this? For one thing, hostnames are not managed by you, the user. Hostnames are assigned automatically by EC2, and there isn’t any way of controlling this assignment. Also, hostnames are not necessarily unique. In case you have several independent subnets with overlapping IP address ranges (maybe even from different AWS accounts), they will have the same hostname. But most importantly, AWS-generated hostnames are not stable. Under default settings, whenever an EC2 server is restarted, its IP address is changed on the fly – and the hostname is changed along with it.
So what happens if you just use the hostname as a unique ID, as you did in the enterprise data center? Most likely, the agent will still function, and will still show up in its management console, under its hostname at the time the agent was installed. But the lack of uniqueness may mean that agents from different servers may have their identity mixed up, resulting in loss of reported data, “blind spots” of unmonitored or uncontrollable servers, and maybe even configuration operations accidentally taking place on the wrong server.
Possibly the biggest drawback of using hostnames is that due to their instability, you are bound to end up with a mismatch between the hostnames you see in agent consoles and the hostnames you see in the cloud management console. Such confusion can have dire consequences when operations and DevOps teams try to maintain the environment.
The Jetpatch Agent Manager offers a simple solution to the agent identity issue: instead of using hostnames, we use the cloud vendor’s instance ID as the agent identifier. Instance IDs are the cloud era equivalent of last century’s hostnames: a unique way of identifying a server throughout its lifecycle. Jetpatch makes it easy to use the instance ID as an identifier not only when setting up the agent itself, but also, when configuring the console to accept the agent into its inventory. Agent identities are no longer an issue.
Want to try the Jetpatch Agent Manager for yourself? Get it on the AWS Marketplace and check out our Getting Started Guide.