Consul config setting ports with a variable

Hi All,

I am trying to configure Consul (and then after that Nomad) with a ports section in my hcl config file that resolves ENV vars for the values:


ports {
  server = "$SERVER_RPC_PORT"
  serf = "$SERF_LAN_PORT"
  http = "$API_HTTP_PORT"
  https = "$API_HTTPS_PORT"
  dns = "$CONSUL_DNS_PORT"

My problem is that I hit a catch-22 with this config:

  • If I don’t quote the variable references, I get an invalid token error when the parser encounters the ‘$’ in the variable reference.
  • If I do quote the variable reference, then I get a schema error saying the value must be an int.
    ** Sadly, it does not seem to attempt to coerce the string value to an int.

I tried finding the reference info on what other forms of variable interpolation is valid in the hcl files in general, and the ports {} section in particular.

Can anyone please point me to documentation on the suppprted interpolation syntax so I can work out how to resolve my var references?

Kind Regards,

I’m pretty sure there is no interpolation syntax at all, unless I’ve totally missed something in the documentation.

Well, the Consul docs show that go-template interpolcation is supported for at least some values:

bind_addr = "{{ GetPrivateInterfaces | include \"network\" \"\" | attr \"address\" }}"

So I was hoping to find out what other functions and operators were supported by that syntax.

[Removed comment about nomad which referred to job files, and not config files]

I agree that the documentation does not state whether or not variable iterpolation is supported in general for values in the consul config file.

I’m pretty sure that interpolation is not a general feature of the configuration file, but a feature applied after parsing, to the literal string assigned to selected settings of “socket address” type.

Thanks Max - that’s pretty much as I had feared.

Do you think it’s worth raising a feature-request for some form of interpolation of values in the config file?

It doesn’t hurt to ask, but I’d estimate the chances of it actually happening to be low.

I think it could turn out to be surprisingly complicated to work out a way to introduce just enough of the concepts from a more complex dialect of HCL like that used by Terraform, into the config file syntax, without the engineering effort just being too hard for the limited payoff.

After some reading - it would seem that it could be accomplished for HCL config files by switching the config file parser from HCL1 to HCL2.
I’m still not sure about JSON config files.