Роли нод и установка

Требования к ролям одинаковы для нод на ваших серверах и для ВМ, созданных через Gateway.

Роль ноды определяет, чем Gateway сможет управлять на этом сервере: Ingress, Docker, базами данных, сборками, мониторингом или Relay. Вместе с ролью устанавливается нужный набор программ и выдаются только необходимые полномочия. Выбирайте роль по назначению сервера, а не по пакетам, которые уже случайно на нём установлены.

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

Что требуется каждой роли

Используйте сгенерированную команду установщика из сценария создания ноды. Она содержит ограниченные регистрационные данные и закреплённую идентичность Gateway.

nginx: требует nginx, публичных портов Ingress там, где они нужны, валидации конфигурации и доступа к журналам.
Docker: требует поддерживаемый Docker Engine и права на настроенные операции среды выполнения.
database: требует выделенное хранилище и средства ядра и хранилища, указанные установщиком.
builder: требует выделенную ёмкость BuildKit/containerd и не должен иметь сокет Docker Engine.
monitoring: предоставляет поддерживаемый сбор данных мониторинга.
Relay supervisor/worker: расширяет ёмкость и устойчивость Relay с явным размещением.

После установки проверяйте отчёт о возможностях, а не делайте вывод по наличию пакетов на хосте. Функции GPU, Secure Runtime, builder, хранилища и миграции зависят от сообщённых работоспособных возможностей.

Выберите роль

Ingress: завершает TLS и обслуживает публичные Domains и Routes. Ему нужны валидация конфигурации nginx, хранилище сертификатов, журналы и публичные порты там, где они требуются.
Docker: управляет обычными рабочими нагрузками приложений и ресурсами Docker. Ему нужны поддерживаемый Docker Engine и права для выбранных функций среды выполнения.
Build Worker: запускает сборки Git в изолированных службах BuildKit/containerd. Он должен быть выделен под сборки и не должен открывать профилю builder обычный сокет Docker Engine.
Databases: запускает управляемые PostgreSQL, Redis и ClickHouse с отдельной подготовкой хранилища и ограниченным профилем Docker-демона.
Monitoring: собирает поддерживаемые данные о состоянии и метрики хоста без прав на жизненный цикл рабочих нагрузок.
Relay: устанавливает supervisor Relay, объявляет доступный адрес и присоединяется к Relay Pool для Secure Link.

Стандартный поток регистрации

Откройте Nodes и выберите Add Node.
Выберите нужный Node Type и прочитайте описание.
Введите стабильное имя, понятное оператору.
Для Relay укажите адрес, к которому участвующие ноды могут обратиться по TCP 9443.
Создайте ожидающую ноду.
Скопируйте сгенерированную одноразовую команду установки.
Выполните команду на нужном Linux-хосте.
Оставьте диалог результата открытым, пока демон устанавливается и регистрируется; он закроется автоматически, когда именно эта нода перейдёт в состояние online.
Откройте страницу ноды и проверьте роль, имя хоста, версию, возможности, метрики и служебные адреса.

Действие Add relay node в настройках Relay открывает тот же сценарий с заранее выбранным и заблокированным типом Relay. Участник Relay отображается как готовая ёмкость пула только после успешной регистрации и передачи состояния.

Подготовка хоста

Используйте выделенный хост или виртуальную машину, если роль образует сильную границу доверия. До запуска установщика проверьте DNS, системное время, исходящую доступность Relay, требования к пакетам и среде выполнения, постоянное хранилище и наличие systemd. Не используйте команду установщика для другой ожидающей записи ноды.

Для нод баз данных установщик выполняет предварительную проверку хранилища. Build Workers требуют выделенных вычислительных ресурсов и хранилища. Нодам Relay нужен доступный объявленный адрес; если Relay Pool должен обеспечивать устойчивость, размещайте ноды в разных доменах отказа.

Проверка и очистка

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

Ошибки установки

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

Нода, зарегистрированная без ожидаемой возможности, не готова к своей роли. Проверьте профильную службу, права на сокет или хранилище, необходимые функции ядра и ограниченный фрагмент журналов запуска демона. Исправьте предварительное условие хоста и дождитесь обновления отчёта; смена Node Type после установки не заменяет правильный профиль.

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

Безопасность после установки

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

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