Поддержка хранилищ

Использование таргетов в delivery-контуре DC CMS

Определения

Таргет (target) — конфигурация деплоя в Deployer для пары «сайт + окружение» (siteName, env: например preview, authoring, live, serverless-delivery). Таргет задаёт источник контента (путь к Git-репозиторию или URL remote), цепочку процессоров (pipeline) и параметры интеграций (Elasticsearch, Engine, S3). Studio создаёт и обновляет таргеты при создании сайта и по событиям (сохранение контента, публикация); запуск деплоя — HTTP-вызов POST /api/1/target/deploy/{env}/{siteName}.

Контур authoring — среда создания и подготовки контента. Включает DC CMS Studio (UI, REST API, Content/Workflow Service), Git Sandbox (черновики и конфигурация сайта), Authoring Deployer (таргеты preview / authoring: diff, индексация для авторов, предпросмотр) и Preview Engine. Авторы работают с неопубликованным срезом; публикация переносит утверждённые изменения в Git Published.

Контур delivery — среда доставки опубликованного контента конечным потребителям (сайт, API, поиск). Источник — Git Published (ветка live). Delivery Deployer (таргет live и при необходимости serverless-delivery) забирает published, индексирует delivery-поиск и доводит артефакты до runtime: локальные каталоги + Engine или S3 (serverless). Studio инициирует деплой delivery после публикации (DeliveryDeployer, delivery.deployer.url).

Процесс

В контуре delivery Deployer забирает опубликованный срез из Git Published (ветка live) и доводит его до среды потребления. Studio после публикации вызывает DeliveryDeployer (delivery.deployer.url, env live); при включённом serverless дополнительно создаётся отдельный таргет (studio.serverless.delivery.enabled, шаблоны aws-s3).

Классический delivery (локальные папки, без S3)

Шаблон: remote-target-template (и близкие «remote»-варианты).

Поток: gitPullProcessor → локальный клон published → gitDiffProcessor → elasticsearchIndexingProcessor → httpMethodCallProcessor (rebuild context / clear cache / GraphQL) → fileOutputProcessor.

Размещение контента: рабочая копия на диске Deployer; Preview/Delivery Engine читает сайт с локального content store (file:…/work-area или смонтированный каталог).

Плюсы:

1.    Простая топология: Git + FS + Engine, без облачных зависимостей.
2.    Предсказуемая отладка: файлы и логи на хосте.
3.    Полный контроль над версиями, бэкапами и сетевой политикой.
4.    Engine сразу видит изменения конфигурации через HTTP rebuild.

Минусы:

1.    Масштабирование только «горизонтально» своими серверами (N инстансов Engine + общий или синхронизированный диск, либо pull на каждый узел).
2.    Нужны общие тома или репликация FS при кластере delivery.
3.    Больше ручной работы по HA, CDN и геораспределению.
4.    Зависимость от доступности Engine и Elasticsearch на той же инфраструктуре.

Использование имеет значение для следующих условий: on-prem, dev/stage, небольшие и средние инсталляции, требование «данные не покидают периметр».

Serverless delivery (S3 как хранилище артефактов)

Шаблоны: aws-s3.

Реализация: gitPullProcessor → gitDiffProcessor → elasticsearchIndexingProcessor → s3SyncProcessor → опционально CloudFront invalidation → события деплоя в S3 → fileOutputProcessor. Локальный клон published обычно в ${CMS_DATA_DIR}/repos/aws/{siteName} — промежуточный этап перед sync.

Размещение контента: опубликованные файлы и статика — в S3; runtime читает из bucket, а не с диска сервера приложения.

Плюсы:

1.    Горизонтальное масштабирование и отказоустойчивость за счёт S3 и CDN.
2.    Удобно для «тонкого» delivery без постоянного Engine на VM.
3.    Естественная связка с CDN (CloudFront) для static-assets.
4.    Меньше операций с общими дисками в кластере.

Минусы:

1.    Сложнее стек: IAM, bucket policy, endpoint, CloudFormation (для cloudformed-шаблона).
2.    Дополнительная задержка и стоимость S3 API / egress.
3.    Два слоя по смыслу: Git Published (SoT) и S3 (проекция для runtime) — нужен мониторинг рассинхрона.
4.    Зависимость от облака и credentials; отладка «что в bucket» сложнее, чем просмотр файлов на сервере.

Использование имеет значение для следующих условий:: production в AWS (или S3-совместимое хранилище), headless/API-first, высокая нагрузка на статику, serverless-рендер.

Сравнение

Локальные папки: runtime — Engine на ФС; ключевой шаг — HTTP rebuild Engine; SoT — Git Published; эксплуатация проще; масштаб и CDN — вручную.

Serverless + S3: runtime — Engine/Lambda + S3; ключевой шаг — s3SyncProcessor; SoT — Git Published, S3 — доставка; эксплуатация сложнее; масштаб и CDN — из коробки в облаке.

Оба варианта используют один Git Published при публикации из authoring; различается только конечное хранилище и способ доставки до пользователей и поисковых индексов delivery.