refactor: move server config from command flags to configmap

[ishustava]

Changes proposed in this PR:
Move as much of the server config into config map as possible. Things that could not be moved into config maps are flags that contain env variables and that are being scripted inside the command (e.g. DNS recursors).

The motivation for this change is to make the configuration more readable and consolidate it in one place as much as possible. For historical context, we were not doing that from the beginning because when you update the config map, the server stateful set would not be automatically updated and so we were using command flags instead to ensure that servers will be restarted. However, this has changed with hashicorp/consul-helm#550, but we never went back and updated it.

This change could be easier to read via commits:

• refactor: move server TLS config to configmap
• refactor: consolidate all ui config into server configmap
• Use single DNS name for server's retry-join
• refactor: move general server config from cmd flags to configmap
• refactor: move recursors to server configmap
• refactor: move server connect wan fed config to configmap
• refactor: move server telemetry config to configmap

Note: the client configmap and flags will be potentially updated in a future PR

How I've tested this PR:

• unit & acceptance tests
• some manual testing to ensure that servers get rolled when configmap changes

How I expect reviewers to test this PR:
👀

Checklist:

• Tests added
• CHANGELOG entry added

  HashiCorp engineers only, community PRs should not add a changelog entry.
  Entries should use present tense (e.g. Add support for...)

[jmurret]

Nice! What is the glue that binds these config maps to where consul reads them? Does the config-checksum annotation lay these out similar to having .json files in the -config-dir?

[jmurret]

👏

[ishustava]

What is the glue that binds these config maps to where consul reads them?

Configmap is mounted as a volume to pods (similar to secrets):

consul-k8s/charts/consul/templates/server-statefulset.yaml

Lines 130 to 132 in a713f85

	- name: config
	configMap:
	name: {{ template "consul.fullname" . }}-server-config

consul-k8s/charts/consul/templates/server-statefulset.yaml

Lines 363 to 364 in a713f85

	- name: config
	mountPath: /consul/config

All files from the configmap will be in that /consul/config directory we mount to the server pod. So by default it will be:

/consul/consul-config:
- server.json
- central-config.json
- ui-config.json
etc

Then we pass the entire config dir to consul via -config-dir flag:

consul-k8s/charts/consul/templates/server-statefulset.yaml

Line 305 in a713f85

-config-dir=/consul/config \

Consul will consume all files in alphabetical order and merge them all into one configuration.

Does the config-checksum annotation lay these out similar to having .json files in the -config-dir?

The config-checksum is there to detect that update server statefulset when configmap changes. For example, let's say you had an installation without TLS and now you want to enable TLS.

Without this annotation, if you run helm upgrade consul --set global.tls.enabled=true hashicorp/consul, it will just update the configmap, but the user will have to upgrade the servers themselves to apply the configmap changes.

With an annotation, when run helm upgrade, the checksum of the configmap will change and so the helm upgrade will need to update the checksum annotation on your server statefulset pods, which will trigger a restart of the pods.

[jmurret]

@ishustava Thank you. This is cool.

[ndhanushkodi]

This looks great! The commit by commit readability made it so nice to review!