Configuration Entries

    Outside of Kubernetes, configuration entries can be specified in HCL or JSON using either or CamelCase for key names. On Kubernetes, configuration entries can be managed by custom resources in YAML.

    Outside of Kubernetes, every configuration entry specified in HCL or JSON has at least two fields: Kind and Name. Those two fields are used to uniquely identify a configuration entry. Configuration entries specified as HCL or JSON objects use either snake_case or CamelCase for key names.

    Example config specified outside of Kubernetes

    1. Kind = "<supported kind>"
    2. Name = "<name of entry>"

    On Kubernetes, Kind is set as the custom resource kind and Name is set as metadata.name:

    1. apiVersion: consul.hashicorp.com/v1alpha1
    2. kind: <supported kind>
    3. metadata:
    4.   name: <name of entry>

    Example config specified on Kubernetes

    1. apiVersion: consul.hashicorp.com/v1alpha1
    2. kind: <supported kind>
    3. metadata:
    4.   name: <name of entry>

    See Service Mesh - Config Entries for the list of supported config entries.

    See .

    Creating or Updating a Configuration Entry

    The command is used to create and update configuration entries. This command will load either a JSON or HCL file holding the configuration entry definition and then will push this configuration to Consul.

    Example HCL Configuration File:

    1. Name = "global"
    3.    local_connect_timeout_ms = 1000
    4.    handshake_timeout_ms = 10000
    5. }

    proxy-defaults.hcl

    1. Kind = "proxy-defaults"
    2. Name = "global"
    3. Config {
    4.    local_connect_timeout_ms = 1000
    5.    handshake_timeout_ms = 10000
    6. }

    Then to apply this configuration, run:

    1. $ consul config write proxy-defaults.hcl

    If you need to make changes to a configuration entry, simple edit that file and then rerun the command. This command will not output anything unless there is an error in applying the configuration entry. The write command also supports a -cas option to enable performing a compare-and-swap operation to prevent overwriting other unknown modifications.

    Reading a Configuration Entry

    The command is used to read the current value of a configuration entry. The configuration entry will be displayed in JSON form which is how its transmitted between the CLI client and Consul’s HTTP API.

    1. $ consul config read -kind service-defaults -name web
    2. {
    3.    "Kind": "service-defaults",
    4.    "Name": "web",
    5.    "Protocol": "http"
    6. }
    1. $ consul config read -kind service-defaults -name web
    2. {
    4.    "Protocol": "http"
    5. }

    Listing Configuration Entries

    The command is used to list out all the configuration entries for a given kind.

    Example:

    1. $ consul config list -kind service-defaults
    2. web
    3. api
    4. db
    1. $ consul config list -kind service-defaults
    2. web
    3. api
    4. db

    Deleting Configuration Entries

    The command is used to delete an entry by specifying both its kind and name.

    Example:

    1. $ consul config delete -kind service-defaults -name web

    This command will not output anything when the deletion is successful.

    Configuration Entry Management with Namespaces

    Enterprise

    Configuration entry operations support passing a namespace in order to isolate the entry to affect only operations within that namespace. This was added in Consul 1.7.0.

    1. $ consul config write service-defaults.hcl -namespace foo
    1. $ consul config write service-defaults.hcl -namespace foo
    1. $ consul config list -kind service-defaults -namespace foo
    2. web
    3. api
    1. $ consul config list -kind service-defaults -namespace foo
    2. web
    3. api

    Bootstrapping From A Configuration File

    Configuration entries can be bootstrapped by adding them inline to each Consul server’s configuration file. When a server gains leadership, it will attempt to initialize the configuration entries. If a configuration entry does not already exist outside of the servers configuration, then it will create it. If a configuration entry does exist, that matches both and name, then the server will do nothing.