---
title: Как работают публикация и флот сайтов
description: Три независимо деплоящихся слоя — платформа, хаб публикации и флот статических Hugo-сайтов — и дисциплина идентичности, держащая опубликованные URL стабильными.
locale: ru
version: 0.2.0
canonical: https://enterium-developer-docs.pages.dev/developers/ru/how-it-works/publishing-and-the-fleet/
---

> Documentation index: https://enterium-developer-docs.pages.dev/developers/llms.txt — every page of this portal has a Markdown twin at <route>.md; the frozen API contract is at https://enterium-developer-docs.pages.dev/developers/api/openapi.json.

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

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

```mermaid
flowchart TB
    P[Platform<br/>generates + gates articles] -- publish payload --> HUB[Publishing hub<br/>separate microservice:<br/>instance registry · renderers · builders]
    HUB -- render to Hugo content --> T[Per-brand site templates<br/>shared theme + brand overrides]
    T -- build + deploy --> FLEET[Fleet of static sites<br/>served by nginx]
    FLEET -- verified live URL --> P
```

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

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

```mermaid
sequenceDiagram
    participant P as Platform
    participant H as Hub API
    participant A as Hugo adapter
    participant B as Builder
    participant S as Site host
    P->>H: publish-live (article payload)
    H->>A: upsert by source_url<br/>(article registry — republish ≠ duplicate)
    A->>B: build site (hugo --minify)
    B->>S: deploy (rsync to web root)
    P->>S: fetch the live URL
    S-->>P: 200 → publication counts
```

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

- **Апсерт по 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` перечисляет флот, который
обслуживает хаб.