Перейти к основному содержимому

ADR: Выбор платформы развертывания инфраструктуры

  • Status: Accepted by Andrei Ganiushkin andrey@ganyushkin.ru
  • Date: 2026-07-25
  • Authors: Andrei Ganiushkin andrey@ganyushkin.ru
  • Related issues: -

Context​

Проекту Netgap требуется определить целевую инфраструктурную платформу для двух контуров:

  • среда разработки: хранение исходного кода, управление задачами и merge request, CI/CD, доступы разработчиков, артефакты сборки и внутренние релизы;
  • боевые ресурсы проекта: публикация сайта документации, размещение релизов, статических артефактов, публичных материалов и вспомогательных сервисов проекта.

Решение должно учитывать не только прямую стоимость сервисов, но и стоимость времени команды на администрирование, обновления, резервное копирование, мониторинг, реагирование на инциденты и поддержание приемлемого уровня защищенности.

Для проекта важны следующие факторы:

  • предсказуемая стоимость владения на ранних стадиях проекта;
  • быстрый запуск без длительного построения собственной инфраструктурной команды;
  • достаточный уровень защищенности, сетевой изоляции, управления доступами и журналирования;
  • возможность хранить и публиковать документацию как статический сайт;
  • возможность размещать релизы, артефакты, контейнерные образы и другие ресурсы проекта;
  • перспектива последующего перехода на собственную инфраструктуру без критического переписывания процессов;
  • контролируемый vendor lock-in.

Decision​

В качестве основной платформы для инфраструктуры проекта выбрать Yandex Cloud.

Для среды разработки использовать управляемый GitLab в Yandex Cloud как основной сервис для:

  • хранения исходного кода;
  • управления задачами, merge request и code review;
  • запуска CI/CD;
  • подключения GitLab runners, которые могут размещаться как в Yandex Compute Cloud, так и в защищенной зоне на собственном железе;
  • хранения внутренних артефактов сборки и релизных материалов, если это поддерживается выбранной конфигурацией;
  • централизованного управления доступами команды.

Для боевых ресурсов проекта использовать статический хостинг сайта документации на базе сервисов Yandex Cloud. Документационный сайт должен публиковаться как статический ресурс, без обязательного постоянного приложения-сервера.

Для размещения релизов и дополнительных публичных или внутренних ресурсов проекта допускается использовать другие сервисы Yandex Cloud по мере необходимости, включая объектное хранилище, CDN, registry для контейнерных образов, управление сертификатами, DNS, мониторинг, аудит и журналирование.

Выбранная модель фиксируется как облачная managed-first стратегия: на раннем и среднем этапах проекта управляемые сервисы имеют приоритет над самостоятельным администрированием аналогичной инфраструктуры, если они обеспечивают приемлемую стоимость, функциональность, защищенность и переносимость данных.

Considered Alternatives​

Alternative 1: Yandex Cloud с Managed GitLab и статическим хостингом документации​

Инфраструктура разработки и публикации размещается преимущественно в Yandex Cloud. Для разработки используется Managed GitLab, для сайта документации — статический хостинг, для релизов и артефактов — подходящие управляемые сервисы Yandex Cloud.

  • Pros:
    • Лучший баланс между прямой стоимостью, временем команды на администрирование, уровнем защищенности и получаемой функциональностью.
    • Managed GitLab закрывает ключевые потребности разработки: репозитории, merge request, code review, CI/CD, управление доступами и артефактами.
    • GitLab runners можно размещать как в Yandex Compute Cloud, так и в защищенной зоне на собственном железе, сохраняя гибкость для чувствительных сборок и будущей гибридной модели.
    • Статический хостинг документации дешевле и проще в эксплуатации, чем постоянный сервер приложения.
    • Неиспользуемые вычислительные и вспомогательные ресурсы можно отключать, что существенно снижает затраты на ранних стадиях и при нерегулярной нагрузке. На начальном этапе, когда разработчик один, активная работа в основном приходится на выходные, поэтому оплата только фактически используемых ресурсов дает существенную экономию.
    • Управляемые сервисы снижают нагрузку на команду: обновления, отказоустойчивость, базовый мониторинг, резервирование и часть задач безопасности выполняются на стороне провайдера.
    • Инфраструктура может развиваться постепенно: от статического сайта и GitLab к registry, объектному хранилищу, CDN, мониторингу и другим сервисам.
    • Для российского рынка упрощается работа с локальным облачным провайдером, оплатой, доступностью сервисов и юридическими требованиями.
  • Cons:
    • Возникает зависимость от доступности, тарифов, API и продуктовой политики Yandex Cloud.
    • Часть сервисов и настроек будет специфична для провайдера.
    • При росте нагрузки потребуется регулярный контроль стоимости и лимитов.
  • Reason for selection: вариант обеспечивает лучший баланс стоимость — ресурсы команды — защищенность — функциональность. Он позволяет быстро развернуть среду разработки и боевые ресурсы без значительных затрат на собственное администрирование, сохраняя возможность последующей миграции на собственную инфраструктуру.

Alternative 2: Платформы разработки типа SourceCraft.dev или GitVerse​

Исходный код, задачи, code review, CI/CD и часть артефактов размещаются на специализированной платформе разработки, например SourceCraft.dev или GitVerse. Боевые ресурсы проекта при этом размещаются отдельно либо средствами самой платформы, если они доступны.

  • Pros:
    • Быстрый старт без самостоятельной установки и сопровождения Git-сервера.
    • Низкая административная нагрузка на команду разработки.
    • Готовые функции для репозиториев, code review, задач и совместной работы.
    • Потенциально удобная экосистема для открытой разработки и внешних участников.
  • Cons:
    • Меньше контроля над инфраструктурой разработки, сетевой моделью, хранением артефактов, политиками доступа и интеграцией с боевыми ресурсами.
    • Боевые ресурсы проекта, сайт документации, релизные файлы, container registry, CDN, DNS, мониторинг и аудит все равно могут потребовать отдельной инфраструктурной платформы.
    • Функциональность CI/CD, артефактов, секретов, аудит-логов и enterprise-настроек может отличаться от привычной модели GitLab и быть недостаточной для требований проекта.
    • Vendor lock-in переносится на платформу разработки, при этом не решается полный набор задач боевой инфраструктуры.
  • Reason for rejection: главный риск — vendor lock-in в платформу разработки и отсутствие бесшовного пути перехода на собственную инфраструктуру в будущем. Эти платформы удобны как сервисы разработки, но хуже закрывают совокупную задачу проекта: единая инфраструктура для разработки, статического сайта документации, релизов, артефактов, безопасности, мониторинга и последующего масштабирования.

Alternative 3: Собственная инфраструктура​

Команда самостоятельно разворачивает и сопровождает GitLab, Gitea или Forgejo, CI/CD runners, объектное хранилище, registry, веб-сервер для статического сайта, backup, monitoring, logging, IAM-подобные процессы и сетевую защиту на собственных серверах или арендованных VM.

  • Pros:
    • Максимальный контроль над конфигурацией, сетевой моделью, обновлениями, хранением данных и политиками безопасности.
    • Ниже зависимость от конкретного облачного провайдера или платформы разработки.
    • Потенциально ниже прямые инфраструктурные расходы при большой стабильной нагрузке и зрелой эксплуатации.
    • Проще реализовать нестандартные требования, если они не поддерживаются managed-сервисами.
  • Cons:
    • Высокая стоимость владения из-за времени команды на установку, обновления, резервное копирование, мониторинг, hardening, управление инцидентами и восстановление после сбоев.
    • Требуется отдельная эксплуатационная компетенция для GitLab, CI/CD, registry, object storage, веб-публикации, сетевой безопасности и observability.
    • Риск получить более низкий фактический уровень защищенности, если администрирование выполняется нерегулярно или без выделенной команды.
    • Медленнее запуск проекта и выше риск технического долга в инфраструктуре.
    • Для ранней стадии проекта ресурсы на поддержку собственной платформы конкурируют с разработкой продукта.
  • Reason for rejection: собственная инфраструктура дает максимальный контроль, но на текущем этапе проигрывает по совокупной стоимости владения, скорости запуска и соотношению администрирования к получаемой функциональности.

Consequences​

Positive​

  • Проект получает единую управляемую инфраструктурную базу для разработки и публикации ресурсов.
  • Команда быстрее запускает Git-репозитории, code review, CI/CD и публикацию документации.
  • GitLab runners можно размещать ближе к требованиям конкретного контура: в облаке для типовых задач или в защищенной зоне на собственном железе для чувствительных сборок.
  • Статический хостинг документации снижает операционную сложность, стоимость и поверхность атаки по сравнению с постоянно работающим серверным приложением.
  • Возможность отключать неиспользуемые ресурсы снижает прямые расходы при нерегулярной нагрузке и помогает управлять бюджетом проекта.
  • Управляемые сервисы уменьшают объем ручного администрирования и повышают базовый уровень эксплуатационной надежности.
  • Инфраструктура может расширяться постепенно: релизы, артефакты, container registry, CDN, DNS, сертификаты, мониторинг и аудит добавляются по мере потребности.
  • Решение совместимо с будущим переходом на собственную инфраструктуру, если нагрузка, требования безопасности или экономика проекта изменятся.

Negative​

  • Проект становится зависимым от Yandex Cloud как от основного инфраструктурного провайдера.
  • Тарифы, лимиты и доступность managed-сервисов должны регулярно контролироваться.
  • Часть инфраструктурных описаний, API и настроек может быть провайдер-специфичной.
  • При миграции на собственную инфраструктуру потребуется заранее спланировать перенос CI/CD, артефактов, секретов, DNS, статического сайта и прав доступа.

Risks and Mitigations​

  • Risk: vendor lock-in в сервисы Yandex Cloud усложнит переход на собственную инфраструктуру или другого провайдера.
    • Mitigation: использовать переносимые сущности: Git-репозитории, стандартные container images, статическую сборку сайта, S3-совместимые подходы к объектному хранилищу, декларативное описание инфраструктуры и CI/CD, не завязанное на уникальные возможности провайдера без необходимости.
  • Risk: рост стоимости облачных сервисов станет незаметным до момента существенного увеличения счета.
    • Mitigation: настроить бюджеты, лимиты, регулярный cost review и разделение ресурсов по окружениям и проектам.
  • Risk: недоступность провайдера повлияет одновременно на разработку и публичные ресурсы проекта.
    • Mitigation: хранить локальные и внешние резервные копии критичных репозиториев и релизных артефактов, документировать процедуру восстановления и предусмотреть возможность публикации статического сайта из независимого хранилища.
  • Risk: команда начнет использовать провайдер-специфичные возможности без оценки переносимости.
    • Mitigation: для каждого нового managed-сервиса фиксировать причину выбора, данные для экспорта и минимальный сценарий миграции на self-hosted или альтернативную платформу.
  • Risk: собственная инфраструктура может стать экономически или организационно выгоднее при росте проекта.
    • Mitigation: периодически пересматривать решение по фактической стоимости, нагрузке, требованиям безопасности и доступности компетенций эксплуатации.