dynamic scaling with proper hostname/domainname scheme about opsworks-cookbooks HOT 7 CLOSED

Hi @m0crack. Thanks for reporting the problem.

Currently no property to set the domain name of a host exists. OpsWorks supports setting the domain name for certain applications (Apache, NGinx), but not for the host itself.

Could you provide more details on your use-case?

Best,
Jens

from opsworks-cookbooks.

we love DNS. we like having consistent, friendly, meaningful names on servers. our helpdesk guys will go insane having to first find an ip address of the instance(console or cli), in order to ssh into it. they'll go doubly insane because if they have more than one ssh session open because their window title names and bash prompts will be worthless. how do you remember that host ip-192.168.204.21 is a web server in layer1, under stack 1?

what we want is the ability to configure an instance to come up with a consistent, predictable, customizable, fully qualified domain name. let's say you create a subdomain for all your amazon ec2 instances, amazon.example.com. if you fire up a third web layer instance in stack 7, you'd know it's DNS name would be web3.stack7.amazon.example.com. if you use bash as a shell, now all sorts of fun things are possible with \h or \H in your PS1 prompt, or even in your window title.

i've tried doing this in chef. it's breaks chef. on first run, my hostname is web1.localdomain. on it's subsequent runs, it'll fail because the first run changed its hostname/node name to web1.stack1.amazon.example.com.

i can think of a few options.

1. fix the hostname before chef runs. you need access to the custom json that is used in the creation of the instance. the utility opsworks-agent-cli should do the trick. the question is, when does that populate? i ran it from a rc.local script and it errors out that it's empty. can you access this after it's populated but before chef runs? if so, where and how?
2. make chef re-register after it's first run. this option feels like a bad idea. it seems like it would add an unneeded registration (as the original web1.localdomain). your time-to-run has now doubled because chef now runs 4 times instead of 2 (setup and configure times 2).

hopefully this gives you a clearer picture as to what we're trying to accomplish. thanks for your help!

from opsworks-cookbooks.

I think that all of the above should be possible when you override the hosts.erb in a recipe that is triggered on setup. Once the full hostname (incl. domain) is set, it will be present on the next Chef run - which would be the configure event.

So the features you describe should be possible with OpsWorks today. What concrete issues are you facing? Especially I would be interested in details, why running configure with "localdomain" and setup with "yourdomain.com" breaks for you.

I can see, that setting the domain name in OpsWorks (e.g. as a Stack property) would be the more straight forward solution. Unfortunately this option is not available in OpsWorks at the moment, but has been taken note of in the backlog.

from opsworks-cookbooks.

It sounds to me you want integration with Route53. Overriding the hosts template alone will only make the DNS resolution work on each EC2 instance. But it will not make it work on your developer machines for SSH access.

What you can do is have a custom Chef cookbook that registers an instance with Route53 on 'setup' and de-registers it on 'shutdown'. That will have the effect you're after.

from opsworks-cookbooks.

thanks for the replies. as jbraeuer mentioned, using a custom host.erb file is part of the solution. it's not perfect because there isn't a mechanism to pass more than just the host name between the opsworks and chef. as a "workaround", providing a custom chef cookbook per stack we create will do the same thing.

so, all we did we customized line 18 in hosts.erb to:

<%= Resolv.getaddress(instance_config[:private_ip]) %> <%= instance_name %>.stackname.amazon.example.net <%= instance_name %>

and jweiss is correct in that the remaining piece is to get the newly spun up client to do a DDNS registration.

thanks for you help!

from opsworks-cookbooks.

I will close the issue. Please feel free to re-open it, if you have further questions.

Best,
Jens

from opsworks-cookbooks.

I was hung on a similar issue - I was looking to use Chef host-based files and templates, which are interpreted based on FQDN. Since all my instances had the domain-name of "localdomain", I was unable to use the same cookbook for different environments based on their domain names (since both staging and production app-server-1 would have the FQDN of app-server-1.localdomain instead of app-server-1.stage and app-server-1.prod). I've tried setting the name in hosts.erb, which does set hostname and domain name fine eventually, but does not suffice for Chef for host-based cookbooks.

The workaround I found was to use the environment name in the hostname (and not the domain name). This way I can have host-based files/templates for both app-server-1-prod.localdomain and app-server-1-stage.localdomain in the same cookbook (instead of a cookbook per stack as @m0crack suggested).

At the same time, I'm unsure why is it so challenging to use a domain-name that would be recognized by Chef in OpsWorks... Perhaps I'm missing something basic?

from opsworks-cookbooks.