¿Por qué no se permite usar un booleano en un docker-compose.yml?

Definir un booleano en un archivo docker-compose.yml:

environment:
  SOME_VAR: true

y docker upresultados de ejecución en:

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

Intenta resolver el problema

1. Si verdadero se cambia a Verdadero, el problema persiste.

2. El uso 'true'no es aceptado por el código en sí mismo ( una aplicación de Play Framework se inicia usando ./target/universal/stage/bin/APPNAME -Dplay.evolutions.db.default.autoApply=, es decir, -Dplay.evolutions.db.default.autoApply=trueo -Dplay.evolutions.db.default.autoApply=falseparámetro)

   VAR tiene tipo STRING en lugar de BOOLEAN

3. El uso de yeso nocomo variable da como resultado:

   contiene verdadero, que es un tipo no válido, debe ser una cadena, un número o un valor nulo

4. Usando yesy usando un script que se transforma yesen verdaderas obras

Discusión

Según los 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 :

Medio ambiente

Agregar variables de entorno. Puede usar una matriz o un diccionario. Cualquier valor booleano; verdadero, falso, sí no, debe incluirse entre comillas para asegurarse de que el analizador YML no los convierta en verdadero o falso.

Las variables de entorno con solo una clave se resuelven en sus valores en la máquina en la que se está ejecutando Compose, lo que puede ser útil para valores secretos o específicos del host.

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

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

Pregunta

¿Por qué no está permitido?

Esto proviene de una elección de diseño del lenguaje YAML sobre booleanos

Cada valor sin comillas que coincida con esta "expresión regular":

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

Se convertirá a True o False.

Esto comienza a causar un problema cuando su código probará que un valor de entorno sea sí o no, por ejemplo, tomando este script (otros ejemplos en la advertencia PR ):

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

Y configurando en su archivo de redacción

environment:
  SOME_VAR: yes

Resultará en SOME_VARser Truecuando se ejecuta el script, por lo tanto, tomar el caso incorrecto ya que no es igual a yes.

Así que la elección se ha hecho para no permitir booleano para evitar comportamientos no deseados difíciles de depurar cuando no estás consciente de la regla YAML.

Veo dos formas de superar el problema:

1. Usando un env_fileen su lugar, no se analizan IIRC y deben evitar la conversión.

2. Como ya dijo, use un script de envoltura alrededor de su iniciador para definir el valor en su lugar antes de iniciar la aplicación, algo similar debería hacer:

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

Eso es YAML. Se interpreta truecomo un booleano. Los Envars deben ser cadenas, de ahí el requisito de hacer explícito el tipo mediante comillas.

Pruebe esto con https://www.json2yaml.com/