Обзор Pages

Pages публикует статические сайты как проекты с неизменяемыми Deployments и перемещаемыми Tags. Deployment — фиксированный артефакт, созданный ручной загрузкой или сборкой Git. Tag — именованный указатель на один Deployment. Routes указывают на Tags, а не напрямую на Deployments, поэтому продвижение и откат становятся намеренными эксплуатационными действиями, а не изменениями уже опубликованного артефакта.

Для руководителя продукта или разработки результатом является управляемый путь релиза для документации, лендингов, Dashboard и других статических клиентских приложений без отдельного сервера приложений. Владелец проекта определяет, что собирается; владелец релиза решает, какой неизменяемый артефакт выбирает Tag; владелец Ingress управляет Domain и TLS Route. Успех означает, что релиз можно предварительно проверить, продвинуть, подтвердить и откатить без пересборки или изменения предыдущего артефакта.

Pages подходит для статического результата, который доставляется в браузер. Это не универсальная серверная среда выполнения: процессы API, фоновые обработчики, сеансы с состоянием и серверный код приложений должны работать как нагрузки за Gateway Routes.

Этот портал документации и продуктовый лендинг Good Gateway сами публикуются через Gateway Pages. Они используют ту же модель неизменяемых Deployments, Tags, Routes, TLS и отката, которая описана на этой странице.

Модель ресурсов и владение

Pages Project владеет историей Deployments, Tags, Routes, конфигурацией среды выполнения, отношениями доступа и политикой хранения. Gateway централизованно хранит каждый опубликованный артефакт и материализует его на назначенных нодах nginx. Nginx обслуживает применённую конфигурацию Pages, а Gateway остаётся источником истины для выбора Tag, который должен использовать Route.

Deployments неизменяемы: изменение файлов сайта, результата сборки или входных данных источника создаёт новый Deployment. Tags перемещаемы: перенос Tag меняет уже созданный Deployment, на который он указывает. Системный Tag latest отслеживает подходящий текущий Deployment; используйте пользовательские Tags для именованных сред, каналов релизов или явного барьера продвижения.

Решения до первого релиза

До подключения публичного Domain согласуйте пять пунктов:

Владение: кто может создавать Deployments, перемещать Tags рабочей среды, менять конфигурацию среды выполнения и удалять цели отката.
Источник релиза: ручная загрузка артефакта или одобренная интеграция Git и Build Worker.
Политика продвижения: автоматическое развёртывание для низкорискового сайта или явная проверка до перемещения Tag рабочей среды.
Хранение: сколько заведомо исправных Deployments нужно сохранять и как долго.
Контракт среды выполнения: какие публичные значения могут меняться независимо от артефакта, а какие требуют новой сборки.

Используйте отдельные Tags, если средам нужно независимое продвижение. Не используйте имена Tags как контроль доступа: границей безопасности остаются права и Routes.

Публикация из Git или вручную

Для релиза из Git поддерживаемая интеграция источника и Build Worker создают новый неизменяемый Deployment. Для ручного релиза передайте готовый артефакт статического сайта и создайте из него новый Deployment. В обоих случаях проверьте артефакт и идентичность Deployment до перемещения публичного Tag.

Создание Deployment не публикует его на пользовательском Domain. Публикация начинается, когда Route указывает на Tag, выбирающий этот Deployment. Так команда может проверить релиз до продвижения, а при инциденте — откатить Tag без изменения предыдущего артефакта.

Routes, предварительные версии и конфигурация среды выполнения

Пользовательские Routes указывают только на Tags. До объявления релиза проверьте Domain, TLS-сертификат, размещение nginx и цель Tag. Необязательные предварительные версии с подстановочными доменами используют неизменяемые имена хостов Deployments; они позволяют проверить конкретный артефакт без изменения публичного Tag.

Конфигурация среды выполнения — публичные клиентские данные, отделённые от идентичности неизменяемого артефакта. Сайт получает её как window.runtime.config с объектом Default и полными переопределениями объекта для Tags. Неизменяемые предварительные версии используют Default; Route с Tag использует его переопределение, если оно есть, или возвращается к Default. Не помещайте в конфигурацию секреты, учётные данные или приватную топологию.

Конфигурация подходит для публичных адресов API, представления функций, идентификаторов аналитики или меток среды, которые действительно должны быть видны браузеру. Переопределение Tag заменяет объект целиком, а не объединяет отдельные ключи, поэтому проверяйте все обязательные поля. Сохраняйте совместимость со всеми Deployments, на которые Tag может вернуться при откате.

Продвиньте, откатите и проверьте

Создайте новый неизменяемый Deployment через Git или ручную публикацию.
Проверьте результат сборки или загрузки и протестируйте артефакт через подходящую предварительную версию или контролируемый Route.
Переместите нужный Tag на проверенный Deployment.
Проверьте путь DNS и TLS Route, ожидаемый ответ, статические ресурсы и видимую браузеру конфигурацию среды выполнения.
После продвижения наблюдайте за Route, состоянием приложения nginx и операциями проекта.

Для отката переместите Tag Route на предыдущий заведомо исправный Deployment. Старый артефакт остаётся неизменным, а откат записывается как изменение публикации Tag. Сохраняйте обратную совместимость конфигурации среды выполнения, пока Tag может перемещаться между релизами; изменение конфигурации не создаёт новый Deployment.

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

Последствия жизненного цикла

Удаление Deployment исключает этот неизменяемый релиз из будущего выбора и может убрать цель отката. Удаляйте его только после проверки требований хранения и ссылок Tags. Удаление Tag или Route меняет доступность, а не содержимое выбранного Deployment. Отключение Pages убирает функцию из обычной навигации, сохраняя данные проекта.

Для операторов: размещение и восстановление

Gateway хранит артефакт Pages централизованно и материализует копии на назначенных нодах nginx. Если Route не работает, а Deployment готов, проверьте размещение Domain, ноду Ingress, связь сертификата, цель Tag и Task Pages до пересборки. Повторная сборка того же источника не заменяет восстановление пути обслуживания.

Если продвижение вызвало инцидент, сначала переместите Tag рабочей среды на предыдущий проверенный Deployment. Меняйте конфигурацию среды выполнения только тогда, когда она является частью сбоя и совместима с целью отката. Сохраняйте неисправный Deployment, запись сборки и журналы до выяснения причины: неизменяемость делает их полезными доказательствами.

Симптом	Первая проверка	Безопасное следующее действие
Deployment готов, но сайт не открывается	Domain, TLS, Route, Tag и нода Ingress	Пройдите диагностику Ingress, не пересобирая сайт
Не открывается только новая версия	Положение Tag, предварительную версию и конфигурацию сайта	Верните Tag на проверенный Deployment и сохраните Task и журналы
Сборка или загрузка не завершилась	Task, журналы сборки и Build Worker	Исправьте конкретную ошибку и повторите сценарий; не удаляйте предыдущую версию

Следующий шаг

Соберите и опубликуйте Deployment Pages из Git