Итоговая самостоятельная работа

Итоговая самостоятельная работа

Дедлайн сдачи: 20 декабря

Рассмотрим audit-svc — игрушечный веб-сервис принимающий по HTTP события аудита (техническое описание смотрите в README.md репозитория). Это сервис на Python, использующий пакетный менеджер Poetry (аналогичный counter-backend, с которым мы работали на практиках ранее), но в отличии от counter-backend этому сервису для работы требуется подключение к БД PostgreSQL.

В рамках итоговой самостоятельной работы вам предстоит написать скрипты развертывания для этого сервиса, настроить хранение секретов и мониторинг.

Рассмотрим задачи детальнее.
Начнем с публикации проекта: требуется написать GitLab CI пайплайн упаковывающий сервис в Docker-образ и публикующий его на курсовой Harbor. Как пробросить настройки Harbor в пайплайн остается на ваше усмотрение: вы можете использовать интеграцию с Harbor, задать требуемые переменные вручную в настройках проекта, или же подтягивать их из курсового Vault.

После того, как вы опубликуете образ, вам предстоит развернуть сервис на ВМ2. Так как здесь мы развертываем один независимый сервис, то выносить развертывание в отдельный репозиторий необязательно. Используйте любую из рассмотренных нами технологий: Docker, Docker Compose, Ansible + коллекция community.docker.

Развертывание должно запускаться как задача в сборочном пайплайне при создании тега или по коммиту в репозиторий развертывания (задача с коммитом также должна запускаться из тега).

Рассмотрим состав развертывания:

Сервису требуется подготовленная БД в PostgreSQL: саму БД и пользователя в ней создайте при помощи роли, рассмотренной на практике. Подготовку Б Д выполните при помощи скрипта migrate в репозитории сервиса;
Параметры подключения к БД — это секреты и должны храниться соответствующе. В этой практике мы рассматривали HashiCorp Vault как хранилище секретов: используйте его, чтобы сохранить параметры подключения и отдать их сервису при развертывании.

Для передачи параметров в сам сервис используйте Vault Agent и его механизм генерации конфигов из шаблонов, который мы также рассматривали в этой практике. Чтобы автоматизировать перезагрузку сервиса при обновлении конфигурационного файла используйте опцию command, которая позволяет выполнить произвольную команду при обновлении сгенерированного файла (сервис перечитывает конфиг при вызове эндпоинта POST /reload).

Авторизацию Vault Agent в Vault также настройте аналогично этой практике — при помощи AppRole и политик, ограничивающих доступ до конкретного секрета.

Разверните вместе с сервисом Nginx и организуйте доступ так, чтобы к сервису нельзя было обратиться напрямую из внутренней подсети МТС Cloud или интернета (только через Nginx). Также ограничьте доступ к эндпоинту /reload в конфигурации Nginx так, чтобы при вызове этого эндпоинта через Nginx запрос не пробрасывался в сервис, а вместо этого возвращался HTTP код ответа 404;
Добавьте к развернутому Nginx официальный экспортер — nginx-exporter и настройте Nginx так, чтобы в экспортере была информация об развернутом инстансе (инструция по настройке есть в репозитории nginx-exporter).

В задании не требуется автоматизировать запуск миграций БД при каждом развертывании сервиса, но вы можете сделать это как дополнительное задание.

После того как вы развернете сервис требуется настроить сбор его метрик в инстанс Prometheus, развернутый ранее. Затем создайте в курсовой Grafana дэшборд, содержащий следующие метрики сервиса:

Графики присланных событий в секунду в разбивке по приложениям;
Графики распределения кодов ответа от сервиса (какой процент от всех ответов составляли ответы с кодом XXX в каждый момент времени);
Статусный блок, показывающий запущен ли сервис (воспользуйтесь системной метрикой up);

Чтобы на дэшборде отображались не нули, сгенерируйте события аудита при помощи скрипта generate в репозитории сервиса.
Затем скачайте дэшборд для мониторинга Nginx при помощи nginx-exporter и сохраните его в курсовую Grafana.

Для проверки предоставьте артефакты:
Репозиторий audit-svc, форкнутый в вашу подгруппу.
Ссылки на запуски пайплайнов сервиса:

В ветке по-умолчанию (пайплайн должен содержать сборку проекта и публикацию Docker образа)
В защищенном теге (пайплайн должен содержать либо задачу развертывания, либо запускать пайплайн развертывания);
Если пайплайн развертывания вынесен отдельно, то ссылку на его успешный запуск.

Ссылки на скрипты развертывания в курсовом GitLab, которые демонстрируют:

Запуск миграций при каждом развертывании (опционально);
Настроенную синхронизацию конфига сервиса с Vault при помощи Vault Agent.

Ссылку на развернутый сервис в подсети МТС Cloud;

Запросы к эндпоинту /reload не должны доходить до сервиса и должны возвращать HTTP код ответа 404;
Ссылку на настроенный дэшборд сервиса.