Требования и планирование

Для Gateway лучше выделить отдельный сервер, а приложения и базы данных оставить на управляемых хостах. Gateway станет единым центром управления: в нём хранятся пользователи и права, настройки ресурсов, сертификаты, история операций и аудит. При этом операционная система, диски и резервные копии самих серверов по-прежнему остаются в зоне ответственности вашей команды.

Gateway — привилегированный контур управления

Хост Gateway имеет доступ к зашифрованным инфраструктурным учётным данным и к сокету Docker с правом записи, который нужен для подписанных обновлений, восстановления, обслуживания и локальных управляемых служб. Контроль этого хоста фактически даёт права уровня root на установку Gateway и может затронуть все подключённые ресурсы в пределах её полномочий. Используйте отдельную виртуальную машину или сервер, разместите его в ограниченной управляющей сети и не запускайте там посторонние рабочие нагрузки.

Определите схему развёртывания

Для знакомства с продуктом приложение Gateway и его внутренние службы можно разместить на одном Linux-сервере. В рабочей среде у этого сервера должны быть ответственный владелец, постоянное хранилище, резервное копирование, процедура восстановления и контроль свободного места. Управляемые хосты подключаются после установки Gateway; это могут быть физические серверы, виртуальные машины или изолированные системные контейнеры.

До установки зафиксируйте:

• постоянный HTTPS-адрес, по которому пользователи и управляемые ноды будут открывать Gateway;
• владельцев DNS, сертификатов, аутентификации, резервного копирования и обновлений;
• сети, из которых доступны веб-приложение и Relay;
• роли нод, нужные сразу, и роли, которые можно добавить позднее;
• требуемый тарифный план и права на функции;
• допустимое время восстановления и допустимую потерю данных Gateway, включая ключи шифрования.

Не начинайте с временного IP-адреса или доменного имени, которое планируете заменить после запуска. Основной URL используется в защите браузера, URI перенаправления, командах подключения нод и интеграциях, поэтому его последующая смена затронет сразу несколько частей системы.

Решение по хосту и ёмкости

Подготовьте поддерживаемый Linux-сервер с доступом root или рабочим sudo. Заранее устанавливать Docker не требуется: установщик сам добавит официальный репозиторий Docker, установит Docker Engine и модуль Compose v2 и запустит службу. Автоматическая установка поддерживает Debian, Ubuntu, Fedora, CentOS и RHEL. Если Docker уже установлен, скрипт проверит его и использует существующую установку.

Для центрального сервера Gateway используйте следующие ориентиры:

Профиль	CPU	Память	Свободное место на SSD
Минимальный	2 vCPU	4 GB RAM	32 GB
Рекомендуемый	4 vCPU	8 GB RAM	64 GB

В таблице указано свободное место после установки операционной системы. Если структурированные журналы будут храниться в локальном ClickHouse под управлением Gateway, дополнительно потребуется минимум 32 GB, а для длительного хранения рекомендуется от 128 GB. Точный объём зависит от количества событий и срока хранения. При подключении внешнего ClickHouse эти данные не занимают диск сервера Gateway.

Выделите постоянное хранилище для PostgreSQL Gateway, данных Redis (если их сохранение включено), загружаемых материалов, сертификатов, конфигурации, внутреннего реестра образов и необязательных структурированных журналов. Сборки из Git требуют дополнительного места: Gateway хранит текущие и резервные версии, незавершённые сборки и версии, которые оператор закрепил вручную.

Также как минимум обеспечьте:

• запас процессора и памяти для приложения, PostgreSQL, Redis и Relay без постоянного использования раздела подкачки;
• постоянное хранилище с мониторингом свободного места и проверенным местом назначения резервных копий;
• корректное системное время и надёжное разрешение DNS;
• процедуру обновления ОС, которая не удаляет и не заменяет постоянные тома;
• доступ к текущему подписанному релизу Gateway и службе лицензирования.

Не храните единственную резервную копию или единственную копию ключа шифрования на сервере Gateway. Резервной копии базы данных недостаточно: без соответствующего ключа зашифрованные секреты восстановить нельзя.

Для оператора: сетевой доступ

Публичной установке обычно нужен входящий HTTP/HTTPS для интерфейса и API. Управляемые ноды подключаются через Relay; если они находятся вне локальной сети, адрес Relay должен быть доступен по 9443/tcp. Административный доступ стоит ограничить на сетевой границе. Прокси или межсетевой экран перед Relay допустимы только в том случае, если они поддерживают долгоживущие соединения и не обрывают их по короткому тайм-ауту.

Необходимый исходящий доступ зависит от включённых функций. Обычно Gateway обращается к поставщикам аутентификации, ACME- и DNS-службам, системам контроля версий, реестрам контейнеров, службам обновления и лицензирования, адресам электронной почты и вебхуков, SIEM и настроенным поставщикам AI. Для Build Worker лучше определить отдельные и более строгие правила исходящего доступа.

Перед изменением межсетевого экрана изучите раздел Порты и сеть. Проверяйте соединение именно с того сервера или контейнера, который будет его устанавливать: успешный запрос с ноутбука администратора не доказывает, что тот же адрес доступен Gateway или нодам.

Роли нод и границы доверия

Выбирайте только нужные роли:

• Нода Ingress: маршруты, TLS, Pages, журналы доступа и ошибок и метрики трафика;
• Нода Docker: контейнеры, развёртывания, Compose Project, файлы, журналы и фактическое состояние служб;
• Нода баз данных: управляемые экземпляры PostgreSQL, Redis или ClickHouse и их постоянное хранилище;
• Build Worker: изолированное выполнение BuildKit/containerd без передачи сокета Docker Engine;
• Нода Monitoring: специализированный сбор метрик поддерживаемых систем;
• Relay: дополнительная пропускная способность и отказоустойчивость прямых защищённых соединений Secure Link.

Разделение ролей влияет и на эксплуатацию, и на безопасность. Для ноды баз данных нужны правила хранения и резервного копирования, подходящие для сервисов с постоянными данными. Build Worker выполняет инструкции из репозитория и не должен делить хост с посторонними приложениями или многоразовыми инфраструктурными учётными данными. Основной границей безопасности должна быть отдельная виртуальная машина или непривилегированный системный контейнер; внутренняя изоляция сборки служит дополнительной защитой.

Нода Docker обычно управляет локальным Docker Engine. Тот, кто контролирует этот путь, может запускать привилегированные Containers, подключать каталоги хоста и влиять на другие рабочие нагрузки в том же движке. Считайте ноду Docker границей доверия уровня root на соответствующем хосте. Используйте отдельный сервер или осознанно принятую общую границу рабочих нагрузок; права на ресурсы не изолируют систему от скомпрометированного администратора хоста.

DNS и сертификаты

Решите, будет ли Gateway управлять DNS через Cloudflare или записи останутся под внешним управлением. Для выпуска сертификата через HTTP-01 назначенной ноде Ingress нужен публичный порт 80. Для DNS-01 настройте интеграцию с минимальными правами на создание проверочных записей. Если сертификаты загружаются вручную, заранее назначьте ответственного за продление и контроль срока действия.

Для первоначального URL Gateway используйте доменное имя, уже покрытое доверенным сертификатом. Предупреждения браузера во время настройки подталкивают к небезопасным обходам и могут скрыть реальные ошибки прокси или доменного имени.

Проверка готовности

До запуска установщика подтвердите всё перечисленное:

1. Основное доменное имя указывает на нужный адрес.
2. Определено, где завершается TLS и кто отвечает за передаваемые прокси-заголовки.
3. Подготовлены постоянное хранилище и внешнее место для резервных копий.
4. Межсетевой экран пропускает веб-трафик, соединения Relay и необходимые исходящие запросы.
5. Назначены первый администратор и второй ответственный с доступом для восстановления.
6. Роли нод и изоляция хостов выбраны осознанно.
7. Зафиксированы сроки хранения данных, требования к аудиту, уведомлениям и SIEM.
8. Доступны необходимые права тарифного плана.

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

Перед изменением межсетевого экрана см. раздел Порты и сеть.