Consul
Consul Agent Service Registration
Command: consul services register
Corresponding HTTP API Endpoint: [PUT] /v1/agent/service/register
The services register
command registers a service with the local agent.
This command returns after registration and must be paired with explicit
service deregistration. This command simplifies service registration from
scripts, in dev mode, etc.
This is just one method of service registration. Services can also be registered by placing a service definition in the Consul agent configuration directory and issuing a reload. This approach is easiest for configuration management systems that other systems that have access to the configuration directory. Clients may also use the HTTP API directly.
The table below shows this command's required ACLs. Configuration of blocking queries and agent caching are not supported from commands, but may be from the corresponding HTTP endpoint.
ACL Required |
---|
service:write |
Usage
Usage: consul services register [options] [FILE...]
This command can register either a single service using flags documented below, or one or more services using service definition files in HCL or JSON format. The service is registered against the specified Consul agent (defaults to the local agent). This agent will execute all registered health checks.
This command returns after registration succeeds. It must be paired with
a deregistration command or API call to remove the service. To ensure that
services are properly deregistered, it is highly recommended that
a check is created with the
DeregisterCriticalServiceAfter
configuration set. This will ensure that even if deregistration failed for
any reason, the agent will automatically deregister the service instance after
it is unhealthy for the specified period of time.
Registered services are persisted in the agent state directory. If the state directory remains unmodified, registered services will persist across restarts.
Warning for Consul operators: The Consul agent persists registered services in the local state directory. If this state directory is deleted or lost, services registered with this command will need to be reregistered.
Command Options
The flags below should only be set if no arguments are given. If no arguments are given, the flags below can be used to register a single service.
Note that the behavior of each of the fields below is exactly the same as when constructing a standard service definition. Please refer to that documentation for full details.
-id
- The ID of the service. This will default to-name
if not set.-name
- The name of the service to register.-address
- The address of the service. If this isn't specified, it will default to the address registered with the local agent.-port
- The port of the service.-socket
- The Unix Domain socket of the service. Conflicts with address and port flags.-meta key=value
- Specify arbitrary KV metadata to associate with the service instance. This can be specified multiple times.-tag value
- Associate a tag with the service instance. This flag can be specified multiples times.
Enterprise Options
-partition=<string>
- Specifies the partition to query. If not provided, the partition will be inferred from the request's ACL token, or will default to thedefault
partition. Partitions are a Consul Enterprise feature added in v1.11.0.
-namespace=<string>
- Specifies the namespace to query. If not provided, the namespace will be inferred from the request's ACL token, or will default to thedefault
namespace. Namespaces are a Consul Enterprise feature added in v1.7.0.
API Options
-ca-file=<value>
- Path to a CA file to use for TLS when communicating with Consul. This can also be specified via theCONSUL_CACERT
environment variable.-ca-path=<value>
- Path to a directory of CA certificates to use for TLS when communicating with Consul. This can also be specified via theCONSUL_CAPATH
environment variable.-client-cert=<value>
- Path to a client cert file to use for TLS whenverify_incoming
is enabled. This can also be specified via theCONSUL_CLIENT_CERT
environment variable.-client-key=<value>
- Path to a client key file to use for TLS whenverify_incoming
is enabled. This can also be specified via theCONSUL_CLIENT_KEY
environment variable.-http-addr=<addr>
- Address of the Consul agent with the port. This can be an IP address or DNS address, but it must include the port. This can also be specified via theCONSUL_HTTP_ADDR
environment variable. In Consul 0.8 and later, the default value is http://127.0.0.1:8500, and https can optionally be used instead. The scheme can also be set to HTTPS by setting the environment variableCONSUL_HTTP_SSL=true
. This may be a unix domain socket usingunix:///path/to/socket
if the agent is configured to listen that way.-tls-server-name=<value>
- The server name to use as the SNI host when connecting via TLS. This can also be specified via theCONSUL_TLS_SERVER_NAME
environment variable.-token=<value>
- ACL token to use in the request. This can also be specified via theCONSUL_HTTP_TOKEN
environment variable. If unspecified, the query will default to the token of the Consul agent at the HTTP address.-token-file=<value>
- File containing the ACL token to use in the request instead of one specified via the-token
argument orCONSUL_HTTP_TOKEN
environment variable. This can also be specified via theCONSUL_HTTP_TOKEN_FILE
environment variable.
Examples
To create a simple service:
$ consul services register -name=web
To create a service from a configuration file:
$ cat web.json
{
"Service": {
"Name": "web"
}
}
$ consul services register web.json