Cloud auto-join does simplify this for any cloud that is currently supported too. One trick I like to use is multiple config-file options. This enables me to split out the cloud-specific configuration and tends to make provisioning scripts easier since I can bake most of it as a static file in an image, and then add the dynamic elements as one or more separate files.
Click here to see an HCL example.
bootstrap_expect = 3
client_addr = "0.0.0.0"
data_dir = "/opt/consul/data"
datacenter = "dc1"
node_name = "consul-server-1"
server = true
ui = true
enabled = true
default_policy = "deny"
enable_token_persistence = true
enabled = true
enable_truncate = true
"grpc" = 8502
prometheus_retention_time = "1m"
retry_join = ["10.0.2.21", "10.0.2.22", "10.0.2.23"]
retry_join = ["provider=aws region=us-west-1 tag_key=node-role tag_value=consul-server" ]
(These are example tag keys and values.)
With that configuration, for local agents, you could run:
consul agent -config-file=consul.hcl -config-file=join-local.hcl
and for AWS instances:
consul agent -config-file=consul.hcl -config-file=join-aws.hcl
If you selectively deploy the configuration file with the retry_join attribute, you could place them in the same folder and use the
-config-dir flag, rather than multiple
-config-file flags too.
Using multiple configuration files can sure reduce the amount of repeated configuration or post-provisioning manipulation you need to do when you have elements that vary by environment.
Hopefully this helps you or a future reader, because it’s one of my favorite tricks that I think folks overlook.