Вы работаете в крупной компании, которая строит систему на основе микросервисной архитектуры. Вам как DevOps-специалисту необходимо выдвинуть предложение по организации инфраструктуры для разработки и эксплуатации.
Предложите решение для обеспечения процесса разработки: хранение исходного кода, непрерывная интеграция и непрерывная поставка. Решение может состоять из одного или нескольких программных продуктов и должно описывать способы и принципы их взаимодействия.
Решение должно соответствовать следующим требованиям:
- облачная система;
- система контроля версий Git;
- репозиторий на каждый сервис;
- запуск сборки по событию из системы контроля версий;
- запуск сборки по кнопке с указанием параметров;
- возможность привязать настройки к каждой сборке;
- возможность создания шаблонов для различных конфигураций сборок;
- возможность безопасного хранения секретных данных (пароли, ключи доступа);
- несколько конфигураций для сборки из одного репозитория;
- кастомные шаги при сборке;
- собственные докер-образы для сборки проектов;
- возможность развернуть агентов сборки на собственных серверах;
- возможность параллельного запуска нескольких сборок;
- возможность параллельного запуска тестов.
Обоснуйте свой выбор.
Для организации процесса разработки микросервисной системы я бы предложил использовать сервисы Yandex Cloud. В качестве основной платформы для хранения исходного кода и CI/CD можно использовать Yandex Managed Service for GitLab, а для развертывания приложений — Managed Service for Kubernetes.
Такое решение удобно тем, что вся инфраструктура находится в одном облаке: хранение исходного кода, запуск сборок, хранение Docker-образов, управление секретами и эксплуатация приложений. Это особенно важно в микросервисной архитектуре, где количество сервисов может быть большим, а процессы сборки и доставки должны быть максимально автоматизированы.
| Требование | Реализация |
|---|---|
| Облачная система | Все сервисы размещаются в Yandex Cloud |
| Система контроля версий Git | Используется Managed Service for GitLab |
| Репозиторий на каждый сервис | Для каждого микросервиса создаётся отдельный репозиторий |
| Запуск сборки по событию | Pipeline запускается по push, merge request или tag |
| Запуск сборки по кнопке с указанием параметров | Ручной запуск pipeline с передачей переменных |
| Возможность привязать настройки к каждой сборке | CI/CD Variables, Environment Variables |
| Возможность создания шаблонов для различных конфигураций сборок | Общие шаблоны .gitlab-ci.yml, include |
| Безопасное хранение секретных данных | GitLab Protected Variables + Yandex Lockbox |
| Несколько конфигураций для сборки из одного репозитория | Разные pipeline/jobs для dev, stage, prod |
| Кастомные шаги при сборке | Любые shell-команды внутри pipeline |
| Собственные Docker-образы для сборки проектов | Использование собственных build-образов |
| Возможность развернуть агентов сборки на собственных серверах | Self-hosted GitLab Runner |
| Возможность параллельного запуска нескольких сборок | Несколько GitLab Runner-ов |
| Возможность параллельного запуска тестов | Parallel jobs, matrix builds |
Выбор пал на Yandex Cloud, потому что это удобная облачная платформа, которая позволяет закрыть весь жизненный цикл разработки и эксплуатации приложений в рамках одной экосистемы.
Для микросервисной архитектуры это особенно удобно, так как каждый сервис развивается независимо, но при этом используется единый процесс сборки, тестирования и доставки.
Дополнительным преимуществом является возможность запускать собственные GitLab Runner на своих серверах. Это полезно в корпоративной среде, где часть инфраструктуры может быть закрыта от внешнего доступа.
Использование Kubernetes делает эксплуатацию микросервисов более удобной и масштабируемой, а Yandex Lockbox позволяет безопасно работать с секретами.
Предложите решение для обеспечения сбора и анализа логов сервисов в микросервисной архитектуре. Решение может состоять из одного или нескольких программных продуктов и должно описывать способы и принципы их взаимодействия.
Решение должно соответствовать следующим требованиям:
- сбор логов в центральное хранилище со всех хостов, обслуживающих систему;
- минимальные требования к приложениям, сбор логов из stdout;
- гарантированная доставка логов до центрального хранилища;
- обеспечение поиска и фильтрации по записям логов;
- обеспечение пользовательского интерфейса с возможностью предоставления доступа разработчикам для поиска по записям логов;
- возможность дать ссылку на сохранённый поиск по записям логов.
Обоснуйте свой выбор.
Для организации централизованного сбора и анализа логов в микросервисной архитектуре я бы предложил использовать связку Fluentd + ELK-стек (Elasticsearch + Logstash + Kibana).
Это одно из наиболее распространённых решений для централизованного логирования в распределённых системах. Такой подход хорошо подходит для микросервисной архитектуры, так как позволяет собирать логи со всех сервисов в одном месте, анализировать их и предоставлять удобный доступ разработчикам и администраторам.
Каждый микросервис пишет логи в стандартный вывод:
stdout
stderr
Это удобный подход, потому что приложения не нужно дорабатывать под конкретную систему логирования. Они просто пишут сообщения в стандартный поток, а инфраструктура уже отвечает за их дальнейшую доставку и обработку.
На каждом хосте или Kubernetes-ноде запускается Fluentd, который собирает логи контейнеров, при необходимости добавляет метаданные и отправляет их дальше.
После этого логи передаются в Logstash, где можно выполнять дополнительную обработку.
Затем обработанные логи попадают в Elasticsearch, где индексируются и становятся доступными для быстрого поиска.
Для пользователей используется Kibana, которая предоставляет веб-интерфейс для анализа логов.
| Требование | Реализация |
|---|---|
| Сбор логов в центральное хранилище со всех хостов | Fluentd устанавливается на каждый хост или Kubernetes-ноду |
| Минимальные требования к приложениям | Приложения пишут логи только в stdout / stderr |
| Сбор логов из stdout | Fluentd собирает контейнерные логи из stdout/stderr |
| Гарантированная доставка логов | Fluentd поддерживает буферизацию и повторную отправку |
| Поиск и фильтрация по логам | Elasticsearch обеспечивает быстрый поиск и фильтрацию |
| Пользовательский интерфейс | Kibana предоставляет веб-интерфейс |
| Доступ разработчикам | Можно настроить пользователей и роли |
| Возможность передать ссылку на поиск | Kibana позволяет сохранять поисковые запросы и делиться ссылками |
Выбор пал на связку Fluentd + ELK, потому что это проверенное и широко используемое решение для централизованного логирования в распределённых системах.
Преимущества такого подхода:
- минимальные требования к приложениям;
- централизованный сбор логов;
- удобный поиск и фильтрация;
- гибкая обработка логов;
- доступ разработчиков через веб-интерфейс;
- возможность сохранять поисковые запросы;
- хорошая масштабируемость при росте количества сервисов.
ELK-стек особенно хорошо подходит для микросервисной архитектуры, где сервисы могут генерировать большое количество логов в разных форматах.
Предложите решение для обеспечения сбора и анализа состояния хостов и сервисов в микросервисной архитектуре. Решение может состоять из одного или нескольких программных продуктов и должно описывать способы и принципы их взаимодействия.
Решение должно соответствовать следующим требованиям:
- сбор метрик со всех хостов, обслуживающих систему;
- сбор метрик состояния ресурсов хостов: CPU, RAM, HDD, Network;
- сбор метрик потребляемых ресурсов для каждого сервиса: CPU, RAM, HDD, Network;
- сбор метрик, специфичных для каждого сервиса;
- пользовательский интерфейс с возможностью делать запросы и агрегировать информацию;
- пользовательский интерфейс с возможностью настраивать различные панели для отслеживания состояния системы.
Обоснуйте свой выбор.
Для организации мониторинга в микросервисной архитектуре я бы предложил использовать связку Prometheus + Grafana + Exporters.
Это одно из самых распространённых решений для мониторинга современных распределённых систем. Такой подход позволяет централизованно собирать метрики с хостов, контейнеров и самих приложений, а также визуализировать их в удобном интерфейсе.
Система мониторинга строится вокруг Prometheus, который выступает как центральное хранилище метрик.
Prometheus по заданному расписанию опрашивает источники метрик (pull model) и сохраняет полученные данные.
Для сбора информации используются разные компоненты:
- Node Exporter — собирает метрики состояния хостов;
- cAdvisor — собирает метрики контейнеров;
- kube-state-metrics — предоставляет информацию о состоянии объектов Kubernetes;
- application exporters — предоставляют метрики самих приложений.
После сбора метрики визуализируются в Grafana, где можно строить панели мониторинга и выполнять анализ.
| Требование | Реализация |
|---|---|
| Сбор метрик со всех хостов | Node Exporter устанавливается на каждый хост |
| CPU, RAM, HDD, Network для хостов | Node Exporter |
| Метрики ресурсов каждого сервиса | cAdvisor + Kubernetes metrics |
| Метрики, специфичные для сервисов | Prometheus application metrics / exporters |
| Интерфейс с запросами и агрегацией | Grafana + PromQL |
| Настраиваемые панели мониторинга | Grafana dashboards |
Выбор пал на связку Prometheus + Grafana, потому что это стандарт де-факто для мониторинга микросервисной инфраструктуры.
Преимущества:
- хорошо подходит для Kubernetes;
- поддерживает мониторинг как инфраструктуры, так и приложений;
- легко масштабируется;
- поддерживает пользовательские метрики;
- имеет мощный язык запросов;
- предоставляет удобный интерфейс визуализации.
Такой подход позволяет контролировать как техническое состояние инфраструктуры, так и бизнес-показатели приложений.