Порядок развёртывания

Новое окружение Ризомы вводится в эксплуатацию в фиксированном порядке. Пропустите этап — и следующий станет сложнее; следуйте порядку — и каждый этап верифицирует предыдущий.

Подготовка DNS и сертификатов

Решите, что окружение будет открывать публично, до подключения первого узла. Выберите имена ingress, настройте их DNS-записи и подготовьте сертификаты. Публичный ingress — единственная часть mesh, касающаяся открытого интернета, — всё остальное остаётся внутри 100.64.0.0/10.

Создание центра доверия mesh

Поднимите координатор и инициализируйте MeshCA корневой центр доверия. Каждая идентичность в окружении — узлы, пиры, релеи, продуктовые сервисы — будет выпущена из этого корня, поэтому он является главной ценностью развёртывания: держите его ключи вне общих хостов и резервируйте его состояние до подключения чего-либо. Сгенерируйте setup-ключ для первой волны подключения и выпустите токены узлов из координатора.

Типовая подготовка подключения

  # coordinator: create setup key for the first wave
  coordinator setup-key create --name first-wave --limit 8

  # agent: enroll against the coordinator, receive identity
  agent enroll --coordinator <coordinator-host> --setup-key <key>
  #   &lt;- mesh IP, node token, certificates

Подключение первых узлов

Цикл подключения таков: агент вызывает /v1/enroll и получает свои mesh-IP, токен и сертификаты; с этого момента его heartbeat публикует эндпоинты, материал ключей E2E, телеметрию и результаты команд; координатор возвращает пиры, выбор релеев, синхронизацию ACL и назначения ingress. Сначала подключите хосты control plane, проверьте их heartbeat, затем добавьте продуктовые хосты.

Обмен при подключении (схема)

  agent -> POST /v1/enroll           # identity + setup key
  agent &lt;- mesh IP (100.64.0.0/10)   # token, certificates
  agent -> heartbeat                 # endpoints, E2E key, telemetry, command results
  agent &lt;- peers, relay selection    # ACL sync, ingress assignments

Публикация минимальной ACL-политики

Прежде чем открывать трафик между рабочими нагрузками, опубликуйте минимальную политику, делающую окружение работоспособным: какие команды видят какие группы узлов, какие методы разрешены каждой роли и во что компилируется межсетевой экран. Начните с запрета по умолчанию и добавляйте точечные разрешения по мере доказанной необходимости, — шаблон разобран на странице «Политики zero-trust» .

Добавление продуктовых сервисов

После подключения узлов и публикации политик подключите продуктовые сервисы: Webpanel для хостинговых рабочих нагрузок, S3 для объектного хранения (эндпоинт: mesh-IP узла, порт 9000 ), Rizoma Git для рабочих процессов разработчиков и Rizoma Router там, где окружению необходим шлюз безопасности. Каждый сервис привязывается к идентичности mesh — публичные слушатели не создаются, если вы намеренно не публикуете их через ingress.

Проверка сервиса внутри mesh

  # from any enrolled host, the S3 endpoint resolves inside the mesh
  curl http://s3-node.rizoma.mesh:9000/healthz

  # Webpanel health endpoints
  curl http://panel-node.rizoma.mesh:8080/healthz
  curl http://panel-node.rizoma.mesh:8080/readyz

Верификация, резервное копирование, затем открытие трафика

Прежде чем пойдёт производственный трафик: проверьте телеметрию и состояние агентов, координатора, релеев, ingress и дашборда; убедитесь в поступлении метрик Prometheus; сделайте первый снапшот состояния координатора и проверьте восстановление. Только затем открывайте ingress, подготовленный на первом этапе. Пересмотрите политику постквантовых ключей до того, как окружение начнёт нести то, что вы не хотели бы объяснять заказчику.

Первая промышленная проверка. Пройдите сертификационный трек для операторов в качестве пробной проверки собственных знаний о развёртывании: именно эту последовательность охватывает программа сертификации «Оператор» .

Назад System Requirements Далее Post-Quantum Key Policy