Configuració
La llavor de configuració, on es desa la configuració, git i ytt
Canvia aquestes variables per decidir d’on surt la configuració: una llavor de configuració, la base de dades, git o plantilles ytt.
Exemple
Aplica una llavor de configuració muntada, comprova-la cada cinc minuts i desa config.yaml a la base de dades. A docker-compose.yml:
environment:
- CONFIG_SEED_PATH=/seed/seed.yaml
- CONFIG_SEED_RELOAD_SECONDS=300
- ENABLE_CONFIG_IN_DATABASE=1
- ALLOW_ENV_EDIT=0 # the environment is declared here, not on the settings pages
volumes:
- ./seed:/seed:ro
Una llavor no vàlida impedeix que el servidor arrenqui. Vegeu Llavor de configuració per al format del fitxer.
D’on es llegeix config.yaml
Les categories, els rols i les constants surten de config.yaml al disc o de la seva còpia a la base de dades, decidit en aquest ordre:
ENABLE_CONFIG_IN_DATABASE, quan està definida, a l’entorn o a la pestanya Configuració de la pàgina de configuració:1llegeix la base de dades,0llegeix el fitxer.- Si no, l’origen de configuració desat a la base de dades (
fileodatabase), que les instàncies configurades abans de la 6.3.0 van triar a la pàgina de configuració. - Si no, el fitxer: el
config.yamldel repositori amb Utilitzar per a la configuració ? activat, si no el d’un repositori amb Utilitzar per als formularis ? activat, i si no el deCONFIG_PATH.
Un ENABLE_CONFIG_IN_DATABASE definit explícitament sempre guanya, fins i tot 0 davant d’un database desat. Es llegeix cada vegada que es carrega la configuració, així que un canvi s’aplica sense reiniciar. La pàgina Estat mostra l’origen en ús a la seva pestanya Informació.
Variables
Totes les variables d’aquest grup, amb el seu tipus, el seu valor predeterminat i la seva descripció:
| Variable | Opcions/Valors per defecte | Comentaris |
|---|---|---|
| CONFIG_SEED_PATH string added in version 6.3.0 | Valor per defecte: | Config seed file
Path to a declarative config seed. When set, the yaml file it points to is applied at startup and the admin objects it declares become read-only in the interface, so a whole instance can be rebuilt from git on an empty database. Secrets are referenced as ${ENV_VAR} and resolved from the environment, so the file itself holds none. Unrelated to CONFIG_PATH, which holds the forms configuration. An invalid seed makes the server refuse to start, and so does a path whose file is missing (a mounted file may only be late). Leaving it empty turns the seed off: the next start releases every object an earlier seed made read-only, keeping its values, so it can be changed in the interface again. See the Config seed page in the documentation. |
| CONFIG_SEED_RELOAD_SECONDS integer added in version 6.3.0 | Valor per defecte: 60 | Config seed reload interval (seconds)
How often the config seed file is checked and re-applied when its content has changed, in seconds. This is what lets a seed edited in git take effect without restarting: on kubernetes a ConfigMap is remounted under the running pod within about a minute and the change is picked up from there. A reload that fails is never fatal, unlike the one at startup: the configuration already in force is kept and the Status page reports it. Set it to 0 to check only at startup, leaving POST /api/v2/config-seed/apply and SIGHUP. Takes effect at once, without a restart. Ignored when CONFIG_SEED_PATH is empty. |
| ALLOW_ENV_EDIT boolean added in version 6.3.0 | Valor per defecte: 1 | Allow editing these settings
Whether the settings pages may write persistent/.env. Set it to 0 in a declarative deployment (kubernetes, docker-compose, ArgoCD): there the file is either ephemeral, so a save is silently lost at the next restart, or durable, so it drifts away from the manifest that is meant to be authoritative. With 0 every variable is shown with its value in force but cannot be changed, and the save endpoint refuses. |
| ENABLE_CONFIG_IN_DATABASE number added in version 6.1.0 | Opcions:
| Store the configuration in the database
If you use git repositories to store the forms, you can choose to store the master config.yaml in git as well. This gives the config.yaml in the database the highest priority in the loading order. |
| GIT_CLONE_COMMAND string added in version 6.0.2 | Valor per defecte: git clone | Git clone command
The command used to clone git repositories. Note that branch and repository will be auto added. |
| GIT_PULL_COMMAND string | Valor per defecte: git pull | Git pull command
The command used to pull git repositories. Note that branch and repository will be auto added. |
| GIT_PUSH_COMMAND string | Valor per defecte: git push | Git push command
The command used to push git repositories (used by the designer’s sync to git feature). Note that |
| USE_YTT number added in version 5.0.2 | Opcions:
| Enable the ytt interpreter
https://github.com/carvel-dev/ytt is a tool for yaml templating. It can be activated by this variable. |
| YTT_ALLOW_SYMLINK_DESTINATIONS string added in version 5.0.8 | Valor per defecte: | ytt allowed symlink destinations
Ytt disables templating with symlinks by default. If you want to allow symlink use on specific directories, this variable can be set to the path(s) where the symlinks are allowed (multiple paths separated by Node’s |
| YTT_DANGEROUS_ALLOW_ALL_SYMLINK_DESTINATIONS number added in version 5.0.8 | Opcions:
| ytt dangerous allow-all symlink destinations
Ytt disables templating with symlinks by default. If you want to allow all symlink use EVERYWHERE, you can set this variable to 1. Note: enabling this comes with some risks (hence the ‘DANGEROUS’ part), see ytt FAQ for more info. |
| YTT_VARS_PREFIX string added in version 5.0.8 | Valor per defecte: | ytt vars prefix
Environment variable prefix for ytt to get data values from. For example, when set to |
| YTT_LIB_DATA_{dynamic} string added in version 5.0.8 | Valor per defecte: | ytt lib data
This is not a single variable but rather an infinite amount of variables. You can set as many as you want. The dynamic part is the name of the lib data. For example |