Add option to use private IPv4 for route53

[lo1tuma]

This option makes it possible to set the private IPv4 address of the instance in the DNS record of route53.

Due to the policies of my company we are not allowed to use public IPs for internal infrastructure servers. That’s why we need to associate private IPs with a route53 hostname.

I’m not sure about the option name. From a user perspective I would probably prefer a single option where you can specify whether to use public ip, private ip or public DNS name but that would be a breaking change, so I decided to introduce a second separate option.

[gilligan]

Some feedback on this would be great.

[spinus]

Actually, I'm pretty surprised that route53 entry is not another resource and it's tied to the machine. Maybe would be better to refactor this? That way you can write you function to map machines to route53 resources.

[lo1tuma]

@spinus Interesting. Could you provide an example how one could bind the IP if route53 would be an resource?

Apart from that, changing route53 to be a resource would also be a breaking change.

[spinus]

{
  resources = {
    r53-zone = {nodes}: {
      # zone-id  (set by NixOps)
      name = "my-zone.com";
      entries = {
         "node1.my-zone.com": nodes.node1.networking.privateIPv4;
         "node2.my-zone.com": nodes.node1.networking.privateIPv4;
       };
    };
  };

I wouldn't break it. Old method can be there or new method can autogenerate config to support old way + generating some "warning" message.

[domenkozar]

cc @rbvermaa

[rbvermaa]

I would love to see route53 as separate resource.

[lo1tuma]

Alright, so I think the suggestions for having route53 as a separate resource makes sense. Unfortunately I’m not really fluent in python so I’m not sure if I can implement the necessary changes.

So if somebody else wants to take over, please do so. Otherwise it would be nice if you could give me some guidance.

[spinus]

Mathias,

I would say, the first step could be just copy paste some existing AWS
resource, let's say key (python files + nix files), change name to route53,
then adjust data structure (first in nix, adjust field names etc, then
adjust in python to read correct values from XML generated by nix) and then
adjust calls in python to hit route53 endpoints instead of keys endpoints
(boto library calls).

I could help if you need more details.

2016-07-22 11:36 GMT+01:00 Mathias Schreck notifications@github.com:

Alright, so I think the suggestions for having route53 as a separate
resource makes sense. Unfortunately I’m not really fluent in python so I’m
not sure if I can implement the necessary changes.

So if somebody else wants to take over, please do so. Otherwise it would
be nice if you could give me some guidance.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#469 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA6CD09vBMVOO4fJX3XC3tRoDlC5LyBbks5qYJ0ogaJpZM4JNZEu
.

Tomasz Czyż

[roberth]

The suggested improvement seems to be a duplicate of #527.
I would suggest merging this (or my duplicate PR #630) and to continue work on making route53 machine-independent in the context of #527.

[rbvermaa]

Is this PR still WIP, if not, I suggest removing the WIP from the title.

[lo1tuma]

@rbvermaa The changes are functional and we actually use this for one project since several months.
What is missing would be a unit/integration test which I don’t know how to write because im quite unfamiliar with python.
I also haven’t implemented the change to make route53 a separate resource, but this could also be done after merging this.

[domenkozar]

The duplicated PR https://github.com/NixOS/nixops/pull/630/files has two improvements over this one that I think could be incorporated for this PR to be merged:

1. better error handling (double if/else logic)

2. mentions that Private Hosted DNS zones needs to be used with this option

[gilligan]

So @lo1tuma and me would be fine with using the changes of #630 instead of this one but the problem of turning this into a resource remains ;-) Need help with that.

[lo1tuma]

Closing in favor of #753.

[lo1tuma]

After testing the resource approach from #753 I’m now unsure if the approach works at all. The private IP gets assigned automatically at deploy-time and is not a static configuration. So I currently don’t see a way how to get this IP in the resource. The example from @spinus doesn’t work because nodes.node1.networking.privateIPv4 doesn’t exist.
In order to achieve this we would need to deploy the instance before we create the resource and pass-through concrete details from the deployed instance to the resource.

I guess this is also the reason why route53 is currently bound to the deployment of the machine instead of being a separate resource.

[alexhumphreys]

What's the status of this issue?

In #753 @rbvermaa mentions a route53 branch that should get merged soon. Did that happen?

If you need some support with this issue I'd like to try to help.

[domenkozar]

I took a very quick look today and seems like publicIPv4 = v.config.networking.publicIPv4 needs acompanying line in nix/eval-machine-info.nix for the standalone record set to work - still would need to verify that.

[domenkozar]

I've merged 0dbb6b3 as it has been three years and having the option to set the private DNS entry is reasonable one :)