@busy-human/configurator
Loads and synchronizes configuration
Installation
npm i -g @busy-human/configurator
Purpose
It is bad practice to store passwords, keys, and other authorization elements directly in your repository. There are secure ways of distributing the configuration and keys between developers but it can be difficult to integrate this into automated workflows.
How a configuration is loaded
A configuration should be stored securely and require some form of authentication to access it regardless of where or how it is stored.
This tool uses key-based authentication.
Usage
The Configurator can be run interactively and non-interactively. If you call it with the right arguments, or if your package.json has the data it needs it can run certain commands without any interaction. Or, if you aren't sure what you need to provide it there are helpful prompts that gather the data needed for every command.
The Configurator can be run from your terminal after it has been installed on the system.
configurator authenticate http://myurl --key=****************
This command will fetch a token which will be saved and associated with your device. The token will then automatically be used on subsequent calls to that url.
After you've successfully authenticated you can get your configuration
configurator get
Generally your package.json should provide the data on which file to get and how to install it. But if you want to call the command directly you can use this pattern:
configurator get --url=http://myurl/myfile
Using with Environment Variables
The Configurator can use environment variables to supply its arguments.
CONFIGURATOR_KEY
If this is found on the system and the option is not passed into the command, they will be used when running.
package.json setup
You can add a new property to your package.json to store data about where and how to retrieve the configuration file(s) from.
"configurator": {
"strategy": "key",
"url": "http://myendpoint.com/myconfig"
}
DO NOT store your key in your package.json. This will be ignored by the Configurator and is a bad practice.
Arguments
key
url
This optional argument will tell exactly where the configuration file should be pulled from. Generally it is recommended to call this command without directly specifying the url and to instead define the configuration in your package.json.
Security
Client Token
The first time you try to connect to a Configurator endpoint you'll be asked for a key. You'll be given a token that expires after about 30 days.
IP Restrictions
IP Restrictions can be applied in two ways.
- You can require a whitelisted IP to do just the initial authentication
- You can require a whitelisted IP for every call to the Configurator
Setting Environment Variables from a config file
You can set environment variables from a config file by calling a special command available:
configurator "set-env,config.json,BASE_URL=appEngine.baseUrl"
Because of how the terminal works, the program cannot set environment variables all by itself and must be invoked in a special way. The configurator can construct the command for you, however.
configurator build-set-env
This interactive command will help you automatically construct the command you need to run to get the environment variables you need in your script.
Example command generated by build-set-env:
source /dev/stdin <<< "$(cat <(configurator 'set-env,config.json,BASE_URL=appEngine.baseUrl'))"
These variables are read at run-time, so whatever the latest value is will be used by the script.