Вы работаете в крупной компании, которая строит систему на основе микросервисной архитектуры. Вам как DevOps-специалисту необходимо выдвинуть предложение по организации инфраструктуры для разработки и эксплуатации.
Предложите решение для обеспечения процесса разработки: хранение исходного кода, непрерывная интеграция и непрерывная поставка. Решение может состоять из одного или нескольких программных продуктов и должно описывать способы и принципы их взаимодействия.
Решение должно соответствовать следующим требованиям:
- облачная система;
- система контроля версий Git;
- репозиторий на каждый сервис;
- запуск сборки по событию из системы контроля версий;
- запуск сборки по кнопке с указанием параметров;
- возможность привязать настройки к каждой сборке;
- возможность создания шаблонов для различных конфигураций сборок;
- возможность безопасного хранения секретных данных (пароли, ключи доступа);
- несколько конфигураций для сборки из одного репозитория;
- кастомные шаги при сборке;
- собственные докер-образы для сборки проектов;
- возможность развернуть агентов сборки на собственных серверах;
- возможность параллельного запуска нескольких сборок;
- возможность параллельного запуска тестов.
Обоснуйте свой выбор.
Представим, у нас есть backend, который отдает апи для админки, для пользователей, и для других сервисов. И есть frontend два web клиента (для админки, для пользователей), и либа (для взаимодействия с апи для других сервисов) для подключения к другим сервисам. Все эти 4 проекта находятся в разных репозиториях. Backend в данном случае может являться как одним сервисом, так и группой из микросервисов. Рассмотрим простой случай, когда это один сервис.
Для развертывания проектов, и хранения либ, можно взять один из вариантов облачных систем: Yandex cloud, Amazon cloud.
Для работы с репозиториями можно взять gitlab - популяное и самодостаточное решение на сегодняшний день. Каждый из проектов, включая либу, будет жить в отдельном репозитории.
При любом коммите я бы сделал запуск ci, т.е. событие - коммит.
Возможность перезапуска имеется по умолчанию, а конфиги можно менять в настройках конфигурации, если хотим запуск с другими параметрами, либо можно сделать отдельную кнопку, где будут на лету переопределяться параметры, при её клике. Обычно это делают для поднятия стендов вручную, например для стенда для тестирования ручками QA, чтобы экономить ресурсы, т.к. этот стенд не всегда нужен.
Привязка настроек к сборке осуществляется через файл .gitlab.yml и конфигурационных параметров, заданных во владке конфигов.
Шаблоны можно использовать с наследованием, чтобы для разных репозиториев не создавать копии шаблонов, и чтобы были стандарты и быстрое написание конфиг, которые наследуются от базовых, и лишь переопределяют некоторые параметры.
В gitlab есть хранение конфиг в засекреченном виде и с возможность ограничить доступы до этих конфиг. Если мы хотим поместить секреты прямо в проект, тогда можно воспользоваться ansible-vault, а ключ для шифрования/расшифровки хранить в gitlab в засекреченном виде, доступ к которому будет только у devops и ответственного за проект программиста. Он же и будет заниматься шифрованием данных.
Несколько конфигураций для сборки из одного репозитория. Делается это через передачу различных ENVs, которые предоставляет само приложение. Таким образом можно развернуть разные стенды.
Кастомные шаги при сборке. Настраивается в .gitlab.yml, можно сделать как параллельные шаги, так и последовательные, с остановкой и зависимостями от результата предыдущих шагов.
Собственные докер-образы для сборки проектов. В gitlab есть хранилище для хранения этих образов с версионированием. Можно и этот процесс автоматизировать, когда успешно пройдут все тесты.
Возможность развернуть агентов сборки на собственных серверах. В gitlab есть такая возможность, там они называются runners. Можно как на той же машине их поднимать, так и на удаленных. И настраивать к какому проекту какие будут подключены для использования. Можно одну мощную тачку использовать, которая будет запускать сборки разных проектов или даже одного для разных веток, параллельно.
Выбрал gitlab, т.к. в нём все сразу есть, не нужно устанавливать множество ПО и связывать их.
Предложите решение для обеспечения сбора и анализа логов сервисов в микросервисной архитектуре. Решение может состоять из одного или нескольких программных продуктов и должно описывать способы и принципы их взаимодействия.
Решение должно соответствовать следующим требованиям:
- сбор логов в центральное хранилище со всех хостов, обслуживающих систему;
- минимальные требования к приложениям, сбор логов из stdout;
- гарантированная доставка логов до центрального хранилища;
- обеспечение поиска и фильтрации по записям логов;
- обеспечение пользовательского интерфейса с возможностью предоставления доступа разработчикам для поиска по записям логов;
- возможность дать ссылку на сохранённый поиск по записям логов.
Обоснуйте свой выбор.
ELK stack (elasticsearch, kibana, logstash, filebeat, либо fluentid)
Все логи должны быть одного формата на всех сервисах, и все они должны выгружаться в stdout, разработчики должны позаботиться об этом.
Далее на каждом узле должен быть установлен filebeat, который будет сбоирать логи и передавать их в logstash. logstash будет их модифицировать к нужному форматы и передавать в кластер центрального хранилища elasticsearch. kibana - UI инструмент для поиска, фильтрации логов, и возможностью передачи ссылок, т.к. эта фильтрация работает через get запросы.
Предложите решение для обеспечения сбора и анализа состояния хостов и сервисов в микросервисной архитектуре. Решение может состоять из одного или нескольких программных продуктов и должно описывать способы и принципы их взаимодействия.
Решение должно соответствовать следующим требованиям:
- сбор метрик со всех хостов, обслуживающих систему;
- сбор метрик состояния ресурсов хостов: CPU, RAM, HDD, Network;
- сбор метрик потребляемых ресурсов для каждого сервиса: CPU, RAM, HDD, Network;
- сбор метрик, специфичных для каждого сервиса;
- пользовательский интерфейс с возможностью делать запросы и агрегировать информацию;
- пользовательский интерфейс с возможностью настраивать различные панели для отслеживания состояния системы.
Обоснуйте свой выбор.
prometheus + grafana
prometheus - БД временных рядов. Поддерживает сбор данных из различных источников. Имеются инструменты для анализа данных, подсистема уведомлений.
В grafana можно настроить dashboard под любые нужды, который будет работать в реальном времени.
Продолжить работу по задаче API Gateway: сервисы, используемые в задаче, пишут логи в stdout.
Добавить в систему сервисы для сбора логов Vector + ElasticSearch + Kibana со всех сервисов, обеспечивающих работу API.
docker compose файл, запустив который можно перейти по адресу http://localhost:8081, по которому доступна Kibana. Логин в Kibana должен быть admin, пароль qwerty123456.
Продолжить работу по задаче API Gateway: сервисы, используемые в задаче, предоставляют набор метрик в формате prometheus:
- сервис security по адресу /metrics,
- сервис uploader по адресу /metrics,
- сервис storage (minio) по адресу /minio/v2/metrics/cluster.
Добавить в систему сервисы для сбора метрик (Prometheus и Grafana) со всех сервисов, обеспечивающих работу API. Построить в Graphana dashboard, показывающий распределение запросов по сервисам.
docker compose файл, запустив который можно перейти по адресу http://localhost:8081, по которому доступна Grafana с настроенным Dashboard. Логин в Grafana должен быть admin, пароль qwerty123456.
Выполненное домашнее задание пришлите ссылкой на .md-файл в вашем репозитории.