dannc/netology-devops
1
0
Fork 0
mirror of https://github.com/Dannecron/netology-devops.git synced 2025-12-25 23:32:37 +03:00
Code Issues Packages Projects Releases Wiki Activity

homework 11.3: complete homework

Browse Source
This commit is contained in:
dannc
2022-10-25 16:55:18 +07:00
parent fb4b18368b
commit 61a95ffd50
3 changed files with 93 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
src/homework/11-microservices/11.2/readme.md
View File

@@ -5,7 +5,6 @@
### Задание 1
> Предложите решение для обеспечения реализации API Gateway.
> Составьте сравнительную таблицу возможностей различных программных решений. На основе таблицы сделайте выбор решения.
>

92
src/homework/11-microservices/11.3/readme.md Normal file
View File

@@ -0,0 +1,92 @@
Выполнение [домашнего задания](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.