Linux для DevOps — домашнее задание

Цель

Привести намеренно сломанный сервис homework-app к точному конечному состоянию, описанному ниже. Все проблемы можно последовательно обнаружить обычными средствами диагностики Linux: угадывать скрытые значения или бесцельно искать файлы по системе не требуется.

Основной принцип работы: наблюдаем текущую ошибку → получаем подтверждающие данные → вносим одно обоснованное изменение → проверяем результат → переходим к следующей проблеме.

В процессе выполнения заполняйте REPORT.md: в нём нужно зафиксировать не только итоговые изменения, но и ход диагностики — что наблюдали, как искали причину, что изменили и почему.

Требования к окружению

Нужна свежая Linux-система с пакетным менеджером APT, в которой systemd работает как PID 1. Подойдут, например:

• Debian/Ubuntu VM на любом гипервизоре;
• Debian/Ubuntu VPS;
• WSL2 на базе Debian/Ubuntu с включённым systemd.

setup.sh самостоятельно установит необходимые для задания пакеты.

Правила

Можно изменять и коммитить:

• systemd/homework-app.service;
• config/app.conf;
• REPORT.md.

В процессе решения можно выполнять необходимые системные команды, в том числе менять права и владельцев файлов, управлять сервисом и перечитывать конфигурацию systemd. Все существенные команды и изменения, которые не отражаются в Git сами по себе, необходимо зафиксировать в REPORT.md.

Нельзя изменять:

• scripts/setup.sh;
• scripts/check.sh;
• app/server.py.

Нельзя решать проблемы с правами через chmod 777 или запуск приложения от root.

1. Подготовка окружения

Выполните:

sudo ./scripts/setup.sh

Скрипт установит необходимые пакеты, подготовит стенд и намеренно оставит сервис в неисправном состоянии.

Первая команда для диагностики задана явно:

systemctl status homework-app.service

Дальше двигайтесь от информации, которую показывает сама система. После исправления очередной проблемы перезапускайте или перечитывайте конфигурацию сервиса, если это необходимо, и снова проверяйте его состояние. Исправление одной проблемы может открыть следующую — это ожидаемое поведение задания.

В любой момент можно запустить проверку:

sudo ./scripts/check.sh

check.sh проверяет текущее состояние стенда. При ошибке он указывает только общее направление для дальнейшей диагностики и не сообщает готовую команду или способ исправления.

2. Требуемое конечное состояние

После выполнения задания система должна удовлетворять всем условиям:

1. homework-app.service запускает приложение, установленное в /opt/linux-devops-homework/.
2. Сервис работает от отдельного пользователя и группы homework, а не от root.
3. /var/lib/linux-devops-homework принадлежит homework:homework и имеет права 0750.
4. Сервис включён в автозапуск и находится в состоянии active.
5. Запущенный процесс имеет UID пользователя homework.
6. Приложение слушает TCP-порт 8080 на всех IPv4-интерфейсах (0.0.0.0:8080), а не только на loopback.
7. GET http://127.0.0.1:8080/health возвращает HTTP 200 и {"status": "ok"}.
8. Исправленные unit-файл и конфигурация приложения находятся в репозитории, а не только в системных каталогах локальной машины.
9. sudo ./scripts/check.sh завершается без ошибок.

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

Во время выполнения убедитесь, что можете объяснить ответы на следующие вопросы:

• Что systemctl status сообщил о первой проблеме?
• Как определить точный ExecStart, используемый systemd?
• Где появилась следующая ошибка приложения после исправления первой проблемы?
• От какого пользователя фактически работает процесс сервиса?
• Какие у него PID и PPID?
• Что можно подтвердить через /proc/<PID>/status, /proc/<PID>/cmdline и /proc/<PID>/fd/?
• Какие права или владельцы мешали сервису записывать данные в рабочую директорию?
• Как доказать, на каком адресе и порту слушает приложение?
• Почему 127.0.0.1:8080 не соответствует условию, а 0.0.0.0:8080 соответствует?
• Какой маршрут хост выберет до адреса 1.1.1.1? Реальное подключение к интернету для этого не требуется.
• Как после каждого изменения вы проверяли, что исправили именно наблюдаемую проблему?

Ответы на эти вопросы не нужно оформлять отдельным списком: соответствующие наблюдения и рассуждения должны быть отражены в REPORT.md по ходу решения.

3. Отчёт

В REPORT.md для каждой обнаруженной проблемы опишите:

1. что именно вы наблюдали;
2. как проводили диагностику и какие команды использовали;
3. в чём оказалась причина;
4. какие конкретно изменения файлов и/или команды исправили проблему;
5. почему было выбрано именно это решение;
6. как вы убедились, что проблема устранена.

Не ограничивайтесь перечнем команд. Отчёт должен позволять восстановить ход диагностики и понять причинно-следственную связь между наблюдаемой ошибкой и внесённым изменением.

Если изменение состояния машины не отражается в Git — например, chmod, chown, systemctl enable или другая системная команда — обязательно укажите его в отчёте.

4. Сдача работы

До завершения задания не коммитьте итоговое решение. Сначала добейтесь успешного результата:

sudo ./scripts/check.sh

Ожидаемый итог:

Результат: 10 проверок пройдено, 0 не пройдено

Добавьте итоговый вывод check.sh в REPORT.md и убедитесь, что в отчёте зафиксирован весь ход решения.

Результат домашнего задания необходимо загрузить в собственный Git-репозиторий. Не нужно создавать commit или push в исходный репозиторий с заданием.

После первоначального клонирования удалите Git-историю исходного репозитория и инициализируйте собственный:

rm -rf .git
git init

Создайте пустой репозиторий в используемом Git-сервисе, добавьте его как remote и отправьте туда выполненную работу обычным способом.

Перед итоговым commit проверьте изменения:

git diff

В репозитории должны находиться:

• исправленный systemd/homework-app.service;
• исправленный config/app.conf;
• заполненный REPORT.md;
• остальные исходные файлы задания без изменений.

Проверяться будут итоговые файлы и описанный в REPORT.md ход решения.