Раздел 19. Практические задания
Задания раздела аналитические. Ни одно не требует установленного Docker: все они про решения, а не про команды.
Это соответствует содержанию раздела. Границы применимости, выбор средства изоляции и антипаттерны — вещи, которые определяются до запуска, а не выясняются по его результатам.
Раздел последний, поэтому задания 3 и 6 опираются на весь курс, а не только на этот раздел.
Как проверять себя
| Формулировка | Что требуется |
|---|---|
| «обосновать» | Причина, из которой следует вывод |
| «оценить риск» | Что произойдёт и насколько вероятно — раздельно |
| «приоритизировать» | Порядок с указанием признака, по которому он получен |
| «назвать альтернативу» | Конкретный инструмент и цена перехода на него |
| «отметить» | Явное указание, что шаг не выполнялся, и почему |
Задание 1. Проверка своего проекта по каталогу
Тип: обязательное
Материал: 19.4
Проверить собственный проект по каталогу антипаттернов.
Требования:
- Проверку выполнить программой, а не чтением: не менее пятнадцати правил.
- Каждая находка содержит код, место, серьёзность и способ исправления.
- Прогнать линтер на заведомо чистой конфигурации и убедиться, что находок нет.
- Отдельно перечислить антипаттерны, которых линтер не обнаруживает.
- Ответить на организационные вопросы каталога вручную — их проверить нечем.
Проверка
python3 lint.py Dockerfile compose.yaml; echo "код: $?"
python3 lint.py Dockerfile.reference compose.reference.yaml; echo "код: $?"
Критерий
Второй прогон даёт ноль находок высокой серьёзности. Без этого первый ничего не значит: инструмент, отмечающий любую конфигурацию, неотличим от сломанного.
Ответы на организационные вопросы записаны — они не выводятся ни из какого файла.
Ориентир: организационные вопросы
| Вопрос | Как проверить |
|---|---|
| Кто, кроме вас, может собрать этот образ? | Назвать имя |
| Когда последний раз обновлялся базовый образ? | Дата |
| Кто читает отчёты сканирования? | Назвать имя или признать, что никто |
| Что произойдёт, если завтра потерять том с данными? | Описать процедуру |
| Почему этот сервис вообще в container'е? | Назвать свойство, которое пропадёт без него |
Ноль находок линтера ни на один из пяти вопросов не отвечает.
Задание 2. Обоснование трёх исправлений
Тип: обязательное
Материал: 19.4
Взять три находки из задания 1 и написать обоснование исправления с оценкой риска.
Требования:
- Для каждой находки — что произойдёт, если не исправлять, и насколько это вероятно.
- Разделить «последствие» и «вероятность»: это разные оси.
- Оценить стоимость исправления в том же масштабе, что и риск.
- Указать, какие находки исправлять не нужно, и объяснить почему.
- Получить порядок исправления, выведенный из чисел, а не назначенный.
Критерий
Хотя бы одна находка помечена как «не исправлять» с обоснованием. Каталог перечисляет антипаттерны, а не приговоры: bind mount каталога хоста на машине разработчика — не проблема.
Порядок получен сортировкой, а не написан от руки.
Ориентир: разделение осей
последствие × вероятность = риск
риск / стоимость исправления = приоритет
Типичная ошибка — сводить всё к одной оценке «серьёзности». Тогда chmod 777 в образе для локальной разработки и секрет в ENV эксплуатационного образа получают одинаковый вес, хотя первый почти безвреден, а второй уже произошёл.
Задание 3. Нужна ли контейнеризация
Тип: обязательное
Материал: 19.1, 19.3
Взять задачу из своей практики и решить, нужна ли ей контейнеризация.
Требования:
- Ответить на главный вопрос: что перестанет работать, если убрать Docker?
- Сопоставить задачу с семью случаями из урока 19.3.
- Если случай попал в список — проверить, не снимается ли он условием.
- Назвать конкретную альтернативу и то, чем за неё платят.
- Оценить стоимость обоих вариантов, разделив разовую и постоянную части.
- Сформулировать вывод так, чтобы с ним можно было спорить по существу.
Критерий
Вывод «Docker оправдан» — полноценный результат. Если инструмент рассуждения приводит к отказу в любой задаче, он бесполезен так же, как приводящий к согласию.
Ответ на первый вопрос — не «удобство», а конкретное свойство: одинаковость окружения, единообразие доставки, упаковка зависимостей.
Ориентир: что считается настоящим доводом
| Довод | Настоящий? |
|---|---|
| «Зависимости не ставятся из репозитория дистрибутива» | Да |
| «Машин четыре, окружения должны совпадать» | Да |
| «Нужна воспроизводимая сборка и SBOM» | Да |
| «Так делают все» | Нет |
| «Потом пригодится» | Нет, пока нет данных о росте |
| «У нас уже есть Docker» | Нет: это не свойство задачи |
Задание 4. Требования к observability
Тип: дополнительное
Материал: 19.1, раздел 13
Сформулировать, какие требования к наблюдаемости добавляет переход в containers.
Требования:
- Показать удлинение пути от симптома к причине числом уровней.
- Для каждого добавленного уровня назвать, что на нём может пойти не так.
- Назвать, чем этот уровень наблюдается: команда или источник данных.
- Показать случай, где
docker logsпуст, а причина существует. - Сформулировать минимальный набор требований к приложению.
Критерий
Случай с пустым docker logs разобран конкретно: процесс, убитый по превышению памяти, не пишет в лог приложения — запись делает ядро, и она видна в dmesg и в событиях Docker, а не в выводе процесса.
Набор требований выражен в проверяемых утверждениях, а не в пожеланиях.
Ориентир: минимальный набор
| Требование | Почему добавилось |
|---|---|
Логи в stdout и stderr | Файл внутри container'а не виден сборщику |
| Структурированные логи | Строки нескольких сервисов смешиваются |
| Идентификатор запроса | Путь запроса проходит через несколько container'ов |
| Healthcheck | «Запущен» перестало значить «работает» |
| Раздельные пробы | Отказ зависимости не должен вызывать перезапуск |
| Метрики из cgroup | Ограничения ресурсов появились и стали причиной отказов |
Шесть требований, и ни одно не нужно было до контейнеризации.
Задание 5. База данных в container'е
Тип: дополнительное
Материал: 19.1, раздел 07
Описать сценарий, где контейнеризация базы данных оправдана, и сценарий, где нет.
Требования:
- Оба сценария описать одинаково подробно.
- Назвать признак, по которому они различаются, — один, а не список.
- Ответить на шесть вопросов о данных для каждого сценария.
- Показать, что «оправдано» не означает «без работы».
- Назвать вариант, который снимает вопрос целиком.
Критерий
Различающий признак назван один. Если их получается несколько, разбор не доведён: как правило, все они сводятся к вопросу «что произойдёт при потере тома».
Третий вариант — управляемая база вне кластера или вне машины — назван, потому что он снимает не часть вопросов, а все шесть.
Ориентир: шесть вопросов
| Вопрос | Кто отвечает |
|---|---|
| Как делается резервная копия? | Вы |
| Как проверяется, что копия восстанавливается? | Вы |
| Как восстановить состояние на конкретный момент? | Вы |
| Что с правами на файлы тома? | Вы |
| Как переносится том между машинами? | Вы |
| Как обновляется версия СУБД с миграцией данных? | Вы |
Docker не отвечает ни на один. Это не упрёк: он этим не занимается. Упрёк — считать, что «база в Docker» означает решённую задачу.
Задание 6. Ревью чужого репозитория ★
Тип: повышенной сложности
Материал: весь курс
Провести ревью чужого репозитория с Docker-конфигурацией и написать отчёт.
Требования:
- Не менее пяти находок, каждая с последствием, а не с нарушенным правилом.
- Приоритизация по признаку, который назван и применён программно.
- Разделить находки на устраняемые в конфигурации и требующие изменений в коде.
- Назвать, что в конфигурации сделано хорошо — не менее двух пунктов.
- Отдельно перечислить вопросы, на которые нельзя ответить по репозиторию.
- Отчёт должен быть таким, чтобы автор кода мог по нему работать, не оправдываясь.
Критерий
Пункт 4 обязателен и проверяется первым. Отчёт из одних находок читается как обвинение и приводит к спору вместо исправлений — независимо от того, насколько находки верны.
Пункт 5 отделяет ревью от догадок: по репозиторию не видно, сколько машин, какая нагрузка, кто дежурит и есть ли резервные копии.
Разбор
Как приоритизировать. Признак — риск, делённый на стоимость исправления:
риск = последствие × вероятность
приоритет = риск / стоимость исправления
Секрет в ENV эксплуатационного образа: последствие высокое, вероятность — единица (уже произошло), стоимость исправления низкая. Наивысший приоритет.
Отсутствие .dockerignore: последствие среднее, вероятность высокая, стоимость почти нулевая. Тоже высоко — и это тот случай, когда сортировка по одной «серьёзности» дала бы неверный порядок.
chmod 777 в образе для локальной разработки: последствие низкое, вероятность низкая. Внизу списка, а возможно — в разделе «не исправлять».
Что относится к коду, а не к конфигурации.
| Находка | Где исправлять |
|---|---|
Нет обработки SIGTERM | Код |
Нет разделения /healthz и /readyz | Код |
| Приложение падает при недоступности базы | Код |
| Логи в файл | Код |
| Конфигурация читается из файла в образе | Код |
| Всё остальное из каталога | Конфигурация |
Это различение полезно назвать прямо: пять находок из шести в столбце «код» означают, что перед автором не задача на вечер, и планировать их нужно иначе.
Что назвать хорошим. Пункты находятся всегда, если искать:
- multi-stage сборка, даже неоптимальная;
.dockerignore, даже неполный;- фиксированный тег базового образа;
USERвообще присутствует;- healthcheck есть, хотя и один на всё;
- тома объявлены, а не анонимные.
Чего не видно по репозиторию.
| Вопрос | Почему не видно |
|---|---|
| Сколько машин и какая нагрузка | Нет в файлах |
| Есть ли резервные копии и проверялось ли восстановление | Процедура вне репозитория |
| Кто дежурит и с какими знаниями | Организационное |
| Обновлялись ли базовые образы | Видно по датам сборок, а не по файлам |
| Читаются ли отчёты сканирования | Процесс, а не конфигурация |
| Почему принято решение контейнеризовать | Обсуждалось до репозитория |
Шесть вопросов, и все они весомее половины найденного. Отчёт, не называющий их, создаёт впечатление полноты, которой нет.
Форма отчёта. Три раздела: что сделано хорошо, находки в порядке приоритета, вопросы к автору. Именно в этом порядке — он определяет, будет ли отчёт прочитан до конца.
Сводная таблица
| № | Задание | Тип | Основной материал |
|---|---|---|---|
| 1 | Проверка своего проекта по каталогу | обяз. | 19.4 |
| 2 | Обоснование трёх исправлений | обяз. | 19.4 |
| 3 | Нужна ли контейнеризация | обяз. | 19.3 |
| 4 | Требования к observability | доп. | 19.1 |
| 5 | База данных в container'е | доп. | 19.1 |
| 6 | Ревью чужого репозитория | ★ | весь курс |
Что должно получиться
После задания 1 у вас есть работающий линтер — и, что важнее, привычка проверять его на входе, который обязан пройти.
Задание 2 переводит каталог из списка правил в инструмент планирования: часть находок не подлежит исправлению, и это нормальный результат.
Задание 3 — единственное в курсе, где допустимый ответ звучит «Docker здесь не нужен». Курс из девятнадцати разделов об инструменте обязан заканчиваться умением от него отказаться.
Задания 4 и 5 закрывают два места, где контейнеризация чаще всего применяется по инерции: наблюдаемость, которую не подняли до нового уровня сложности, и база данных, помещённая в container без ответа на вопрос о восстановлении.
Задание 6 — проверка на то, чему курс учил всё это время: находить причину, а не нарушение правила, и называть цену, а не только выгоду.
Что этот раздел меняет в работе
До него вопрос звучал «как правильно контейнеризовать?». После — «нужно ли, и что мы за это платим?».
Практическое следствие проявляется на ревью. Разговор смещается с «здесь не по гайдлайну» на «здесь произойдёт вот что, вероятность такая, исправление стоит столько» — и на такой разговор отвечают исправлениями, а не возражениями.
Второе следствие незаметнее. Каждая проверка в этом разделе — линтер, разбор unit-файла, оценка изоляции — проверялась на входе, который обязан пройти. Это не приём раздела о Docker, а общее правило: «ноль находок» означает что-то только тогда, когда доказано, что находки бывают, и что бывает их отсутствие.
Что дальше
Курс закончен. Проверьте себя и продолжите:
- Итоговый теоретический тест и практический экзамен;
- Проект 4. Production pipeline, если он ещё не выполнен;
- Справочники — то, к чему возвращаются после курса;
- План дальнейшего развития.
Навигация
← Предыдущий материал
Вернуться к разделу
К справочникам →
Главное оглавление