Как работают публикация и флот сайтов

Проблема: одна платформа публикует на много сайтов, у каждого свой бренд, домен и тема. Свяжи контент-движок с рендерингом сайтов — и каждая правка темы становится деплоем платформы, а каждый баг платформы — падением флота. Ответ дизайна — три слоя, деплоящиеся независимо.

Слой 1 — трёхслойная топология

Хаб — вендорнутый микросервис с собственным реестром инстансов: записи на сайт несут шаблон, статус, деплой-таргет и публичный URL. Реестр — не база платформы — источник правды хаба о том, где живёт каждый бренд. Платформа отдаёт хабу готовую статью; всё от «markdown-файла в нужной папке» до «сайт пересобран и разъехался rsync-ом» — забота хаба.

Слой 2 — поток публикации от края до края

Надёжность несут две детали:

• Апсерт по URL источника. Хаб ведёт собственный реестр статей, ключованный по source URL, — поэтому републикация улучшенной версии заменяет страницу, а не чеканит дубликат.
• Идентичность слага живёт на стороне платформы. Реестр опубликованных URL ключует идентичность как (инстанс, нормализованный URL источника) — намеренно не внутренний id статьи, который меняется при регенерации. Регенерированная статья переиспользует свой замороженный слаг; совершенно новый источник чеканит новый. Именно это защищает накопленный SEO-капитал от перетасовки рутинной регенерацией.

Слой 3 — конфигурация бренда это код, не состояние сервера

Брендинг (тайтл, лого, цвета, таксономии, ростер авторов) живёт в git-шаблонах по бренду поверх общей темы. Ручная правка на веб-хосте живёт лишь до следующей сборки — по дизайну: шаблон — единственный источник правды, и каждый деплой его переутверждает. Новые сайты стартуют staged port-инстансами (доступны, без домена) и конвертируются в прод-домены короткой обратимой процедурой (DNS → vhost → URL в реестре → запись платформы).

Слой 4 — деплой самих слоёв

Каждый слой едет своим ритмом, со своими инвариантами:

• Платформа — четырёхфазный деплой-скрипт: preflight (отказывается при активных прогонах; снапшотит поверхность секретов), подмена кода с таймстампованным бэкапом, пересборка контейнера, postflight (health-ожидание + пере-хэш поверхности секретов — неожиданный дифф абортит). Миграции БД применяются автоматически на старте контейнера.
• Хаб — пересобирается из своего репо; правка шаблона редеплоится по инстансу, не трогая платформу.
• Эта документация — собирается статически, едет неизменяемой релизной директорией с переключением симлинка; откат — переключить симлинк обратно.

Трейд-оффы, честно

Три слоя — это три реестра правды (БД платформы, реестр инстансов хаба, git-шаблоны), и операционная цена — держать их указатели выровненными; рассинхрон реестра уже давал инциденты «instance not found». Правило verified-live-URL также означает, что публикация готова лишь настолько, насколько медленна самая долгая сборка сайта, — очередь на хабе задерживает доказательство, а не только доставку. Обе цены приняты в обмен на брендовые изменения по всему флоту, никогда не требующие трогать контент-движок.

Пощупать за две минуты

Любая строка опубликованной статьи несёт свой живой URL; сходи по нему — ответивший URL и есть собственное определение платформой слова «опубликовано». API-домен instances перечисляет флот, который обслуживает хаб.

Спеки: SPEC-073 (идентичность опубликованных URL), SPEC-096 (укрепление publish-пути), SPEC-097 (publish-стек), плюс вендорнутый сервис хаба.