Выполнение [домашнего задания](https://github.com/netology-code/devkub-homeworks/blob/main/11-microservices-03-approaches.md)
по теме "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](https://github.com/prometheus/node_exporter).
Этого же агента можно использовать для сбора информации о docker-контейнерах,
что покроет потребность в отслеживании потребляемых ресурсов каждым сервисом.

Специфичные метрики можно отправлять как непосредственно изнутри приложений, так и при помощи [`push gateway`](https://prometheus.io/docs/practices/pushing/).

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