netology-devops/src/homework/11-microservices/11.3

Выполнение домашнего задания по теме "11.3. Микросервисы: подходы"

Q/A

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

Задание 1

Обеспечить разработку

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

Решение должно соответствовать следующим требованиям:

• Облачная система;
• Система контроля версий Git;
• Репозиторий на каждый сервис;
• Запуск сборки по событию из системы контроля версий;
• Запуск сборки по кнопке с указанием параметров;
• Возможность привязать настройки к каждой сборке;
• Возможность создания шаблонов для различных конфигураций сборок;
• Возможность безопасного хранения секретных данных: пароли, ключи доступа;
• Несколько конфигураций для сборки из одного репозитория;
• Кастомные шаги при сборке;
• Собственные докер образы для сборки проектов;
• Возможность развернуть агентов сборки на собственных серверах;
• Возможность параллельного запуска нескольких сборок;
• Возможность параллельного запуска тестов;

Обоснуйте свой выбор.

В данном случае облачный gitlab подойдёт как нельзя хорошо. А именно:

• git и гибкое управление репозиториями
• гибкая система настройки и управления CI/CD, большие возможности по кастомизации шагов сборки
• возможность хранить секреты в переменных репозитория
• присутствие приватного docker-registry для хранения собранных docker-образов

Дополнительно к gitlab необходимо будет развернуть несколько gitlab-runner, чтобы непосредственно запускать сборку. В рамках конфигурации gitlab-runner можно указывать параметры параллельного выполнения.

Задание 2

Логи

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

Решение должно соответствовать следующим требованиям:

• Сбор логов в центральное хранилище со всех хостов обслуживающих систему;
• Минимальные требования к приложениям, сбор логов из stdout;
• Гарантированная доставка логов до центрального хранилища;
• Обеспечение поиска и фильтрации по записям логов;
• Обеспечение пользовательского интерфейса с возможностью предоставления доступа разработчикам для поиска по записям логов;
• Возможность дать ссылку на сохраненный поиск по записям логов;

Обоснуйте свой выбор.

Для боевой среды может подойти решение fluentd + elk-стек. Таким образом:

• fluentd будет отвечать за сбор логов из stdout всех docker-контейнеров. Для сбора логов можно настроить для каждого контейнера лог-драйвер fluentd и избежать различных проблем при работе с файловой системой.
• logstash будет отвечать за приём логов со всех агентов fluentd и максимально преобразовывать логи к единому формату.
• кластер elasticsearch будет отвечать за хранение логов.
• kibana будет выступать в качестве пользовательского интерфейса для просмотра логов. Из коробки в данной системе доступны сохранение и шаринг поисковых запросов по логам.

Задание 3

Мониторинг

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

Решение должно соответствовать следующим требованиям:

• Сбор метрик со всех хостов, обслуживающих систему;
• Сбор метрик состояния ресурсов хостов: CPU, RAM, HDD, Network;
• Сбор метрик потребляемых ресурсов для каждого сервиса: CPU, RAM, HDD, Network;
• Сбор метрик, специфичных для каждого сервиса;
• Пользовательский интерфейс с возможностью делать запросы и агрегировать информацию;
• Пользовательский интерфейс с возможностью настраивать различные панели для отслеживания состояния системы;

Обоснуйте свой выбор.

Для сбора метрик лучше всего использовать prometheus и его агенты. Например, для сбора метрик состояния ресурсов можно использовать node_exporter. Этого же агента можно использовать для сбора информации о docker-контейнерах, что покроет потребность в отслеживании потребляемых ресурсов каждым сервисом.

Специфичные метрики можно отправлять как непосредственно изнутри приложений, так и при помощи push gateway.

Для отображения всей информации идеально подойдёт grafana, в которой возможно построить огромное множество различных графиков и показателей на основе данных prometheus.