Почему в docker-compose порты нужно экранировать кавычками

Что проверяют

Понимаете ли вы, что именно читает ваши конфиги. Вопрос про YAML, а не про Docker: проверяют, знаете ли вы, что кавычки задают тип значения, и можете ли назвать конкретный случай, когда без них ломается.

Как отвечать

Первым делом снять неточность в формулировке: это не экранирование. Кавычки говорят парсеру, что перед ним строка и угадывать тип не надо.

Конкретная беда с портами растёт из правила шестидесятеричных чисел в старой редакции YAML: запись вида 22:22 парсер вправе прочитать как число в системе с основанием 60 и превратить в 1342. Срабатывает это, только когда обе части меньше 60, поэтому 8080:80 живёт без кавычек прекрасно, а 22:22 или 53:53 могут поехать. Отсюда и привычка кавычить все порты подряд: правило проще запомнить, чем исключение.

Современные парсеры ведут себя аккуратнее, но кавычки остаются дешёвой страховкой, и не только для портов:

services:
  db:
    ports:
      - "5432:5432"
    environment:
      POSTGRES_PASSWORD: "0123"
      FEATURE_ENABLED: "no"

Без кавычек пароль рискует стать числом и потерять ведущий ноль, а no превратиться в булево значение. Ещё надёжнее длинная форма записи портов с полями target и published: там числа лежат в отдельных полях и двоеточия нет вовсе.

Где спотыкаются

Отвечают «так принято» или «иначе не заработает», а на уточнение про 8080:80 без кавычек сказать нечего. Интервьюер тянет ровно за это: важно, что правило про границу 60, а не общая магия.

Второе: переносят привычку на значения, которые обязаны остаться числами, например на лимиты и таймауты соседних полей, и получают ошибку схемы вместо пользы.

Третье: помнят про порты и забывают про переменные окружения, хотя болит там сильнее: пароль с ведущим нулём, значение вида 3.10, ставшее числом 3.1, и пары yes с off, доехавшие в контейнер строками true и false.