Skip to content

Hosts and subdomains and infrastructure deployment

It always amazes me how many IT infrastructure managers apparently fail to understand just what a ‘subdomain’ is. How many of the developers reading this blog entry have ever been confronted with the situation of deploying their applications onto infrastructure that’s named like the following?

  1. Local development: localhost, localhost, localhost, joes-dev-box
  2. Development / Integration: tomcatdev-svr1, orcldb0, mq-dev, joes-dev-box
  3. Testing / UAT: uat-redhat3, uat-rhas7, messageQ-uat1, security-ldap12-DEV
  4. Production: appserver-weblogic-PROD0, orclRAQ-1, mq0, fw0-sec-ldap-bldg6

This of course, necessitates a number of custom configurations for every environment, and depending on your technology, your deployment strategy, and your configuration management , it can quickly and rapidly get either unmanageable, or worse, configuration can be lost, or at least not backed up or documented adequately to enable reconsititution in case of catastrophic failure. What we as developers, often yearn for is a simple scheme like the following:

  1. app-server, database, message-queue, ldap-server

Of course, we sometimes try to map those sorts of schema into the chaotic environment listed above. Then we have custom host-file entries to manage the IP address resolution for us. of course, is this /etc/host file in any sort of configuration management scheme? Usually not. The trick is course, to use the schema as above but /etc/resolv.conf file to force resolution to a default sub-domain, which in the four cases above, are;

  1. developer
  2. integration
  3. uat
  4. prod

Then using either network-based split-segment DNS resolution, or simply a private dns server only visible to resources inside the firewall, to resolve to the relevant sub-domain and thence to the correct IP. But then, there’s the inertia from the infrastructure management, who want to identify machines according to the operating system and the major software brand that’s installed into them, rather than the functional description. Quite apart from the fact that those two schemes can live side by side anyway in a split-segment DNS.

I’m sorry that I don’t have a full solution, I just wish it was easier.

2 Comments

  1. Eric Rizzo wrote:

    My time spent as an application architect at “MegaBank Corporation” taught me that it is a combination of inertia and political empire-building that causes infrastructure/network teams to resist the kind of logical solution you propose here. When I suggested anything similar, the response was almost one of wonderment: after all , what on Earth would an applications guy possibly know about network organization, DNS, logical stucture, etc., right?

    Wednesday, April 8, 2009 at 01:22 | Permalink
  2. admin wrote:

    That’s right. No, our network shouldn’t describe the machine’s functionality, it’s not for the convenience of the system architect or the developers, it’s there for the convenience of the *network admin* staff.

    Next up – having to ask for ports to be opened one-by-one to a *development environment*.

    Wednesday, April 8, 2009 at 06:34 | Permalink