Custom stack environment variables #7
Comments
|
Hi @greenled, Any news on this issue? Have a good day, |
|
Hi @tortuetorche, I'm afraid I can not work on this in an immediate future. Too much work here and some health issues :( |
|
Hi @greenled, Here a starting point: Create a HOSTNAME=bfaecdeb0cd2
HOME=/root
_BASH_VERSION=5.0
_BASH_PATCH_LEVEL=0
_BASH_LATEST_PATCH=7
TERM=xterm
foo=d=ccThen execute this env -i $(cat .env) jq -n 'env | to_entries | map({name: .key, value: .value})'This will output: [
{
"name": "HOSTNAME",
"value": "bfaecdeb0cd2"
},
{
"name": "HOME",
"value": "/root"
},
{
"name": "_BASH_VERSION",
"value": "5.0"
},
{
"name": "_BASH_PATCH_LEVEL",
"value": "0"
},
{
"name": "_BASH_LATEST_PATCH",
"value": "7"
},
{
"name": "TERM",
"value": "xterm"
},
{
"name": "foo",
"value": "d=cc"
}
]I hope you'll be better soon, |
|
Thanks @tortuetorche, this is a very good starting point. Stack envvars are set in the I would also make the environment variables file path customizable with a flag, like |
|
Hi @greenled , Thank you for your explanations. Here some snippets to merge two environment variable JSON files with jq -s 'add | unique_by(.name)' env_new.json env_old.jsonOr: jq -n '[inputs] | add | unique_by(.name)' env_new.json env_old.jsonHave a good day, |
Prior to this pull request `psu` script act like this: Stack env vars are set in the `deploy()` function. When a new stack is deployed it gets no env vars, and when an existing one is updated its envvars are reused (extracted from its stack definition into the stack_envvars variable and set back again). For the first case this pull request load the content of the env vars file and transform it into JSON using a `jq` command and set it as the `stack_envvars` value. For the second case, though, the script update the current stack env vars rather than setting them from scratch, keeping any value not previously set in the env file. The environment variables file path is customizable with the environment variable `$ENVIRONMENT_VARIABLES_FILE` or the `-g` flag, like this: ```bash export ACTION="deploy" export PORTAINER_USER="admin" export PORTAINER_PASSWORD="password" export PORTAINER_URL="http://portainer.local" export PORTAINER_STACK_NAME="mystack" export DOCKER_COMPOSE_FILE="/path/to/docker-compose.yml" export ENVIRONMENT_VARIABLES_FILE="/path/to/env_vars_file" ./psu ``` Or with flags: ```bash ./psu -a deploy -u admin -p password -l http://portainer.local -n mystack -c /path/to/docker-compose.yml -g /path/to/env_vars_file ``` close greenled#7
Prior to this pull request `psu` script act like this: Stack env vars are set in the `deploy()` function. When a new stack is deployed it gets no env vars, and when an existing one is updated its envvars are reused (extracted from its stack definition into the stack_envvars variable and set back again). For the first case this pull request load the content of the env vars file and transform it into JSON using a `jq` command and set it as the `stack_envvars` value. For the second case, though, the script update the current stack env vars rather than setting them from scratch, keeping any value not previously set in the env file. The environment variables file path is customizable with the environment variable `$ENVIRONMENT_VARIABLES_FILE` or the `-g` flag, like this: ```bash export ACTION="deploy" export PORTAINER_USER="admin" export PORTAINER_PASSWORD="password" export PORTAINER_URL="http://portainer.local" export PORTAINER_STACK_NAME="mystack" export DOCKER_COMPOSE_FILE="/path/to/docker-compose.yml" export ENVIRONMENT_VARIABLES_FILE="/path/to/env_vars_file" ./psu ``` Or with flags: ```bash ./psu -a deploy -u admin -p password -l http://portainer.local -n mystack -c /path/to/docker-compose.yml -g /path/to/env_vars_file ``` close greenled#7
Prior to this pull request `psu` script act like this: Stack env vars are set in the `deploy()` function. When a new stack is deployed it gets no env vars, and when an existing one is updated its envvars are reused (extracted from its stack definition into the stack_envvars variable and set back again). For the first case this pull request load the content of the env vars file and transform it into JSON using a `jq` command and set it as the `stack_envvars` value. For the second case, though, the script update the current stack env vars rather than setting them from scratch, keeping any value not previously set in the env file. The environment variables file path is customizable with the environment variable `$ENVIRONMENT_VARIABLES_FILE` or the `-g` flag, like this: ```bash export ACTION="deploy" export PORTAINER_USER="admin" export PORTAINER_PASSWORD="password" export PORTAINER_URL="http://portainer.local" export PORTAINER_STACK_NAME="mystack" export DOCKER_COMPOSE_FILE="/path/to/docker-compose.yml" export ENVIRONMENT_VARIABLES_FILE="/path/to/env_vars_file" ./psu ``` Or with flags: ```bash ./psu -a deploy -u admin -p password -l http://portainer.local -n mystack -c /path/to/docker-compose.yml -g /path/to/env_vars_file ``` close greenled#7
The script only supports keeping stack envvars between stack updates, not changing them. Even worse, new deployments go without envvars. It would be desirable to allow the user to set ennvars at will.
They could be taken from a file like:
Envvars set through the script should overwrite existing ones with the same name, and keep the others.
The Portainer API already has a
Envfield for this purpose:[ { "name": "MYSQL_ROOT_PASSWORD", "value": "password" } ]The text was updated successfully, but these errors were encountered: