Полученные мировыми первопроходцами знания о неизведанных землях и безопасных маршрутах помогают нам, современным людям, достигать своих целей быстрее и эффективнее. Каждый исследователь фиксировал открытия в путевых журналах и дневниках. И лишь благодаря титаническим усилиям ученых-картографов удалось объединить накопленные данные в единую книгу — атлас. В статье Роман Байталов, архитектор системных решений GitFlic (входит в «Группу Астра»), рассказывает о том, что является этим «атласом» в DevOps.
Остров истины в океане технологий
DevOps — процесс постоянного исследования в океане всевозможных решений: систем контроля версий, CI/CD-конвейеров, хранения артефактов, мониторинга, сбора логов… На каждый запрос найдется инструмент, и порой не один, а десяток. Один — фрегат: мощный, но требует экипажа и времени на маневр. Другой — катер: быстрый, но не выдержит шторма.
Очевидно, что есть потребность в консолидации инструментов, причем не только для упрощения, но и ради целостности, скорости и надежности.
При разработке платформы для работы с кодом GitFlic мы воплощаем идею решения все-в-одном, единого инструмента для выстраивания DevOps-процесса в командах, стремящихся оптимизировать и ускорить производство.
С недавнего времени в нашей платформе доступен новый компонент GitFlic Atlas — подсистема хранения и доставки артефактов жизненного цикла разработки и эксплуатации программного обеспечения, призванная стать местом, где каждый пакет, зависимость, контейнер или любой другой двоичный файл «знает» свое происхождение, владельца и историю. Атласом разработки.
GitFlic Atlas: архитектурное решение
Вдохновение и ориентир в части функционала GitFlic Atlas мы почерпнули у популярных продуктов Sonatype Nexus и Jfrog Artifactory и старались сохранить то, к чему уже привыкли их пользователи.
GitFlic Atlas — компонент платформы GitFlic, он тесно интегрирован в иерархию проектов, CI/CD, ролевую модель для обеспечения бесшовной работы с исходным кодом и теми артефактами, что требуются и получаются в процессе разработки продукта. При этом архитектура платформы позволяет развертывать GitFlic Atlas в автономном режиме, если для хранения кода используются другие решения.
Для установки и обновления GitFlic Atlas, как и всей платформы GitFlic, надо запустить один jar-файл, deb-пакет или Docker-контейнер на любой операционной системе, железе, виртуализации и облачной среде контейнеризации.
Поддержка горизонтального масштабирования и хранение загружаемого контента в S3-совместимое хранилище обеспечивают высокую доступность и отказоустойчивость системы хранения данных компании.
В GitFlic Atlas можно хранить пакеты разных форматов: Maven, NPM, PyPi, NuGet, Composer, CRAN, GEM, CARGO, Conda, GO, OPM, Debian, RPM, Container, Helm и Generic. Имеются репозитории трех типов:
- локальный — для загрузки собственных пакетов или артефактов;
- проксирующий — для загрузки пакетов или артефактов из внешних источников с возможностью кеширования и офлайн-работы;
- виртуальный — цепочка из репозиториев GitFlic Atlas любого типа для получения доступа к артефактам через единый URL.
За целостность и консистентность загружаемых данных, одной из главных проблем, с которой сталкиваются разработчики, отвечает промежуточное хранилище. В частности, при работе с Docker-реестром перед тем, как будет обработан манифест, файлы загружаются в него, а после перемещаются в постоянное хранилище. Те файлы, что не были перемещены, через какое-то время удаляются.
Вопрос оптимизации размеров хранилища решают сразу три механизма:
- политики очистки — они определяют область и периодичность очистки хранилища;
- «сборщики мусора», которые согласно политикам удаляют файлы и чистят промежуточное хранилище;
- дедупликация файлов (блобов) реестра контейнеров.
Функции GPG-подписи пакетов локального репозитория и проксирования с кешированием и офлайн-режимом позволяют организовать изолированный контур хранения, служащий единственной однозначной «точкой правды» для безопасной разработки и сборки любого приложения в закрытом контуре.
Функционал на примере
Допустим, у компании-разработчика ПО множество отделов, у них задачи разные, но есть общие технологии. Они уже используют платформу GitFlic для работы с кодом и построения CI/CD-пайплайнов, но артефакты сборки, зависимости и пакеты хранят во внешних системах. Те, кто пишет на Java, — в Nexus, соседняя команда — в Jfrog, TypeScript- и Python-разработчики все зависимости скачивают напрямую из внешнего реестра пакетов, а DevOps-инженерам удобнее держать Docker-образы в Harbor.
Такая фрагментация порождает серьезные операционные и ИБ-риски:
- отсутствие единой точки контроля усложняет аудит, сканирование на уязвимости и управление версиями;
- дублирование зависимостей между системами увеличивает объем хранилищ и замедляет сборки;
- разные политики доступа провоцируют инциденты;
- отсутствие прослеживаемости «код → артефакт → окружение» нарушает принципы SLSA;
- дополнительная нагрузка на инженеров: для каждого нового проекта надо изучить еще один интерфейс, еще одну модель прав, еще один способ деплоя.
Как GitFlic Atlas решит проблему фрагментации? Консолидирует информацию в одном доверенном месте! И сделать это довольно просто. Хранилища артефактов создаются на нескольких уровнях иерархии: системы, компании, проекта. Каждый последующий уровень наследует доступ к данным предыдущего, на каждом из них создаются репозитории нужного типа, например, на проектном — только то, что требуется конкретному проекту:
- локальные репозитории для релизов с возможностью разделения по окружениями (например, dev, test, prod) и гранулярного ограничения доступа к разным типам репозитория;
- проксирующие — с возможностью кеширования и работы без доступа во внешнюю сеть для внешних зависимостей и Docker-образов;
- виртуальные — для группировки множества репозиториев одного типа единым URL.
А зависимости или, например, DevOps-компоненты, которые нужны нескольким проектам, можно получать с верхнего уровня — компании или системы, где организация репозиториев работает аналогично.
В результате команды получают не просто еще один артефакторий, а централизованную систему управления бинарными артефактами, которая снижает риски, упрощает эксплуатацию и обеспечивает сквозную прослеживаемость от коммита до production-образа.
Заключение: единый Atlas вместо сотни островов
Когда инструменты разобщены, разработка идет медленнее, а обеспечить безопасность сложнее, поэтому консолидация — это не роскошь, а необходимость.
GitFlic Atlas предлагает не просто альтернативу Nexus или Artifactory, а целостность: единая точка управления артефактами, встроенная в экосистему разработки, с поддержкой всех популярных форматов, гибкой моделью доступа и отказоустойчивой архитектурой.
Записывайте все. Храните все. Доверяйте одному Atlas’у.