Checkpoints

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

Checkpoint отличается от exercises.md раздела тем, что не подсказывает, какой материал применить. В упражнении раздела 08 понятно, что задача про сеть. В checkpoint дан симптом, и часть работы — определить, где искать.

Правило приёмки: checkpoint не пройден, пока не выполнены все критерии. Частичное выполнение не засчитывается — частично работающий сервис в эксплуатации равен неработающему.

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

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

Checkpoint 1: Container как процесс

После разделов: 01–04
Время: 2 часа
Проверяет: понимание того, что container — это процесс, а не машина

Часть A. Диагностика

Дан образ, собранный из такого Dockerfile:

FROM python:3.13-slim
WORKDIR /app
COPY worker.py .
CMD python worker.py

worker.py:

import signal
import sys
import time


def on_term(signum, frame):
    print("получен SIGTERM, завершаюсь", flush=True)
    sys.exit(0)


signal.signal(signal.SIGTERM, on_term)
print("работаю", flush=True)
while True:
    time.sleep(1)

Симптомы:

$ docker run -d --name w worker
a1b2c3d4e5f6

$ docker logs w
работаю

$ time docker stop w
w

real    0m10.412s

Остановка занимает ровно десять секунд. Строка «получен SIGTERM» в логах не появляется — при том, что обработчик написан и заведомо работает при запуске скрипта напрямую.

Задача. Назвать причину, подтвердить её командой и исправить.

docker exec w ps -eo pid,ppid,cmd

docker exec w ps -eo pid,ppid,cmd

  PID  PPID CMD
    1     0 /bin/sh -c python worker.py
    7     1 python worker.py

CMD ["python", "worker.py"]

  PID  PPID CMD
    1     0 python worker.py

time docker stop w

Часть B. Задание

Собрать образ инструмента, который:

1. принимает аргументы через docker run;
2. читает стандартный ввод;
3. возвращает три различимых кода возврата;
4. корректно завершается по docker stop менее чем за секунду;
5. печатает результат в stdout, диагностику в stderr.

Приложение может быть любым — достаточно тридцати строк Python.

Критерии приёмки

Шесть из шести — checkpoint пройден. Пять из шести — не пройден.

Checkpoint 2: Сборка и многокомпонентная система

После разделов: 05–09
Время: 3 часа
Проверяет: оптимизацию сборки, сети, тома, зависимости по готовности

Часть A. Диагностика

Дан compose.yaml:

services:
  api:
    build: .
    ports:
      - "8080:8000"
    environment:
      DATABASE_URL: postgresql://app:secret@localhost:5432/appdb
    depends_on:
      - db

  db:
    image: postgres:17-alpine
    environment:
      POSTGRES_DB: appdb
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret

Симптомы. docker compose up запускает оба сервиса, db работает, а api перезапускается с ошибкой:

api-1  | connection to server at "localhost" (127.0.0.1), port 5432 failed:
api-1  | Connection refused
api-1  |     Is the server running on that host and accepting connections?

При этом docker compose exec api ping db отвечает.

Задача. Найти две независимые ошибки. Симптом виден один, причин две, и исправление только одной оставит проблему.

DATABASE_URL: postgresql://app:secret@db:5432/appdb

services:
  api:
    depends_on:
      db:
        condition: service_healthy

  db:
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d appdb"]
      interval: 5s
      timeout: 3s
      retries: 10
      start_period: 10s

Часть B. Задание

Собрать стек из трёх сервисов: приложение, база данных, кэш.

Требования:

1. Multi-stage сборка приложения; инструментов сборки в итоговом образе нет.
2. Изменение кода приложения не пересобирает зависимости.
3. Две сети: база и кэш недоступны снаружи.
4. Именованный том для данных базы.
5. Healthcheck у каждого сервиса; зависимости по готовности.
6. Приложение переживает перезапуск базы без перезапуска себя.

Критерии приёмки

Восемь из восьми — checkpoint пройден.

Про критерий 7. Один успешный запуск ничего не доказывает: гонка проявляется не всегда. Десять запусков подряд — минимальная проверка воспроизводимости.

Checkpoint 3: Production и диагностика

После разделов: 10–13
Время: 3 часа
Проверяет: готовность к эксплуатации и умение расследовать

Часть A. Диагностика

Симптом. Сервис работает часами, затем исчезает. В docker logs — ничего необычного: последняя строка выглядит как обычный обработанный запрос. Перезапуск помогает на несколько часов.

$ docker inspect api --format '{{.State.Status}} {{.State.ExitCode}} {{.State.OOMKilled}}'
exited 137 true

Задача. Объяснить, что произошло, почему в логах приложения ничего нет, и назвать, какие данные нужны, чтобы предсказать это заранее.

dmesg | grep -i 'killed process'
docker events --filter 'event=oom' --since 24h

docker exec api cat /sys/fs/cgroup/memory.events

low 0
high 0
max 4213
oom 12
oom_kill 3

Часть B. Задание

Привести сервис из checkpoint 2 в состояние, пригодное для эксплуатации:

1. Три пробы с разной логикой: жив, готов, инициализирован.
2. Структурированные логи в stdout с идентификатором запроса.
3. Ограничения памяти и процессора, подобранные по измерению, а не наугад.
4. Ротация логов.
5. Мягкое завершение: активные запросы дорабатываются.
6. Раздел README с методикой диагностики трёх типовых отказов.

Критерии приёмки

Восемь из восьми — checkpoint пройден.

Про критерии 1 и 2. Это единственная пара, которую проверяют вместе: если обе пробы ведут себя одинаково, разделения нет, сколько бы эндпоинтов ни было объявлено.

Checkpoint 4: Доставка

После разделов: 14–16
Время: 3 часа
Проверяет: воспроизводимость доставки от коммита до образа

Часть A. Диагностика

Симптом. В эксплуатации работает не тот код, который ожидали. Развёртывание выполнено командой:

docker pull registry.example.com/team/api:prod
docker compose up -d

docker compose ps показывает container запущенным, образ — team/api:prod. Разработчик утверждает, что исправление в prod собрано и опубликовано час назад.

$ docker image inspect team/api:prod --format '{{.Id}}'
sha256:9f8e7d6c...

$ docker image inspect team/api:prod --format '{{index .RepoDigests 0}}'
registry.example.com/team/api@sha256:1a2b3c4d...

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

docker inspect container --format '{{.Image}}'
docker image inspect team/api:prod --format '{{.Id}}'

services:
  api:
    image: registry.example.com/team/api@sha256:1a2b3c4d...

Часть B. Задание

Построить конвейер доставки для стека из checkpoint 3:

1. Проверки, тесты и сборка — по возрастанию времени и убыванию вероятности отказа.
2. Логика в скриптах, а не в шагах YAML.
3. Кэш сборки, переносимый между запусками.
4. Сканирование с тремя кодами возврата: чисто, находки, не проверено.
5. SBOM, приложенный к образу.
6. Теги: SHA коммита и digest; перезаписываемых тегов нет.
7. План отката с указанием, что именно откатывается.

Критерии приёмки

Восемь из восьми — checkpoint пройден.

Про критерий 4. Он проверяет то, что обычно не проверяют: поведение конвейера при отсутствии инструмента. Сканер, которого нет, не должен выглядеть как сканер, не нашедший проблем (урок 16.4).

Сводка

Разделы 17–19 контрольных точек не имеют: они не добавляют новых навыков сборки и эксплуатации, а объясняют механизмы и границы применимости. Проверяются quiz'ами и заданиями самих разделов.

Что checkpoints проверяют, чего не проверяет остальное

Диагностические части всех четырёх устроены одинаково: симптом не указывает на раздел. Ошибка Connection refused в checkpoint 2 может быть про сеть, про порядок старта, про конфигурацию или про сам процесс — и половина работы состоит в том, чтобы это сузить.

Упражнения разделов такого дать не могут: они лежат внутри раздела, и область поиска известна заранее. В работе она неизвестна почти никогда.

Второе, общее для всех четырёх: в каждой диагностической задаче больше одной причины или больше одного правильного ответа. Checkpoint 2 содержит две независимые ошибки и третью, не дающую симптомов. Checkpoint 3 заканчивается тремя гипотезами, различить которые можно только измерением. Это ближе к тому, как выглядит расследование, чем задача с единственным ответом.

Навигация

Вернуться к системе проверки
Quizzes по разделам
Debugging challenges
Grading rubric
Главное оглавление