Практические проекты

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

Проекты отличаются от exercises.md разделов масштабом и режимом. Упражнение проверяет одну тему и даёт готовый ответ. Проект требует собрать вместе материал нескольких разделов, принять собственные решения и обосновать их.

Порядок выполнения

Проекты выполняются строго по порядку: каждый следующий переиспользует код и решения предыдущего. Проект 2 развивает сервис, который затем встраивается в стек проекта 3, а проект 4 строит для него pipeline.

Состав каждого проекта

Правильный порядок работы

1. Прочитать TASK.md целиком, включая критерии завершения. Знание критериев до начала работы — не подсказка, а нормальная инженерная практика.
2. Реализовать самостоятельно. Обращаться к разделам курса и официальной документации можно и нужно; к SOLUTION.md — нет.
3. Пройти CHECKLIST.md. По каждому пункту выполнить указанную команду и сравнить вывод. Пункт не засчитывается по ощущению «вроде работает».
4. Открыть SOLUTION.md и сравнить с собственной реализацией.
5. Разобрать расхождения. Где эталон лучше и почему? Где ваше решение обоснованнее? Этот шаг даёт больше остальных четырёх.

Эталонное решение — не единственно верное. В SOLUTION.md явно отмечены места, где возможны другие обоснованные варианты.

Проект 1. Python CLI

Контейнеризованное CLI-приложение, обрабатывающее данные.

Требования: разбор аргументов командной строки, чтение конфигурации из файла и environment, вывод результата в stdout и диагностики в stderr, корректные exit codes для разных ошибок, unit tests, сборка через Dockerfile с работающим build cache.

Что проверяет: базовую контейнеризацию, различие ENTRYPOINT и CMD, передачу аргументов в container, работу со стандартными потоками, exit codes.

Типичная ошибка: использование shell form, из-за которой аргументы не доходят до приложения, а exit code теряется.

Техническое задание →

Проект 2. FastAPI service

REST API, готовый к эксплуатации.

Требования: несколько endpoint с валидацией, health endpoint, конфигурация через environment variables с валидацией при старте, structured logging в JSON, graceful shutdown с завершением активных запросов, non-root user, multi-stage build, tests, образ менее 200 MB.

Что проверяет: multi-stage builds, оптимизацию слоёв, обработку сигналов в ASGI-приложении, работу с портами и сетью, безопасный запуск.

Типичная ошибка: привязка к 127.0.0.1 вместо 0.0.0.0, из-за которой сервис недоступен снаружи container.

Техническое задание →

Проект 3. Multi-service stack

Полная система из пяти компонентов на Docker Compose.

Требования: FastAPI из проекта 2, PostgreSQL, Redis, background worker, сервис миграций. Healthchecks у каждого компонента, зависимости по готовности, две изолированные сети, named volumes, resource limits, integration tests с реальной базой, конфигурации для разработки и тестирования.

Что проверяет: проектирование системы целиком, понимание разницы между «запущен» и «готов», изоляцию сетей, управление состоянием, автоматизированное тестирование с зависимостями.

Типичная ошибка: depends_on без условия готовности — приложение стартует и падает на подключении к базе.

Техническое задание →

Проект 4. Production pipeline

Полный цикл доставки для сервиса из проекта 3.

Требования: production-ready образ с hardening, CI pipeline с проверками, тестами, сборкой с кэшем и integration tests на собранном образе, сканирование уязвимостей, генерация SBOM, tagging по commit SHA, публикация в registry, deployment checklist и rollback plan.

Что проверяет: интеграцию всего материала курса, требования эксплуатации, безопасность цепочки поставок, воспроизводимость доставки.

Типичная ошибка: развёртывание по подвижному тегу, из-за которого откат на «предыдущую версию» не гарантирует того же артефакта.

Техническое задание →

Оценивание

Каждый проект оценивается по rubric, шкала 0–100.

Проходной результат — 70. Независимо от суммы баллов работа не принимается при нарушении blocking-требований: секреты в слоях образа, запуск от root без обоснования, невоспроизводимость с чистой машины, development server в production-конфигурации, отсутствие реакции на SIGTERM.

Проекты дают 40 % итогового балла курса. Подробнее: система оценивания.

Что делать, если застряли

1. Перечитайте раздел курса, на который опирается текущий шаг — ссылки есть в TASK.md для каждого шага.
2. Проверьте гипотезу командой, а не рассуждением. docker inspect, docker logs, docker exec отвечают быстрее размышлений.
3. Сведите к минимальному примеру. Если не работает сложная конфигурация — воспроизведите проблему на минимальной.
4. Загляните в debugging checklist — большинство проблем в проектах уже описаны там.
5. Откройте SOLUTION.md частично. Он структурирован по шагам: можно посмотреть один шаг, не читая остальное.

Навигация

Вернуться к главному оглавлению
Система оценивания
Справочники