565 lines
31 KiB
Plaintext
565 lines
31 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Agents - CLI Reference
|
|
description: >-
|
|
Add flags to the `consul agent` command to configure agent properties and actions from the CLI. Learn about configurable options and how to format them with examples.
|
|
---
|
|
|
|
# Agents Command-line Reference ((#commandline_options))
|
|
|
|
-> **Note:** Some CLI arguments may be different from HCL keys. See [Configuration Key Reference](/consul/docs/agent/config/config-files#config_key_reference) for equivalent HCL Keys.
|
|
|
|
This topic describes the available command-line options for the Consul agent.
|
|
|
|
## Usage
|
|
|
|
See [Agent Overview](/consul/docs/agent#starting-the-consul-agent) for examples of how to use flags with the `consul agent` CLI.
|
|
|
|
## Environment Variables
|
|
|
|
Environment variables **cannot** be used to configure the Consul client. They
|
|
_can_ be used when running other `consul` CLI commands that connect with a
|
|
running agent, e.g. `CONSUL_HTTP_ADDR=192.168.0.1:8500 consul members`.
|
|
|
|
See [Consul Commands](/consul/commands#environment-variables) for more
|
|
information.
|
|
|
|
## General
|
|
|
|
- `-auto-reload-config` ((#\_auto_reload_config)) - This option directs Consul to automatically reload the [reloadable configuration options](/consul/docs/agent/config#reloadable-configuration) when configuration files change.
|
|
Consul also watches the certificate and key files specified with the `cert_file` and `key_file` parameters and reloads the configuration if the files are updated.
|
|
|
|
- `-check_output_max_size` - Override the default
|
|
limit of 4k for maximum size of checks, this is a positive value. By limiting this
|
|
size, it allows to put less pressure on Consul servers when many checks are having
|
|
a very large output in their checks. In order to completely disable check output
|
|
capture, it is possible to use [`discard_check_output`](/consul/docs/agent/config/config-files#discard_check_output).
|
|
|
|
- `-client` ((#\_client)) - The address to which Consul will bind client
|
|
interfaces, including the HTTP and DNS servers. By default, this is "127.0.0.1",
|
|
allowing only loopback connections. In Consul 1.0 and later this can be set to
|
|
a space-separated list of addresses to bind to, or a [go-sockaddr]
|
|
template that can potentially resolve to multiple addresses.
|
|
|
|
<CodeBlockConfig hideClipboard heading="Bind consul client interfaces to private IPv4 interfaces">
|
|
|
|
```shell
|
|
$ consul agent -dev -client '{{ GetPrivateInterfaces | exclude "type" "ipv6" | join "address" " " }}'
|
|
```
|
|
|
|
</CodeBlockConfig>
|
|
|
|
<CodeBlockConfig hideClipboard heading="Bind consul client interfaces to private IP addresses and loopback">
|
|
|
|
```shell
|
|
$ consul agent -dev -client '{{ GetPrivateInterfaces | join "address" " " }} {{ GetAllInterfaces | include "flags" "loopback" | join "address" " " }}'
|
|
```
|
|
|
|
</CodeBlockConfig>
|
|
|
|
<CodeBlockConfig hideClipboard heading="Exclude private interfaces that start with 'br-'">
|
|
|
|
```shell
|
|
$ consul agent -dev -client '{{ GetPrivateInterfaces | exclude "name" "br.*" | join "address" " " }}'
|
|
```
|
|
|
|
</CodeBlockConfig>
|
|
|
|
- `-data-dir` ((#\_data_dir)) - This flag provides a data directory for
|
|
the agent to store state. This is required for all agents. The directory should
|
|
be durable across reboots. This is especially critical for agents that are running
|
|
in server mode as they must be able to persist cluster state. Additionally, the
|
|
directory must support the use of filesystem locking, meaning some types of mounted
|
|
folders (e.g. VirtualBox shared folders) may not be suitable.
|
|
|
|
**Note:** both server and non-server agents may store ACL tokens in the state in this directory so read access may grant access to any tokens on servers and to any tokens used during service registration on non-servers. On Unix-based platforms the files are written with 0600 permissions so you should ensure only trusted processes can execute as the same user as Consul. On Windows, you should ensure the directory has suitable permissions configured as these will be inherited.
|
|
|
|
- `-datacenter` ((#\_datacenter)) - This flag controls the datacenter in
|
|
which the agent is running. If not provided, it defaults to "dc1". Consul has first-class
|
|
support for multiple datacenters, but it relies on proper configuration. Nodes
|
|
in the same datacenter should be on a single LAN.
|
|
|
|
- `-dev` ((#\_dev)) - Enable development server mode. This is useful for
|
|
quickly starting a Consul agent with all persistence options turned off, enabling
|
|
an in-memory server which can be used for rapid prototyping or developing against
|
|
the API. In this mode, [Connect is enabled](/consul/docs/connect/configuration) and
|
|
will by default create a new root CA certificate on startup. This mode is **not**
|
|
intended for production use as it does not write any data to disk. The gRPC port
|
|
is also defaulted to `8502` in this mode.
|
|
|
|
- `-disable-keyring-file` ((#\_disable_keyring_file)) - If set, the keyring
|
|
will not be persisted to a file. Any installed keys will be lost on shutdown, and
|
|
only the given `-encrypt` key will be available on startup. This defaults to false.
|
|
|
|
- `-enable-script-checks` ((#\_enable_script_checks)) This controls whether
|
|
[health checks that execute scripts](/consul/docs/services/usage/checks) are enabled on this
|
|
agent, and defaults to `false` so operators must opt-in to allowing these. This
|
|
was added in Consul 0.9.0.
|
|
|
|
~> **Security Warning:** Enabling script checks in some configurations may
|
|
introduce a remote execution vulnerability which is known to be targeted by
|
|
malware. We strongly recommend `-enable-local-script-checks` instead. See [this
|
|
blog post](https://www.hashicorp.com/blog/protecting-consul-from-rce-risk-in-specific-configurations)
|
|
for more details.
|
|
|
|
- `-enable-local-script-checks` ((#\_enable_local_script_checks))
|
|
Like [`-enable-script-checks`](#_enable_script_checks), but only enable them when
|
|
they are defined in the local configuration files. Script checks defined in HTTP
|
|
API registrations will still not be allowed.
|
|
|
|
- `-encrypt` ((#\_encrypt)) - Specifies the secret key to use for encryption
|
|
of Consul network traffic. This key must be 32-bytes that are Base64-encoded. The
|
|
easiest way to create an encryption key is to use [`consul keygen`](/consul/commands/keygen).
|
|
All nodes within a cluster must share the same encryption key to communicate. The
|
|
provided key is automatically persisted to the data directory and loaded automatically
|
|
whenever the agent is restarted. This means that to encrypt Consul's gossip protocol,
|
|
this option only needs to be provided once on each agent's initial startup sequence.
|
|
If it is provided after Consul has been initialized with an encryption key, then
|
|
the provided key is ignored and a warning will be displayed.
|
|
|
|
- `-grpc-port` ((#\_grpc_port)) - the gRPC API port to listen on. Default
|
|
-1 (gRPC disabled). See [ports](/consul/docs/agent/config#ports-used) documentation for more detail.
|
|
|
|
- `-hcl` ((#\_hcl)) - A HCL configuration fragment. This HCL configuration
|
|
fragment is appended to the configuration and allows to specify the full range
|
|
of options of a config file on the command line. This option can be specified multiple
|
|
times. This was added in Consul 1.0.
|
|
|
|
- `-http-port` ((#\_http_port)) - the HTTP API port to listen on. This overrides
|
|
the default port 8500. This option is very useful when deploying Consul to an environment
|
|
which communicates the HTTP port through the environment e.g. PaaS like CloudFoundry,
|
|
allowing you to set the port directly via a Procfile.
|
|
|
|
- `-https-port` ((#\_https_port)) - the HTTPS API port to listen on. Default
|
|
-1 (https disabled). See [ports](/consul/docs/agent/config#ports-used) documentation for more detail.
|
|
|
|
- `-default-query-time` ((#\_default_query_time)) - This flag controls the
|
|
amount of time a blocking query will wait before Consul will force a response.
|
|
This value can be overridden by the `wait` query parameter. Note that Consul applies
|
|
some jitter on top of this time. Defaults to 300s.
|
|
|
|
- `-max-query-time` ((#\_max_query_time)) - this flag controls the maximum
|
|
amount of time a blocking query can wait before Consul will force a response. Consul
|
|
applies jitter to the wait time. The jittered time will be capped to this time.
|
|
Defaults to 600s.
|
|
|
|
- `-pid-file` ((#\_pid_file)) - This flag provides the file path for the
|
|
agent to store its PID. This is useful for sending signals (for example, `SIGINT`
|
|
to close the agent or `SIGHUP` to update check definitions) to the agent.
|
|
|
|
- `-protocol` ((#\_protocol)) - The Consul protocol version to use. Consul
|
|
agents speak protocol 2 by default, however agents will automatically use protocol > 2 when speaking to compatible agents. This should be set only when [upgrading](/consul/docs/upgrading). You can view the protocol versions supported by Consul by running `consul version`.
|
|
|
|
- `-raft-protocol` ((#\_raft_protocol)) - This controls the internal version
|
|
of the Raft consensus protocol used for server communications. This must be set
|
|
to 3 in order to gain access to Autopilot features, with the exception of [`cleanup_dead_servers`](/consul/docs/agent/config/config-files#cleanup_dead_servers). Defaults to 3 in Consul 1.0.0 and later (defaulted to 2 previously). See [Raft Protocol Version Compatibility](/consul/docs/upgrading/upgrade-specific#raft-protocol-version-compatibility) for more details.
|
|
|
|
- `-segment` ((#\_segment)) <EnterpriseAlert inline /> - This flag is used to set
|
|
the name of the network segment the agent belongs to. An agent can only join and
|
|
communicate with other agents within its network segment. Ensure the [join
|
|
operation uses the correct port for this segment](/consul/docs/enterprise/network-segments/create-network-segment#configure-clients-to-join-segments).
|
|
Review the [Network Segments documentation](/consul/docs/enterprise/network-segments/create-network-segment)
|
|
for more details. By default, this is an empty string, which is the `<default>`
|
|
network segment.
|
|
|
|
~> **Warning:** The `segment` flag cannot be used with the [`partition`](/consul/docs/agent/config/config-files#partition-1) option.
|
|
|
|
## Advertise Address Options
|
|
|
|
- `-advertise` ((#\_advertise)) - The advertise address is used to change
|
|
the address that we advertise to other nodes in the cluster. By default, the [`-bind`](#_bind)
|
|
address is advertised. However, in some cases, there may be a routable address
|
|
that cannot be bound. This flag enables gossiping a different address to support
|
|
this. If this address is not routable, the node will be in a constant flapping
|
|
state as other nodes will treat the non-routability as a failure. In Consul 1.1.0 and later this can be dynamically defined with a [go-sockaddr]
|
|
template that is resolved at runtime.
|
|
|
|
<CodeBlockConfig heading="Using a static network interface name">
|
|
|
|
```shell-session
|
|
$ consul agent -advertise '{{ GetInterfaceIP "eth0" }}'
|
|
```
|
|
|
|
</CodeBlockConfig>
|
|
|
|
- `-advertise-wan` ((#\_advertise-wan)) - The advertise WAN address is used
|
|
to change the address that we advertise to server nodes joining through the WAN.
|
|
This can also be set on client agents when used in combination with the [`translate_wan_addrs`](/consul/docs/agent/config/config-files#translate_wan_addrs) configuration option. By default, the [`-advertise`](#_advertise) address
|
|
is advertised. However, in some cases all members of all datacenters cannot be
|
|
on the same physical or virtual network, especially on hybrid setups mixing cloud
|
|
and private datacenters. This flag enables server nodes gossiping through the public
|
|
network for the WAN while using private VLANs for gossiping to each other and their
|
|
client agents, and it allows client agents to be reached at this address when being
|
|
accessed from a remote datacenter if the remote datacenter is configured with [`translate_wan_addrs`](/consul/docs/agent/config/config-files#translate_wan_addrs). In Consul 1.1.0 and later this can be dynamically defined with a [go-sockaddr]
|
|
template that is resolved at runtime.
|
|
|
|
## Address Bind Options
|
|
|
|
- `-bind` ((#\_bind)) - The address that should be bound to for internal
|
|
cluster communications. This is an IP address that should be reachable by all other
|
|
nodes in the cluster. By default, this is "0.0.0.0", meaning Consul will bind to
|
|
all addresses on the local machine and will [advertise](#_advertise)
|
|
the private IPv4 address to the rest of the cluster. If there are multiple private
|
|
IPv4 addresses available, Consul will exit with an error at startup. If you specify
|
|
`"[::]"`, Consul will [advertise](#_advertise) the public
|
|
IPv6 address. If there are multiple public IPv6 addresses available, Consul will
|
|
exit with an error at startup. Consul uses both TCP and UDP and the same port for
|
|
both. If you have any firewalls, be sure to allow both protocols. In Consul 1.1.0 and later this can be dynamically defined with a [go-sockaddr]
|
|
template that must resolve at runtime to a single address. Some example templates:
|
|
|
|
<CodeBlockConfig heading="Using address within a specific CIDR">
|
|
|
|
```shell-session
|
|
$ consul agent -bind '{{ GetPrivateInterfaces | include "network" "10.0.0.0/8" | attr "address" }}'
|
|
```
|
|
|
|
</CodeBlockConfig>
|
|
|
|
<CodeBlockConfig heading="Using a static network interface name">
|
|
|
|
```shell-session
|
|
$ consul agent -bind '{{ GetInterfaceIP "eth0" }}'
|
|
```
|
|
|
|
</CodeBlockConfig>
|
|
|
|
<CodeBlockConfig heading="Using regular expression matching for network interface name that is forwardable and up">
|
|
|
|
```shell-session
|
|
$ consul agent -bind '{{ GetAllInterfaces | include "name" "^eth" | include "flags" "forwardable|up" | attr "address" }}'
|
|
```
|
|
|
|
</CodeBlockConfig>
|
|
|
|
- `-serf-wan-bind` ((#\_serf_wan_bind)) - The address that should be bound
|
|
to for Serf WAN gossip communications. By default, the value follows the same rules
|
|
as [`-bind` command-line flag](#_bind), and if this is not specified, the `-bind`
|
|
option is used. This is available in Consul 0.7.1 and later. In Consul 1.1.0 and later this can be dynamically defined with a [go-sockaddr]
|
|
template that is resolved at runtime.
|
|
|
|
- `-serf-lan-bind` ((#\_serf_lan_bind)) - The address that should be bound
|
|
to for Serf LAN gossip communications. This is an IP address that should be reachable
|
|
by all other LAN nodes in the cluster. By default, the value follows the same rules
|
|
as [`-bind` command-line flag](#_bind), and if this is not specified, the `-bind`
|
|
option is used. This is available in Consul 0.7.1 and later. In Consul 1.1.0 and later this can be dynamically defined with a [go-sockaddr]
|
|
template that is resolved at runtime.
|
|
|
|
## Bootstrap Options
|
|
|
|
- `-bootstrap` ((#\_bootstrap)) - This flag is used to control if a server
|
|
is in "bootstrap" mode. It is important that no more than one server **per** datacenter
|
|
be running in this mode. Technically, a server in bootstrap mode is allowed to
|
|
self-elect as the Raft leader. It is important that only a single node is in this
|
|
mode; otherwise, consistency cannot be guaranteed as multiple nodes are able to
|
|
self-elect. It is not recommended to use this flag after a cluster has been bootstrapped.
|
|
|
|
- `-bootstrap-expect` ((#\_bootstrap_expect)) - This flag provides the number
|
|
of expected servers in the datacenter. Either this value should not be provided
|
|
or the value must agree with other servers in the cluster. When provided, Consul
|
|
waits until the specified number of servers are available and then bootstraps the
|
|
cluster. This allows an initial leader to be elected automatically. This cannot
|
|
be used in conjunction with the legacy [`-bootstrap`](#_bootstrap) flag. This flag
|
|
requires [`-server`](#_server) mode.
|
|
|
|
## Configuration File Options
|
|
|
|
- `-config-file` ((#\_config_file)) - A configuration file to load. For
|
|
more information on the format of this file, read the [Configuration Files](/consul/docs/agent/config/config-files)
|
|
section. This option can be specified multiple times to load multiple configuration
|
|
files. If it is specified multiple times, configuration files loaded later will
|
|
merge with configuration files loaded earlier. During a config merge, single-value
|
|
keys (string, int, bool) will simply have their values replaced while list types
|
|
will be appended together.
|
|
|
|
- `-config-dir` ((#\_config_dir)) - A directory of configuration files to
|
|
load. Consul will load all files in this directory with the suffix ".json" or ".hcl".
|
|
The load order is alphabetical, and the the same merge routine is used as with
|
|
the [`config-file`](#_config_file) option above. This option can be specified multiple
|
|
times to load multiple directories. Sub-directories of the config directory are
|
|
not loaded. For more information on the format of the configuration files, see
|
|
the [Configuration Files](/consul/docs/agent/config/config-files) section.
|
|
|
|
- `-config-format` ((#\_config_format)) - The format of the configuration
|
|
files to load. Normally, Consul detects the format of the config files from the
|
|
".json" or ".hcl" extension. Setting this option to either "json" or "hcl" forces
|
|
Consul to interpret any file with or without extension to be interpreted in that
|
|
format.
|
|
|
|
## DNS and Domain Options
|
|
|
|
- `-dns-port` ((#\_dns_port)) - the DNS port to listen on. This overrides
|
|
the default port 8600. This is available in Consul 0.7 and later.
|
|
|
|
- `-domain` ((#\_domain)) - By default, Consul responds to DNS queries in
|
|
the "consul." domain. This flag can be used to change that domain. All queries
|
|
in this domain are assumed to be handled by Consul and will not be recursively
|
|
resolved.
|
|
|
|
- `-alt-domain` ((#\_alt_domain)) - This flag allows Consul to respond to
|
|
DNS queries in an alternate domain, in addition to the primary domain. If unset,
|
|
no alternate domain is used.
|
|
|
|
In Consul 1.10.4 and later, Consul DNS responses will use the same domain as in the query (`-domain` or `-alt-domain`) where applicable.
|
|
PTR query responses will always use `-domain`, since the desired domain cannot be included in the query.
|
|
|
|
- `-recursor` ((#\_recursor)) - Specifies the address of an upstream DNS
|
|
server. This option may be provided multiple times, and is functionally equivalent
|
|
to the [`recursors` configuration option](/consul/docs/agent/config/config-files#recursors).
|
|
|
|
- `-join` ((#\_join)) - **Deprecated in Consul 1.15. This flag will be removed in a future version of Consul. Use the `-retry-join` flag instead.**
|
|
This is an alias of [`-retry-join`](#_retry_join).
|
|
|
|
- `-retry-join` ((#\_retry_join)) - Address of another agent to join upon starting up. Joining is
|
|
retried until success. Once the agent joins successfully as a member, it will not attempt to join
|
|
again. After joining, the agent solely maintains its membership via gossip. This option can be
|
|
specified multiple times to specify multiple agents to join. By default, the agent won't join any
|
|
nodes when it starts up. The value can contain IPv4, IPv6, or DNS addresses. Literal IPv6
|
|
addresses must be enclosed in square brackets. If multiple values are given, they are tried and
|
|
retried in the order listed until the first succeeds.
|
|
|
|
This supports [Cloud Auto-Joining](#cloud-auto-joining).
|
|
|
|
This can be dynamically defined with a [go-sockaddr] template that is resolved at runtime.
|
|
|
|
If Consul is running on a non-default Serf LAN port, you must specify the port number in the address when using the `-retry-join` flag. Alternatively, you can specify the custom port number as the default in the agent's [`ports.serf_lan`](/consul/docs/agent/config/config-files#serf_lan_port) configuration or with the [`-serf-lan-port`](#_serf_lan_port) command line flag when starting the agent.
|
|
|
|
If your network contains network segments, refer to the [network segments documentation](/consul/docs/enterprise/network-segments/create-network-segment) for additional information.
|
|
|
|
Here are some examples of using `-retry-join`:
|
|
|
|
<CodeBlockConfig heading="Using a DNS entry">
|
|
|
|
```shell-session
|
|
$ consul agent -retry-join "consul.domain.internal"
|
|
```
|
|
|
|
</CodeBlockConfig>
|
|
|
|
<CodeBlockConfig heading="Using IPv4">
|
|
|
|
```shell-session
|
|
$ consul agent -retry-join "10.0.4.67"
|
|
```
|
|
|
|
</CodeBlockConfig>
|
|
|
|
<CodeBlockConfig heading="Using a non-default Serf LAN port">
|
|
|
|
```shell-session
|
|
$ consul agent -retry-join "192.0.2.10:8304"
|
|
```
|
|
|
|
</CodeBlockConfig>
|
|
|
|
<CodeBlockConfig heading="Using IPv6">
|
|
|
|
```shell-session
|
|
$ consul agent -retry-join "[::1]:8301"
|
|
```
|
|
|
|
</CodeBlockConfig>
|
|
|
|
<CodeBlockConfig heading="Using multiple addresses">
|
|
|
|
```shell-session
|
|
$ consul agent -retry-join "consul.domain.internal" -retry-join "10.0.4.67"
|
|
```
|
|
|
|
</CodeBlockConfig>
|
|
|
|
### Cloud Auto-Joining
|
|
|
|
The `-retry-join` option accepts a unified interface using the
|
|
[go-discover](https://github.com/hashicorp/go-discover) library for doing
|
|
automatic cluster joining using cloud metadata. For more information, see
|
|
the [Cloud Auto-join page](/consul/docs/install/cloud-auto-join).
|
|
|
|
<CodeBlockConfig heading="Using Cloud Auto-Joining">
|
|
|
|
```shell-session
|
|
$ consul agent -retry-join "provider=aws tag_key=..."
|
|
```
|
|
|
|
</CodeBlockConfig>
|
|
|
|
- `-retry-interval` ((#\_retry_interval)) - Time to wait between join attempts.
|
|
Defaults to 30s.
|
|
|
|
- `-retry-max` ((#\_retry_max)) - The maximum number of join attempts if using
|
|
[`-retry-join`](#_retry_join) before exiting with return code 1. By default, this is set
|
|
to 0 which is interpreted as infinite retries.
|
|
|
|
- `-join-wan` ((#\_join_wan)) - **Deprecated in Consul 1.15. This flag will be removed in a future version of Consul. Use the `-retry-join-wan` flag instead.**
|
|
This is an alias of [`-retry-join-wan`](#_retry_join_wan)
|
|
|
|
- `-retry-join-wan` ((#\_retry_join_wan)) - Address of another WAN agent to join upon starting up.
|
|
WAN joining is retried until success. This can be specified multiple times to specify multiple WAN
|
|
agents to join. If multiple values are given, they are tried and retried in the order listed
|
|
until the first succeeds. By default, the agent won't WAN join any nodes when it starts up.
|
|
|
|
This supports [Cloud Auto-Joining](#cloud-auto-joining).
|
|
|
|
This can be dynamically defined with a [go-sockaddr] template that is resolved at runtime.
|
|
|
|
- `-primary-gateway` ((#\_primary_gateway)) - Similar to [`-retry-join-wan`](#_retry_join_wan)
|
|
but allows retrying discovery of fallback addresses for the mesh gateways in the
|
|
primary datacenter if the first attempt fails. This is useful for cases where we
|
|
know the address will become available eventually. [Cloud Auto-Joining](#cloud-auto-joining)
|
|
is supported as well as [go-sockaddr]
|
|
templates. This was added in Consul 1.8.0.
|
|
|
|
- `-retry-interval-wan` ((#\_retry_interval_wan)) - Time to wait between
|
|
[`-retry-join-wan`](#_retry_join_wan) attempts. Defaults to 30s.
|
|
|
|
- `-retry-max-wan` ((#\_retry_max_wan)) - The maximum number of [`-retry-join-wan`](#_join_wan)
|
|
attempts to be made before exiting with return code 1. By default, this is set
|
|
to 0 which is interpreted as infinite retries.
|
|
|
|
- `-rejoin` ((#\_rejoin)) - When provided, Consul will ignore a previous
|
|
leave and attempt to rejoin the cluster when starting. By default, Consul treats
|
|
leave as a permanent intent and does not attempt to join the cluster again when
|
|
starting. This flag allows the previous state to be used to rejoin the cluster.
|
|
|
|
## Log Options
|
|
|
|
- `-log-file` ((#\_log_file)) - writes all the Consul agent log messages
|
|
to a file. This value is used as a prefix for the log file name. The current timestamp
|
|
is appended to the file name. If the value ends in a path separator, `consul-`
|
|
will be appended to the value. If the file name is missing an extension, `.log`
|
|
is appended. For example, setting `log-file` to `/var/log/` would result in a log
|
|
file path of `/var/log/consul-{timestamp}.log`. `log-file` can be combined with
|
|
[`-log-rotate-bytes`](#_log_rotate_bytes) and [-log-rotate-duration](#_log_rotate_duration)
|
|
for a fine-grained log rotation experience.
|
|
|
|
- `-log-rotate-bytes` ((#\_log_rotate_bytes)) - to specify the number of
|
|
bytes that should be written to a log before it needs to be rotated. Unless specified,
|
|
there is no limit to the number of bytes that can be written to a log file.
|
|
|
|
- `-log-rotate-duration` ((#\_log_rotate_duration)) - to specify the maximum
|
|
duration a log should be written to before it needs to be rotated. Must be a duration
|
|
value such as 30s. Defaults to 24h.
|
|
|
|
- `-log-rotate-max-files` ((#\_log_rotate_max_files)) - to specify the maximum
|
|
number of older log file archives to keep. Defaults to 0 (no files are ever deleted).
|
|
Set to -1 to discard old log files when a new one is created.
|
|
|
|
- `-log-level` ((#\_log_level)) - The level of logging to show after the
|
|
Consul agent has started. This defaults to "info". The available log levels are
|
|
"trace", "debug", "info", "warn", and "error". You can always connect to an agent
|
|
via [`consul monitor`](/consul/commands/monitor) and use any log level. Also,
|
|
the log level can be changed during a config reload.
|
|
|
|
- `-log-json` ((#\_log_json)) - This flag enables the agent to output logs
|
|
in a JSON format. By default this is false.
|
|
|
|
- `-syslog` ((#\_syslog)) - This flag enables logging to syslog. This is
|
|
only supported on Linux and macOS. It will result in an error if provided on Windows.
|
|
|
|
## Node Options
|
|
|
|
- `-node` ((#\_node)) - The name of this node in the cluster. This must
|
|
be unique within the cluster. By default this is the hostname of the machine.
|
|
The node name cannot contain whitespace or quotation marks. To query the node from DNS, the name must only contain alphanumeric characters and hyphens (`-`).
|
|
|
|
- `-node-id` ((#\_node_id)) - Available in Consul 0.7.3 and later, this
|
|
is a unique identifier for this node across all time, even if the name of the node
|
|
or address changes. This must be in the form of a hex string, 36 characters long,
|
|
such as `adf4238a-882b-9ddc-4a9d-5b6758e4159e`. If this isn't supplied, which is
|
|
the most common case, then the agent will generate an identifier at startup and
|
|
persist it in the [data directory](#_data_dir) so that it will remain the same
|
|
across agent restarts. Information from the host will be used to generate a deterministic
|
|
node ID if possible, unless [`-disable-host-node-id`](#_disable_host_node_id) is
|
|
set to true.
|
|
|
|
- `-node-meta` ((#\_node_meta)) - Available in Consul 0.7.3 and later, this
|
|
specifies an arbitrary metadata key/value pair to associate with the node, of the
|
|
form `key:value`. This can be specified multiple times. Node metadata pairs have
|
|
the following restrictions:
|
|
|
|
- A maximum of 64 key/value pairs can be registered per node.
|
|
- Metadata keys must be between 1 and 128 characters (inclusive) in length
|
|
- Metadata keys must contain only alphanumeric, `-`, and `_` characters.
|
|
- Metadata keys must not begin with the `consul-` prefix; that is reserved for internal use by Consul.
|
|
- Metadata values must be between 0 and 512 (inclusive) characters in length.
|
|
- Metadata values for keys beginning with `rfc1035-` are encoded verbatim in DNS TXT requests, otherwise
|
|
the metadata kv-pair is encoded according [RFC1464](https://www.ietf.org/rfc/rfc1464.txt).
|
|
|
|
- `-disable-host-node-id` ((#\_disable_host_node_id)) - Setting this to
|
|
true will prevent Consul from using information from the host to generate a deterministic
|
|
node ID, and will instead generate a random node ID which will be persisted in
|
|
the data directory. This is useful when running multiple Consul agents on the same
|
|
host for testing. This defaults to false in Consul prior to version 0.8.5 and in
|
|
0.8.5 and later defaults to true, so you must opt-in for host-based IDs. Host-based
|
|
IDs are generated using [gopsutil](https://github.com/shirou/gopsutil/), which
|
|
is shared with HashiCorp's [Nomad](https://www.nomadproject.io/), so if you opt-in
|
|
to host-based IDs then Consul and Nomad will use information on the host to automatically
|
|
assign the same ID in both systems.
|
|
|
|
## Serf Options
|
|
|
|
- `-serf-lan-allowed-cidrs` ((#\_serf_lan_allowed_cidrs)) - The Serf LAN allowed CIDRs allow to accept incoming
|
|
connections for Serf only from several networks (multiple values are supported).
|
|
Those networks are specified with CIDR notation (eg: 192.168.1.0/24).
|
|
This is available in Consul 1.8 and later.
|
|
|
|
- `-serf-lan-port` ((#\_serf_lan_port)) - the Serf LAN port to listen on.
|
|
This overrides the default Serf LAN port 8301. This is available in Consul 1.2.2
|
|
and later.
|
|
|
|
- `-serf-wan-allowed-cidrs` ((#\_serf_wan_allowed_cidrs)) - The Serf WAN allowed CIDRs allow to accept incoming
|
|
connections for Serf only from several networks (multiple values are supported).
|
|
Those networks are specified with CIDR notation (eg: 192.168.1.0/24).
|
|
This is available in Consul 1.8 and later.
|
|
|
|
- `-serf-wan-port` ((#\_serf_wan_port)) - the Serf WAN port to listen on.
|
|
This overrides the default Serf WAN port 8302. This is available in Consul 1.2.2
|
|
and later.
|
|
|
|
## Server Options
|
|
|
|
- `-server` ((#\_server)) - This flag is used to control if an agent is
|
|
in server or client mode. When provided, an agent will act as a Consul server.
|
|
Each Consul cluster must have at least one server and ideally no more than 5 per
|
|
datacenter. All servers participate in the Raft consensus algorithm to ensure that
|
|
transactions occur in a consistent, linearizable manner. Transactions modify cluster
|
|
state, which is maintained on all server nodes to ensure availability in the case
|
|
of node failure. Server nodes also participate in a WAN gossip pool with server
|
|
nodes in other datacenters. Servers act as gateways to other datacenters and forward
|
|
RPC traffic as appropriate.
|
|
|
|
- `-server-port` ((#\_server_port)) - the server RPC port to listen on.
|
|
This overrides the default server RPC port 8300. This is available in Consul 1.2.2
|
|
and later.
|
|
|
|
- `-non-voting-server` ((#\_non_voting_server)) <EnterpriseAlert inline /> - **This field
|
|
is deprecated in Consul 1.9.1. See the [`-read-replica`](#_read_replica) flag instead.**
|
|
|
|
- `-read-replica` ((#\_read_replica)) <EnterpriseAlert inline /> - This
|
|
flag is used to make the server not participate in the Raft quorum, and have it
|
|
only receive the data replication stream. This can be used to add read scalability
|
|
to a cluster in cases where a high volume of reads to servers are needed.
|
|
|
|
## UI Options
|
|
|
|
- `-ui` ((#\_ui)) - Enables the built-in web UI server and the required
|
|
HTTP routes. This eliminates the need to maintain the Consul web UI files separately
|
|
from the binary.
|
|
|
|
- `-ui-dir` ((#\_ui_dir)) - This flag provides the directory containing
|
|
the Web UI resources for Consul. This will automatically enable the Web UI. The
|
|
directory must be readable to the agent. Starting with Consul version 0.7.0 and
|
|
later, the Web UI assets are included in the binary so this flag is no longer necessary;
|
|
specifying only the `-ui` flag is enough to enable the Web UI. Specifying both
|
|
the '-ui' and '-ui-dir' flags will result in an error.
|
|
|
|
<!-- prettier-ignore -->
|
|
- `-ui-content-path` ((#\_ui\_content\_path)) - This flag provides the option
|
|
to change the path the Consul UI loads from and will be displayed in the browser.
|
|
By default, the path is `/ui/`, for example `http://localhost:8500/ui/`. Only alphanumerics,
|
|
`-`, and `_` are allowed in a custom path.`/v1/` is not allowed as it would overwrite
|
|
the API endpoint.
|
|
|
|
<!-- list of reference-style links -->
|
|
|
|
[go-sockaddr]: https://godoc.org/github.com/hashicorp/go-sockaddr/template
|