Retry_join on configuration files

Hello everyone,

I am confuse about “retry_join” arguments, I have 3 Consul servers (A,B,C) and 3 Consul clients (D,E,F).

  1. When I config retry_join on Consul server do I need to include Consul client? like “retry_join=[A,B,C,D,E,F]” or just Consul server “retry_join=[A,B,C]”
  2. When I config retry_join on Consul client do I need to include Consul client? like “retry_join=[A,B,C,D,E,F]” or just Consul server “retry_join=[A,B,C]”

-retry-join - Similar to -join but allows retrying a join until it is successful. Once it joins successfully to a member in a list of members it will never attempt to join again. Agents will then solely maintain their membership via gossip. This is useful for cases where you know the address will eventually be available. This option can be specified multiple times to specify multiple agents to join.

So no matter on server or client, configurate both IP in retry_join, then Consul can solely maintain it self via gossip.
Many thanks.

@Wolfsrudel What are the best practices with let’s say a cluster of 3 server nodes? What should retry_join normally - by common sense - contain? The IPs of the other two nodes, for example?

I would do that, yes.

1 Like

What if you wanted to avoid hardcoding to IPs? Would that be possible? Would the gossip protocol be enough for the nodes to find one another if they have the right token/datacenter/ACLs?

There is a auto join for the could:

For on-prem you could use DNS instead of IPs.

Would auto-join work through cloud-init using the openstack configuration? So basically for any cloud-init provisionied VM?

The thing is I want to start start with consul basically, which is going to provide DNS for the LAN. So it’s a recursive issue, of course :slight_smile:

Hi @lethargosapatheia,

It might be possible to come up with a workflow that populates the retry_join addresses based off of data injected into the instance over cloud-init.

For example, you a valid workflow might be using cloud-init’s write_files directive to write a JSON file into /etc/consul.d/retry-join-hosts.json that contains the retry_join directive with the addresses of other servers in your network.

write_files:
- path: /etc/consul.d/retry-join-config.hcl
  owner: consul:consul
  permissions: '0640'
  content: |
    retry_join = ["192.0.2.10", 192.0.2.20", 192.0.2.30"]

A better solution would be to use the OpenStack provider that is natively available in cloud-auto-join. The documentation for this can be found at https://www.consul.io/docs/install/cloud-auto-join#openstack.

So you think the openstack provider would work even if I don’t actually use openstack?

I did try that at some point and it kept trying to connect to a http server available on 169.254.x.x, which openstack might provide by default, I’m guessing? I’m not sure how you’re supposed to provision that only using cloud-init and making it believe that you use openstack (if that’s what you were thinking about also).