Por que não é permitido usar um booleano em um docker-compose.yml?

Definindo um booleano em um arquivo docker-compose.yml:

environment:
  SOME_VAR: true

e execução docker upresulta em:

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

Tentativas de resolver o problema

1. Se true for alterado para True, o problema persistirá.

2. O uso 'true'não é aceito pelo próprio código ( um aplicativo de estrutura de reprodução é iniciado usando o parâmetro ./target/universal/stage/bin/APPNAME -Dplay.evolutions.db.default.autoApply=, ou seja, -Dplay.evolutions.db.default.autoApply=trueou -Dplay.evolutions.db.default.autoApply=false):

   VAR tem o tipo STRING em vez de BOOLEAN

3. O uso yesou nocomo variável resulta em:

   contém true, que é um tipo inválido, deve ser uma sequência, número ou um valor nulo

4. Usando yese usando um script que se transforma yesem obras verdadeiras

Discussão

De acordo com os documentos 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 :

Meio Ambiente

Adicione variáveis ​​de ambiente. Você pode usar uma matriz ou um dicionário. Qualquer valor booleano; true, false, yes no, precisam estar entre aspas para garantir que não sejam convertidos em True ou False pelo analisador YML.

As variáveis ​​de ambiente com apenas uma chave são resolvidas com seus valores na máquina em que o Compose está sendo executado, o que pode ser útil para valores secretos ou específicos do host.

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

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

Questão

Por que isso não é permitido?

Isso vem de uma opção de design da linguagem YAML sobre booleanos

Todo valor não citado que corresponde a este "regex":

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

Será convertido para True ou False.

Isso começa a causar um problema quando seu código testará um valor de ambiente como sim ou não, por exemplo, usando este script (outros exemplos na discussão de PR ):

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

E definindo no seu arquivo de composição

environment:
  SOME_VAR: yes

O resultado SOME_VARserá Truequando o script for executado, levando, portanto, o caso errado, pois não é igual a yes.

Portanto, optou -se por proibir o booleano, a fim de evitar comportamentos indesejáveis ​​difíceis de depurar quando você não está ciente da regra YAML.

Eu vejo duas maneiras de superar o problema:

1. Usando um em env_filevez disso, eles não são analisados ​​IIRC e devem impedir a conversão.

2. Como você já disse, use um script de wrapper em torno do seu iniciador para definir o valor antes de iniciar o aplicativo, algo ao longo da linha deve fazer:

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

Isso é YAML. Ele interpreta truecomo um booleano. Envars devem ser strings, daí o requisito de tornar o tipo explícito através de aspas.

Teste isso com https://www.json2yaml.com/