Главная/Материалы/Материал

debug-scenarios

Шесть сломанных конфигураций, воспроизводящих симптомы из debugging challenges. В отличие от текстовых описаний, эти запускаются — симптом можно увидеть, а не прочитать.

Как пользоваться

Открыть СИМПТОМ.md в каталоге сценария. Не открывать разбор.
Воспроизвести симптом командами оттуда.
Сформулировать две-три гипотезы до первой диагностической команды.
Проверять гипотезы командами, а не рассуждением.
Починить и убедиться, что симптом исчез.
Только теперь сверить с разбором в debugging challenges.

Правило. Сценарий засчитывается, если решён до чтения разбора. Подсмотренный разбор даёт знание конкретной поломки, но не навык расследования.

Сценарии

Каталог	Симптом	Challenge
`01-exits-immediately`	Container исчезает через секунду	1
`02-no-logs`	`docker logs` пуст при работающем процессе	2
`03-wrong-bind-address`	Изнутри отвечает, снаружи нет	4
`04-shell-form-sigterm`	`docker stop` занимает ровно 10 секунд	12
`05-depends-on-race`	Приложение стартует раньше базы	15
`06-volume-permissions`	`PermissionError` при записи в том	7

Быстрый старт

cd scenarios/01-exits-immediately
cat СИМПТОМ.md
docker build -t сценарий-01 .
docker run -d --name с01 сценарий-01

Проверка, что симптомы воспроизводятся

./check.sh; echo "код: $?"

Скрипт запускает все шесть и проверяет, что каждый действительно ведёт себя так, как описано. Три кода возврата:

Код	Значение
0	Все симптомы воспроизвелись
1	Какой-то не воспроизвёлся
3	Не проверялось: нет `docker`

На машине без Docker:

НЕ ПРОВЕРЕНО: docker недоступен; сценарии не запускались
код: 3

Зачем этот скрипт. Сломанная конфигурация, которая перестала быть сломанной, — бесполезное упражнение. Если у вас check.sh даёт код 1, значит поведение Docker или базовых образов изменилось, и разбор в challenge может устареть.

Два сценария заслуживают отдельного внимания

04: обработчик есть, и он не срабатывает

Этот сценарий отличается от «забыли написать обработчик». Обработчик написан и исправен — проверяется запуском вне container'а:

cd scenarios/04-shell-form-sigterm
python3 app.py &
sleep 1 && kill -TERM %1

сервис запущен
получен сигнал 15, завершаюсь
сервис остановлен

А в container'е — не срабатывает. Различить «обработчика нет» и «сигнал не доходит» можно только одной командой, и найти её — суть задачи.

05: правильный ответ состоит из двух частей

Исправить depends_on недостаточно. Второй вопрос сценария — что останется неисправленным даже после condition: service_healthy.

Ответ: отказ базы в работе, а не при старте. depends_on действует один раз; повторы подключения в коде действуют всегда. В Kubernetes останется только второе (урок 18.3).

Что общего у шести сценариев

Симптом не указывает на причину. «Порт недоступен» может быть про адрес привязки, про порт, про сеть или про то, что приложение не запустилось. Половина работы — сузить область, и делается это командами.

У двух сценариев причин больше одной. В 04 их две с одинаковым симптомом; в 05 — одна видимая и одна, которая проявится позже.

Два не разрешаются чтением логов приложения. В 01 нужен код возврата, в 06 — владелец каталога. Ни то ни другое приложение не сообщает.

Чего пример не делает

Ни один сценарий не запускался. Docker на машине, где готовился курс, отсутствует. Проверено то, что проверяется без него:

Что	Как	Результат
Все `.py` синтаксически валидны	`ast.parse`	6 из 6
Все `compose.yaml` разбираются	`yaml.safe_load`	2 из 2
`check.sh` синтаксически корректен	`bash -n`	ок
`check.sh` отказывает без Docker	запуск	код 3

Ожидаемое поведение сценариев выведено из механизмов, разобранных в соответствующих уроках, а не записано с сеанса. Прогоните check.sh у себя: если какой-то симптом не воспроизвёлся, это само по себе интересная находка.

Сценариев шесть, а challenges двадцать. Остальные четырнадцать описаны текстом в debugging challenges: часть из них требует условий, которые не создаются в одном каталоге (заполненный диск, устаревшие образы, скомпрометированный секрет).