МИКРОСЕРВИСНАЯ АРХИТЕКТУРА И CI/CD: КАК УПРАВЛЯТЬ РАЗВЕРТЫВАНИЕМ МИКРОСЕРВИСОВ

MICRO SERVICE ARCHITECTURE AND CI/CD: HOW MANAGE THE DEPLOYMENT OF MICROSERVICES

Pavel Khlopkov

student, Department of Digital Economy, Bryansk State Technical Unuversity,

Russia, Bryansk

АННОТАЦИЯ

В статье рассмотрены принципы автоматизации процессов разработки и развёртывания в микросервисной архитектуре на примере ИТ-компании ООО «НооСофт». Кратко сформулированы проблемы управления множеством независимых сервисов и цели использования CI/CD. Проанализирован опыт компании «НооСофт»: приведён стек используемых технологий (Docker, Docker Compose, GitLab CI/CD, Nginx, Apache2, Python, Node.js, PHP) и описана существующая схема работы CI/CD и развёртывания как на облачных хостингах, так и на собственном сервере (Debian 12, FastPanel2, Portainer). Приведены примеры типовых конфигураций (фрагменты .gitlab-ci.yml , docker-compose.yml , Dockerfile ). Показаны упрощённые схемы архитектуры CI/CD (AS-IS) и перспективной архитектуры (TO-BE) с помощью синтаксиса mermaid. Описаны характерные сложности при управлении микросервисами (сетевая связность, согласованность версий, централизованное логирование, откат). Предложены рекомендации по улучшению: внедрение сервис-мешей для управления коммуникацией между сервисами, централизованный мониторинг, а также стратегии деплоя (Blue-Green, Canary) для снижения рисков. Представлены таблицы сравнения подходов к развёртыванию и организации CI/CD. Статья содержит ссылки на технические и научные источники (документация Docker, GitLab, публикации на Хабре) и выдержана в научном стиле.

ABSTRACT

This article discusses the principles of automating development and deployment processes in a microservices architecture, illustrated by the case of IT company NooSoft LLC. The problems of managing multiple independent services and the goals of CI/CD automation are formulated. NooSoft’s experience is analyzed: the technology stack used (Docker, Docker Compose, GitLab CI/CD, Nginx, Apache2, Python, Node.js, PHP) is described, as well as the current CI/CD and deployment workflows on both cloud hosting and on-premise server (Debian 12 with FastPanel2 and Portainer). Examples of typical configurations ( .gitlab-ci.yml , docker-compose.yml , Dockerfile ) are provided. Simplified architecture diagrams of the current (AS-IS) and target (TO-BE) CI/CD systems are shown using mermaid syntax. The article outlines the main challenges in managing microservices (network connectivity, version compatibility, centralized logging, rollbacks). Recommendations for improvement are given: adoption of service meshes to manage inter-service communication, centralized monitoring, and deployment strategies (Blue-Green, Canary) to reduce risks. Comparison tables of different approaches to deployment and CI/CD are included. The article includes references to technical sources (Docker and GitLab documentation, articles on Habr) and is written in a scientific style.

Ключевые слова: микросервисная архитектура, CI/CD, Docker, GitLab, развёртывание, сервис меш, мониторинг, Blue-Green, Canary.

Keywords: microservices architecture, CI/CD, Docker, GitLab, deployment, service mesh, monitoring, Blue-Green, Canary.

Введение

Микросервисная архитектура разбивает приложение на набор мелких, слабо связанных сервисов, каждый из которых можно разворачивать и масштабировать независимо. Это обеспечивает гибкость и ускоряет цикл разработки: команды могут чаще выпускать новые версии функциональности без переписывания большого монолита. Однако по мере роста числа сервисов задача их интеграции и развёртывания становится нетривиальной. Для автоматизации этих процессов применяют практики непрерывной интеграции и доставки (CI/ CD). В такой системе для каждого микросервиса настраивают пайплайн, который автоматически собирает код, создаёт контейнерные образы, выполняет тесты и разворачивает сервис в целевую среду. Целью автоматизации является повышение скорости и надёжности доставки изменений, минимизация простоев при развертывании и возможность быстрого отката некорректных релизов. Как отмечает GitLab, автоматизированное тестирование и развёртывание позволяют вовремя остановить или откатить обновление при выявлении проблем. Таким образом, грамотная организация CI/CD становится ключевым фактором успеха в микросервисной среде.

Опыт компании ООО «Ноософт»

В компании ООО «НооСофт» реализована микросервисная архитектура с использованием технологий Docker и Docker Compose для контейнеризации сервисов. Хранилищем исходного кода является GitLab, а для автоматизации сборки и развёртывания используется GitLab CI/CD. При этом сервисы «НооСофт» написаны на различных языках (Python, Node.js, PHP), что отражает гетерогенность технологического стека. Для обеспечения веб-доступа задействованы серверы Nginx и Apache2, которые выступают в роли API-шлюзов и балансировщиков нагрузки. Микросервисы разворачиваются как на облачных платформах (используя Docker Compose для управления наборами контейнеров), так и на собственном выделенном сервере под управлением Debian 12. На этом сервере установлены FastPanel2 (панель управления сервером) и Portainer (UI для управления Docker-контейнерами).

GitLab CI/CD настроен таким образом, чтобы на каждом изменении в репозитории автоматически запускался конвейер сборки. В пайплайне определены этапы: build – сборка Docker-образа приложения, test – выполнение тестов внутри контейнера, deploy – развёртывание образа на сервере. Пример упрощённой конфигурации .gitlab-ci.yml может выглядеть так:

Рисунок 1. Пример файла конфигурации .gitlab-ci.yml

После сборки и тестирования CI/CD конвейера образы публикуются в контейнерный реестр. Согласно документации GitLab, такой подход позволяет «создать Docker-образ приложения, протестировать его и отправить в реестр» . После этого этап deploy автоматически подтягивает свежий образ и запускает контейнер на нужной среде (например, с помощью 4 docker-compose или через Portainer). Ниже приведён пример типового описывающего запуск нескольких сервисов (включая базу данных):

Рисунок 2. Пример файла конфигурации docker-compose.yml

Каждый микросервис сопровождается своим docker-compose.yml, Dockerfile для сборки образа. Пример простого Dockerfile для Python-сервиса:

Рисунок 3. Пример простого Dockerfile для Python-сервиса

Таким образом, «НооСофт» использует типовой стек DevOps-технологий: GitLab CI/CD с Docker (согласно GitLab CI возможно «включать Docker-команды в задачи и создавать Docker образы»), а развертывание сервисов выполняется с помощью Docker Compose и управляющих панелей.

Архитектура CI/CD: AS-IS и TO-BE

Ниже представлены упрощённые схемы текущей (AS-IS) и перспективной (TO-BE) архитектуры процессов CI/CD в компании.

Текущая архитектура CI/CD (AS-IS) включает GitLab, который при фиксации кода запускает конвейер сборки и тестирования, а затем публикует образы в реестр. Из реестра обновлённые образы развёртываются на облачных серверах и на on-premise сервере Debian (с помощью Docker Compose). В случае on-premise часть контейнеров управляется через FastPanel2/Portainer, Nginx/Apache2 обеспечивают доступ (см. рисунок 4).

Рисунок 4. Flowchart архитектура по модели AS-IS

Перспективная (TO-BE) архитектура предполагает улучшения в сфере надёжности и наблюдаемости. После CI-пайплайна образы доставляются в две среды: «Blue» (продакшн) и «Canary» (стейджинг). Между службами вводится сервис-меш (например, Istio) для прозрачного управления коммуникацией, а с помощью системы мониторинга (Prometheus/Grafana, EFK и т.д.) собираются метрики и логи. Blue-окружение и Canary-канал находятся под контролем единого сервис-меша, что обеспечивает маршрутизацию и быстрый откат.

Рисунок 5. Flowchart архитектура по модели TO-BE

В перспективной модели обе версии контролируются сервис-мешем и выводят метрики в единую систему наблюдения. Это упрощает обнаружение проблем и повышает отказоустойчивость (например, при проблемах в «Green»-канале трафик остаётся на «Blue»).

Сложности управления микросервисами

Управление большим числом микросервисов сопровождается рядом трудностей:

• Сетевая связность и надёжность: микросервисы обычно обмениваются данными по сети (например, через HTTP/gRPC). Синхронные вызовы оказываются уязвимыми к отказам отдельных сервисов: если один сервис перестаёт отвечать, цепочка вызовов может быть заблокирована 5 5 . Кроме того, каждый сетевой запрос добавляет задержки, а взаимодействия в геораспределённых средах подвержены высокой латентности и потере пакетов
• Совместимость версий: при независимом обновлении сервисов может возникнуть разрыв совместимости API или библиотек. Так, изменение контрактов API в одном сервисе может сломать клиентские приложения, если они не синхронизированы. Чтобы избежать конфликтов, GitLab рекомендует применять контрактное тестирование (consumer-driven contract tests) для проверки совместимости версий взаимозависимых сервисов [6].
• Логирование и трассировка: в распределённой системе важно собирать логи и метрики всех сервисов централизованно. Как отмечает Бунин, система логирования эволюционирует от простого вывода в консоль и файлы до полноценных распределённых хранилищ логов [7]. Без надлежащего централизованного логирования и трассировки сложно определить, какой сервис и на каком этапе вызова создал ошибку.
• Откат и отклонение версий: при выпуске новых версий сервисов необходимо предусматривать быстрый откат на предыдущие стабильные релизы. Например, как отмечает GitLab, автоматизированное тестирование позволяет «остановить или откатить» развёртывание при обнаружении проблем [3]. Без CI/CD и специальных стратегий деплоя (см. «Рекомендации…») ручной откат может быть трудоёмким и рискованным, особенно при большой нагрузке или частых релизах.

Каждая из этих проблем требует комплексного решения: от архитектурных паттернов до инструментов мониторинга.

Рекомандации по улучшению процессов

Для повышения надёжности и управляемости микросервисной системы рекомендуется следующие подходы:

• Сервис-меш (Service Mesh): внедрение сервис-меша (например, Istio или Linkerd) позволяет абстрагировать сетевую логику из кода приложений. Service Mesh создаёт инфраструктурный слой для управления коммуникацией между сервисами, добавляя функции наблюдаемости, маршрутизации, балансировки и безопасности «напрозрачно»[8]. Как поясняют специалисты, сервис-меш позволяет внедрять TLS шифрование (mTLS), автоматическую балансировку и отслеживание ошибок без изменения кода микросервисов [7; 8]. Это существенно упрощает защиту каналов связи и мониторинг отказов.
• Централизованный мониторинг и логирование: необходимо настроить сбор ключевых метрик (CPU, память, время ответа API, частота ошибок и т.д.) для каждого сервиса [8]. Без такого мониторинга трудно своевременно обнаружить проблемы – как отмечает GitLab, при перегрузке одного узла «другие сервисы могут не отвечать, поскольку пытаются обратиться к перегруженному» [8]. Рекомендуется использовать стек Prometheus/Grafana для метрик и EFK/ELK для логов, а также распределённый трейсинг (например, Jaeger) для отслеживания путей запросов между сервисами. Централизованные дашборды позволят реагировать на аномалии и предотвращать простои.
• Стратегии деплоя (Blue-Green, Canary): вместо простого перезапуска сервисов рекомендуется использовать плавные стратегии развёртывания. Blue-Green деплоймент предполагает наличие двух идентичных сред – активной («Blue») и подготовленной («Green») 13. При обновлении новая версия разворачивается в «Green», а после тестирования трафик переключается мгновенно, что минимизирует простои и позволяет быстро вернуть «Blue» в случае неудачи [4]. Canary-деплоймент развертывает новую версию на небольшой доле трафика и группе пользователей, постепенно увеличивая нагрузку [6]. Этот подход снижает риск «масштабных ошибок»: проблемы обнаруживаются на ограниченном наборе запросов [6]. Оба подхода требуют тщательного мониторинга и автоматизации, но существенно повышают устойчивость релизов.
• Организация CI/CD: стоит пересмотреть архитектуру конвейеров. Например, можно использовать шаблоны и include в .gitlab-ci.yml для переиспользования общих настроек между сервисами, а сами задания разделять по файлам в зависимости от сервиса (как показано в примерах компаний на Хабре[8]). Такой подход упрощает поддержку гетерогенного окружения: общий функционал (сборка, логин в реестр и т.д.) выносят в шаблоны, а специфичные команды включают в конфигурации конкретных сервисов.

Таким образом, комбинирование сервис-меша, продвинутых стратегий деплоя и надёжного мониторинга создаёт прочный фундамент для управления большим числом микросервисов.

Таблицы сравнения подходов

Ниже приведены таблицы с сравнением популярных подходов к развёртыванию и организации CI/CD.

Таблица 1.

Сравнение стратегий развёртывания

Таблица 2.

Сравнение подходов организации CI/CD

Заключение

Автоматизация развёртывания микросервисов требует комплексного подхода: правильной организации CI/CD, продвинутых стратегий развертывания и инструментов для управления сетью и мониторинга. Опыт ООО «НооСофт» показывает, что использование Docker, GitLab CI/CD и Docker Compose позволяет оперативно доставлять обновления в облако и на собственные сервера. В будущем рекомендовано усилить наблюдаемость (service mesh, метрики, централизованное логирование) и внедрить стратегии Blue-Green/Canary для повышения надёжности релизов. Внедрение этих решений позволит минимизировать простои, быстрее откатывать неудачные изменения и обеспечит масштабируемость процессов DevOps при увеличении числа микросервисов.

Список литературы:

1. Взаимодействие микросервисов между собой. Адамец Д. [Электронный ресурс] Режим доступа: https://habr.com/ru/articles/844100/ (дата обращения: 29.05.2025).
2. Микросервисная архитектура. Atlassian Inc. [Электронный ресурс] Режим доступа: https://www.atlassian.com/ru/microservices/microservices-architecture (дата обращения: 29.05.2025).
3. Настройка CI/CD для GitLab-репозитория: работа с микросервисами [Электронный ресурс]. Режим доступа: https://habr.com/ru/articles/850842/ (дата обращения: 29.05.2025).
4. Распределённое логирование и трассировка для микросервисов. Бунин О.В. [Электронный ресурс] Режим доступа: https://habr.com/ru/companies/oleg-bunin/articles/473946/ (дата обращения: 29.05.2025).
5. Blue-Green и Canary деплойменты в микросервисах. Иванов И. [Электронный ресурс] Режим доступа: https://habr.com/ru/companies/otus/articles/754422/ (дата обращения: 29.05.2025).
6. Get started with microservices architecture. GitLab Inc. [Электронный ресурс] Режим доступа: https://about.gitlab.com/blog/2022/09/20/get-started-with-microservices-architecture/ (дата обращения: 29.05.2025).
7. Istio Service Mesh: как упростить управление микросервисами. Соколова А. [Электронный ресурс] Режим доступа: https://habr.com/ru/companies/slurm/articles/717274/ (дата обращения: 29.05.2025).
8. Use Docker to build Docker. GitLab Inc.  [Электронный ресурс] Режим доступа: https://docs.gitlab.com/ci/docker/using_docker_build/ (дата обращения: 29.05.2025).