Yaml, docker compose, пробелы и цитаты

При каких обстоятельствах должен можно использовать кавычки в файле YAML, особенно при использовании docker-compose.

Например,

service:
  image: "my-registry/repo:tag1"
  environment:
    ENV1: abc
    ENV2: "abc"
    ENV3: "a b c"

Например, если требуются пробелы, нужно ли заключать переменную окружения в кавычки, как показано в ENV3?

24
0
14 446
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ принят как подходящий

После некоторого поиска в Google я нашел Сообщение блога это касается этой проблемы, как я ее понял.

Я процитирую здесь самую важную часть:

plain scalars:
- a string
- a string with a \ backslash that doesn't need to be escaped
- can also use " quotes ' and $ a % lot /&?+ of other {} [] stuff

single quoted:
- '& starts with a special character, needs quotes'
- 'this \ backslash also does not need to be escaped'
- 'just like the " double quote'
- 'to express one single quote, use '' two of them'

double quoted:
- "here we can use predefined escape sequences like \t \n \b"
- "or generic escape sequences \x0b \u0041 \U00000041"
- "the double quote \" needs to be escaped"
- "just like the \\ backslash"
- "the single quote ' and other characters must not be escaped"

literal block scalar: |
  a multiline text
  line 2
  line 3

folded block scalar: >
  a long line split into
  several short
  lines for readability

Также я не видел такого синтаксиса docker-compose для установки переменных env. Документация предлагает использовать простые значения, такие как

environment:
  - ENV1=abc
  - "ENV2=abc"

Где кавычки " или ' не обязательны в этом конкретном примере в соответствии с тем, что я сказал ранее.

Чтобы узнать, как включать пробелы в переменные env, вы можете проверить этот так ответь

Спасибо за это, т. Е. стиль, используемый для среды компоновки докеров, их документы показывают здесь оба варианта стиля: docs.docker.com/compose/compose-file/#environment

David 31.10.2018 17:18

Нужны ли вам кавычки, зависит от парсера. Docker-compose AFAIK по-прежнему полагается на модуль PyYAML, который реализует большую часть YAML 1.1 и имеет несколько собственных причуд.

В общем, вам нужно только указать в кавычках то, что в противном случае могло бы быть неверно истолковано или конфликтовать с некоторой конструкцией YAML, которая не является скалярной строкой. Вам также нужны (двойные) кавычки для вещей, которые не могут быть представлены в простых скалярах, скалярах в одинарных кавычках, литералах блочного стиля или свернутых скалярах.

Неверное толкование

Вам нужно заключить в кавычки строки, которые выглядят как некоторые другие структуры данных:

  • логические значения: «True», «False», но PyYAML также предполагает альтернативные слова, такие как «Yes», ​​«No», «On», «Off», представляют логические значения (и все строчные буквы, все версии в верхнем регистре также должны быть рассмотрены) . Обратите внимание, что стандарт YAML 1.2 удалил ссылки на эти альтернативы.
  • целые числа: сюда входит строка, состоящая только из чисел. Но также шестнадцатеричное (0x123) и восьмеричное число (0123). Восьмеричные числа в YAML 1.2 записываются как 0o123, но PyYAML не поддерживает это, однако лучше процитировать оба. Специальное целое число, которое PyYAML по-прежнему поддерживает, но опять же не в спецификации YAML 1.2, является шестидесятичным: число с основанием 60, разделенное двоеточием (:), указание времени, но также MAC-адреса могут интерпретироваться как таковые, если значения между / после двоеточий находятся в диапазон 00-59
  • floats: строки типа 1E3 (с необязательным знаком и мантиссой) должны быть заключены в кавычки. Конечно, 3.14 также необходимо указать в кавычках, если это строка. Также следует указывать шестидесятеричные числа с плавающей запятой (с мантиссой после числа после последнего двоеточия).
  • временные метки: 2001-12-15T02:59:43.1Z, но также строки, подобные iso-8601, должны быть заключены в кавычки, чтобы они не интерпретировались как временные метки.
  • Значение null записывается как пустая строка, как ~ или Null (во всех типах регистров), поэтому любые строки, соответствующие им, должны быть заключены в кавычки.

Цитирование в приведенном выше примере может быть выполнено в одинарных или двойных кавычках, либо могут использоваться литералы блочного стиля или скаляры со свернутыми контурами. Обратите внимание, что для блочного стиля вы должны использовать |- соответственно. >-, чтобы не вводить завершающий символ новой строки, которого нет в исходной строке.

Столкновения

YAML придает особое значение определенным символам или комбинациям символов. Некоторые из них имеют особое значение только в начале строки, другие - только внутри строки.

  • символы из набора !&*?{[ обычно обозначают специальные конструкции YAML. Некоторые из них могут быть устранены в зависимости от следующего персонажа, но я бы не стал на это полагаться.
  • пробел, за которым следует #, указывает на конец строки комментария
  • везде, где возможен ключ (и в блочном режиме, который есть во многих местах), комбинация двоеточия + пробел (:) указывает, что значение будет следующим. Если эта комбинация является частью вашей скалярной строки, вам необходимо указать кавычки.

Как и в случае неправильной интерпретации, вы можете использовать одинарные или двойные кавычки, литералы блочного стиля или складывающиеся скаляры. Не может быть никаких комментариев в конце строки за пределами первой строки скаляра блочного стиля.

PyYAML может дополнительно запутаться из-за любого двоеточия + пробела в простом скаляре (даже если это значение), поэтому всегда указывайте их.

Представление специальных символов

Вы можете вставлять специальные символы или кодовые точки Unicode в файл YAML, но если вы хотите, чтобы они были четко видны во всех случаях, вы можете использовать escape-последовательности. В этом случае вам нужно использовать двойные кавычки, это единственный режим, в котором позволяет использовать обратную косую черту. И например \u2029. Полный список таких экранирований можно взять из стандарт, но обратите внимание, что PyYAML не реализует, например, \/ (или, по крайней мере, не реализовал, когда я разветвил эту библиотеку).


Один из способов выяснить, что цитировать, а что нет, - это использовать библиотеку, используемую для выгрузки имеющихся у вас строк. Мои ruamel.yaml и PyYAML, используемые docker-compose, когда потенциально сбрасывают простой скаляр, оба пытаются прочитать (да, путем анализа результата) простое скалярное представление строки, и если это приводит к чему-то отличному от строки, это необходимо применять четкие кавычки. Вы также можете сделать это: в случае сомнений напишите небольшую программу, сбрасывающую список строк, которые у вас есть, используя PyYAML safe_dump(), и применяйте кавычки везде, где это делает PyYAML.

Другие вопросы по теме