Expose tagged addresses

[deltaroe]

tagged address support has been added to consul as of 0.6.4. Would love to see it exposed in consul-template. Most of the time the translate_wan_addresess feature will handle exposing the right address, but I have one use case where both lan and wan addresses are needed.

I can put together a PR, but my go is not strong and I don't need it right away so if someone gets to it first that would be great.

[slackpad]

Don't have time to work on this immediately but this is a good idea!

[sethvargo]

Hey @slackpad

Can you link me to the API for this? I don't see it documented on consul.io.

[slackpad]

@sethvargo it's the TaggedAddresses map under the Node record that has the info (see an example here). The weird thing I just realized is that translate_wan_addrs only applies to DNS, so there's no way CT would know if this is set or not. I think we'd need expose this as a new CT option that's independent of what's set on the Consul agent, which feels a little weird. Need to think on this little to see if it makes sense to try to have CT match the agent's setting somehow.

[alexef]

@deltaroe is there currently a way to expose the wan address of a node inside a consul template?

Let's say we have node in dc1, with two different ip addresses. Imagine this template on a node in dc2:

{{ range service "myservice@dc1" }}
server {{.Node}} {{.Address}}:{{.Port}}{{ end }}

I've tried using {{.Address}}, {{.NodeAddress}}, turning translate_wan_addrs on both dc1 and dc2, but with no success: I'm always getting the private address which cannot be accessed within dc2.

[deltaroe]

@alexef not that I know of right now. Based on the previous comments it looks like there was a hangup in deciding if consul-template should redo the wan translation logic itself or to push it into consul itself to do the translation centrally.

In my case I just wanted the raw untranslated value and I was going to do the translation elsewhere. The raw value is in the response consul gives to consul-template, but consul-template doesn't expose it as far as I could tell. It's not been a blocker to me yet, but will be shortly. Exposing the raw attribute looks easy enough and if it does become a blocker I'll see if my limited go knowledge will be useful enough to get the raw value at least added. The translation logic you're looking for is a different issue

[alexef]

Thank you so much @deltaroe for the insight.

For the record, I'm currently exploring this hack: setting the wan address on the service definition as a tag, then parsing the tag in the template (feels like sharpening an arrow with a stone):

{
   ...
   "tags": {
     "testing",
     "wan:54.29.105.1" 
   }
 }

 {{ range service "myservice@dc1" }}
     server {{.Node}}
     {{ range .Tags }}
          {{ $tagType := index (. | split ":") 0 }}
          {{ if eq $tagType "wan" }}
              {{ index (. | split ":") 1 }}
          {{ end }}
     {{ end }}
     :{{.Port}}
 {{ end }}

I have zero go skills yet, but I'll follow up the discussion here and try to help as much as I can.

[deltaroe]

Decided to take a stab at this, but pretty quickly hit a wall that the go consul api doesn't expose the taggedaddresses attribute. It's in the HTTP API, just hasn't been exposed further. I think I'm going to take the approach @alexef did rather than proceed.

[slackpad]

Update on this one - hashicorp/consul#2275 will make Consul translate addresses internally, so consul-template will "just work" for the most common use case where you want the addresses translated in your templates.

I'll get the tagged addresses exposed under hashicorp/consul#2273, and add a new "lan" tag so you can get the raw LAN address even under the above change, and then it should be possible to get all the addresses under consul-template.

[slackpad]

The upstream changes are now in - hashicorp/consul#2280.

[sethvargo]

Thanks @slackpad - I'm not seeing how this will "just work" though? Do we need to set that header somewhere?

[slackpad]

I can do the CT side when I get a chance here in a bit. If your agent is configured with translate_wan_addrs and running Consul 0.7 or later then CT will see the proper WAN or LAN addresses as appropriate, with no changes to CT.

For people who want to do something special with tagged addresses, I think we can expose them in the template language directly, so you can get at TaggedAddresses["wan"] in your template. I don't think we will need to look at the header for CT.

[sethvargo]

#748

[shakisha]

@sethvargo @slackpad i think this part it is totally missing on consul-template documentation, right?

[shakisha]

{{range service "consul@de01"}}
-A INPUT -s {{.TaggedAddresses["wan"]}} -p tcp -m tcp --dport 22 -j ACCEPT {{end}}

gives me

parse: template: :20: unexpected bad character U+005B '[' in command

-A INPUT -s {{.TaggedAddresses "wan"}} -p tcp -m tcp --dport 22 -j ACCEPT {{end}}

gives me

execute: template: :20:14: executing "" at <.TaggedAddresses>: can't evaluate field TaggedAddresses in type *dependency.HealthService

[sethvargo]

Hi @deltaroe

Please read the documentation on Go's templating format. You can find the link to it in the README under the "Templating Language" section. That documentation has examples for accessing values in a map.

https://github.com/hashicorp/consul-template#templating-language

[shakisha]

@sethvargo
can you make a me an example with "TaggedAddresses"?
Only one, because documentation did not help me, i've read it entire night and today also

[shakisha]

@sethvargo I'm still not able to understand how to do this, on Go Documentation it is too hard to catch it.
I'm not a Golang expert and some examples in the documentation about this (or at least a better reference) it's appreciated

[vasekboch]

{{ range service "whoami" }}
http://{{ .NodeTaggedAddresses.lan }}:{{ .Port }}
{{ end }}

[imbdb]

For taggedaddresses in particular service use ServiceTaggedAddresses

{{ range service "whoami" }}
http://{{ .ServiceTaggedAddresses.lan }}:{{ .Port }}
{{ end }}

[eikenb]

@imbdb, @vasekboch ... Thanks for adding the examples.

I just added an example of using the ServiceTaggedAddresses to the official docs. Hopefully it will help more people figure this out.