cli: environment variables for certs dir and addr and other cli flags

[akbarahmed]

Would it make sense to allow the cockroach CLI command to read various environment variables as defaults for the available flags?

For example, a number of environment variables could be defined that allow various flags to have default values set that are specific to a given server/node.

• CDB_BASE_DIR: Base directory for the CockroachDB installation. Could also be used to add CochroachDB to PATH.
• CDB_CERTS_DIR: Directory that contains SSL certs that falls back to $CDB_BASE_DIR/certs.
• CDB_DATA_DIR: Directory that contains the RocksDB database files.

Currently, I'm adding --certs to many commands when I run cockroach outside of the installation directory. For example: cockroach user set user1 --certs="$CDB_CERTS_DIR".

If this sounds like something that would make sense then I'll start on writing the code to implement it.

[mberhault]

Some of them are reasonable to have, but definitely not all. For example, --addr probably shouldn't be one, but --certs would be a good candidate.
I'm happy to change this, but it may be a little while.

[akbarahmed]

@mberhault If its okay, I'd like to take a pass at writing this code. I'm new to both Go and CockroachDB. I figured this a simple place for me to start.

[bdarnell]

I think -addr makes sense as an environment variable too. Maybe not in all cases, but I think that it should be possible to set enough flags in environment variables to make it possible to use the cockroach client without additional arguments in most cases. Most databases' command-line interfaces support environment variables for the server address.

(but not BASE_DIR and DATA_DIR - this should only be for flags used by the client)

[mberhault]

If you like, but I would recommend avoiding shortened names. eg: COCKROACH_CERTS_DIR is preferable to CBD_CERTS_DIR. Data dir should really be a list of stores (limiting it to one is too strict).

Can I ask what your current use case is? Is it development or production?
If dev, do you want to persist the data to disk, or just play with the interface? If the latter, you can use --dev (can be set through COCKROACH_DEV=1) for a single-node in-memory instance.

[akbarahmed]

TL;DR: The purpose of these env vars is to allow people to add cockroach to their PATH, to allow people to run cockroach commands without repeatedly entering options, and lastly to give CockroachDB a layered configuration approach similar to most other servers.

@mberhault My current use case is for development. I added cockroach to my PATH. However, when I run cockroach from any directory other than the source I get the following error message: open certs/root.client.crt: no such file or directory. So, I have to specify --certs every time I run the command. I was about to write a shell script to wrap the cockroach command, but that's not an ideal approach.

BTW, I searched through the source to see if the env vars for --certs and other options already exist. They obviously don't. However, similar env vars already exist for Docker/CI/Go, such as DOCKER_CERT_PATH, DOCKER_HOST, CIRCLECI, GOPATH, etc.

Thinking toward production, IME a server/database usually has a layered configuration. For example, defaults are set in code, which can be overridden in a a config file (yaml, json,...), then the config file can be overridden by env vars, and the env vars can be overridden by CLI options.

[bdarnell]

Yes, I think that's a good goal; all of the client-side flags should have equivalents in the environment: COCKROACH_ADDR, COCKROACH_CERTS_DIR, etc. I don't think that environment variables for the server side make sense, so the data directory should remain in the --stores flag.