Managing cluster configurations | Tarantool
Reference Tooling tt CLI utility Commands Managing cluster configurations

Managing cluster configurations

$ tt cluster COMMAND {APPLICATION[:APP_INSTANCE] | URI} [FILE] [OPTION ...]

tt cluster manages YAML configurations of Tarantool applications. This command works both with local configuration files in application directories and with centralized configuration storages (etcd or Tarantool-based).

COMMAND is one of the following:

  • publish: publish a cluster configuration using an arbitrary YAML file as a source.
  • show: print a cluster configuration.

tt cluster can read and modify local cluster configurations stored in config.yaml files inside application directories.

To write a configuration to a local config.yaml, run tt cluster publish with two arguments:

  • the application name.
  • the path to a YAML file from which the configuration should be taken.
$ tt cluster publish myapp source.yaml

To print a local configuration from an application’s config.yaml, run tt cluster show with the application name:

$ tt cluster show myapp

tt cluster can manage centralized cluster configurations in storages of both supported types: etcd or a Tarantool-based configuration storage.

To publish a configuration from a file to a centralized configuration storage, run tt cluster publish with a URI of this storage’s instance as the target. For example, the command below publishes a configuration from source.yaml to a local etcd instance running on the default port 2379:

$ tt cluster publish "http://localhost:2379/myapp" source.yaml

A URI must include a prefix that is unique for the application. It can also include credentials and other connection parameters. Find the detailed description of the URI format in URI format.

To print a cluster configuration from a centralized storage, run tt cluster show with a storage URI including the prefix identifying the application. For example, to print myapp’s configuration from a local etcd storage:

$ tt cluster show "http://localhost:2379/myapp"

There are three ways to pass the credentials for connecting to the centralized configuration storage. They all apply to both etcd and Tarantool-based storages. The following list shows these ways ordered by precedence, from highest to lowest:

  1. Credentials specified in the storage URI: https://username:password@host:port/prefix:

    $ tt cluster show "http://myuser:p4$$w0rD@localhost:2379/myapp"
    
  2. tt cluster options -u/--username and -p/--password:

    $ tt cluster show "http://localhost:2379/myapp" -u myuser -p p4$$w0rD
    
  3. Environment variables TT_CLI_ETCD_USERNAME and TT_CLI_ETCD_PASSWORD:

    $ export TT_CLI_ETCD_USERNAME=myuser
    $ export TT_CLI_ETCD_PASSWORD=p4$$w0rD
    $ tt cluster show "http://localhost:2379/myapp"
    

If connection encryption is enabled on the configuration storage, pass the required SSL parameters in the URI arguments.

A URI of the cluster configuration storage has the following format:

http(s)://[username:password@]host:port[/prefix][?arguments]
  • username and password define credentials for connecting to the configuration storage.
  • prefix is a base path identifying a specific application in the storage.
  • arguments defines connection parameters. The following arguments are available:
    • name – a name of an instance in the cluster configuration.
    • key – a target configuration key in the specified prefix.
    • timeout – a request timeout in seconds. Default: 3.0.
    • ssl_key_file – a path to a private SSL key file.
    • ssl_cert_file – a path to an SSL certificate file.
    • ssl_ca_file – a path to a trusted certificate authorities (CA) file.
    • ssl_ca_path – a path to a trusted certificate authorities (CA) directory.
    • ssl_ciphers – a colon-separated (:) list of SSL cipher suites the connection can use (for Tarantool-based storage only).
    • verify_host – verify the certificate’s name against the host. Default true.
    • verify_peer – verify the peer’s SSL certificate. Default true.

In addition to whole cluster configurations, tt cluster can manage configurations of specific instances within applications. In this case, it operates with YAML fragments that describe a single instance configuration section. For example, the following YAML file can be a source when publishing an instance configuration:

# instance_source.yaml
iproto:
  listen:
  - uri: 127.0.0.1:3311

To send an instance configuration to a local config.yaml, run tt cluster publish with the application:instance pair as the target argument:

$ tt cluster publish myapp:instance-002 instance_source.yaml

To send an instance configuration to a centralized configuration storage, specify the instance name in the name argument of the storage URI:

$ tt cluster publish "http://localhost:2379/myapp?name=instance-002" instance_source.yaml

tt cluster show can print configurations of specific cluster instances as well. To print an instance configuration from a local config.yaml, use the application:instance argument:

$ tt cluster show myapp:instance-002

To print an instance configuration from a centralized configuration storage, specify the instance name in the name argument of the URI:

$ tt cluster show "http://localhost:2379/myapp?name=instance-002"

tt cluster can validate configurations against the Tarantool configuration schema.

tt cluster publish automatically performs the validation and aborts in case of an error. To skip the validation, add the --force option:

$ tt cluster publish myapp source.yaml --force

To validate configurations when printing them with tt cluster show, enable the validation by adding the --validate option:

$ tt cluster show "http://localhost:2379/myapp" --validate

-u, --username STRING

A username for connecting to the configuration storage.

See also: Authentication.

-p, --password STRING

A password for connecting to the configuration storage.

See also: Authentication.

--force

Applicable to: publish

Skip validation when publishing. Default: false (validation is enabled).

--validate

Applicable to: show

Validate the printed configuration. Default: false (validation is disabled).

--with-integrity-check STRING

Enterprise Edition

This option is supported by the Enterprise Edition only.

Applicable to: publish

Generate hashes and signatures for integrity checks.

Found what you were looking for?
Feedback