Perché non è permesso usare un booleano in un docker-compose.yml?

Definizione di un valore booleano in un file docker-compose.yml:

environment:
  SOME_VAR: true

e docker uprisultati in esecuzione in:

contains true, which is an invalid type, it should be a string, number, or a null

Tentativi di risolvere il problema

1. Se true viene modificato in True, il problema persiste.

2. L'utilizzo 'true'non è accettato dal codice stesso ( un'app play framework viene avviata utilizzando il parametro ./target/universal/stage/bin/APPNAME -Dplay.evolutions.db.default.autoApply=, ovvero uno -Dplay.evolutions.db.default.autoApply=trueo entrambi -Dplay.evolutions.db.default.autoApply=false):

   VAR ha il tipo STRING anziché BOOLEAN

3. L'uso di yeso nocome variabile comporta:

   contiene true, che è un tipo non valido, dovrebbe essere una stringa, un numero o un valore nullo

4. Utilizzo yese utilizzo di uno script che si trasforma yesin opere vere

Discussione

Secondo i documenti Any boolean values; true, false, yes no, need to be enclosed in quotes to ensure they are not converted to True or False by the YML parser :

Ambiente

Aggiungi variabili d'ambiente. È possibile utilizzare un array o un dizionario. Qualsiasi valore booleano; true, false, yes no, devono essere racchiusi tra virgolette per assicurarsi che non vengano convertiti in True o False dal parser YML.

Le variabili di ambiente con solo una chiave vengono risolte sui loro valori sulla macchina su cui è in esecuzione Compose, che può essere utile per valori segreti o specifici dell'host.

environment:
  RACK_ENV: development
  SHOW: 'true'
  SESSION_SECRET:

environment:
  - RACK_ENV=development
  - SHOW=true
  - SESSION_SECRET

Domanda

Perché non è permesso?

Questo deriva da una scelta progettuale del linguaggio YAML sui booleani

Ogni valore non quotato corrispondente a questa "regex":

 y|Y|yes|Yes|YES|n|N|no|No|NO
|true|True|TRUE|false|False|FALSE
|on|On|ON|off|Off|OFF

Verrà convertito in True o False.

Questo inizia causando un problema quando il codice testerà un valore di ambiente come sì o no, ad esempio prendendo questo script (altri esempi nella discution di PR ):

if [ "$SOME_VAR" == "yes" ];
then
  echo "Variable SOME_VAR is activated"
else
  echo "Variable SOME_VAR is NOT activated"
fi

E l'impostazione nel tuo file di composizione

environment:
  SOME_VAR: yes

Si tradurrà in SOME_VARessere Truequando viene eseguito lo script, quindi prendendo il caso sbagliato in quanto non è uguale a yes.

Quindi è stata fatta la scelta di non consentire il booleano per impedire comportamenti indesiderati difficili da eseguire il debug quando non si è a conoscenza della regola YAML.

Vedo due modi per superare il problema:

1. Usando un env_fileinvece, non vengono analizzati IIRC e dovrebbero impedire la conversione.

2. Come hai già detto, usa uno script wrapper attorno al tuo launcher per definire il valore invece prima di avviare l'app, qualcosa sulla linea di ciò dovrebbe fare:

   AUTOAPPLY=false
   if [ "$SOME_VAR" == "true" ]
   then
       AUTOAPPLY=true
   fi
   
   ./target/universal/stage/bin/APPNAME -Dplay.evolutions.db.default.autoApply=$AUTOAPPLY
   

Questo è YAML. Interpreta truecome un booleano. Gli Envars devono essere stringhe, quindi l'obbligo di rendere esplicito il tipo tra virgolette.

Prova questo con https://www.json2yaml.com/