Выбор режима Rocket Pool
Стек Smartnode Rocket Pool довольно гибкий; существует несколько разных способов его запуска. Он может создать полный узел с нуля, он может интегрироваться с существующими развёртываниями клиентов Execution или Consensus, и он даже может работать нативно как набор системных служб. В этом разделе мы рассмотрим типичные способы настройки и использования стека Smartnode.
Конфигурация на основе Docker по умолчанию
Режим по умолчанию и наиболее распространённый способ запуска Smartnode — это создание полного экземпляра узла на вашей локальной машине, которым управляет Rocket Pool.
Для этого Smartnode использует контейнеры Docker. По сути, контейнер Docker — это небольшая песочница, которая поставляется предварительно настроенной с программой, всеми её зависимостями и всей конфигурацией, необходимой для правильной работы. Когда он больше не нужен, его можно просто выбросить. Это удобный маленький автономный пакет, который позволяет вещам работать без беспорядка в вашей фактической файловой системе или других программах.
Этот режим — то, что установщик Smartnode развернёт для вас. Он использует следующие Docker-контейнеры:
rocketpool_api— содержит фактический функционал, который предоставляет Smartnode, когда вы взаимодействуете с ним через интерфейс командной строки (CLI) Rocket Pool.rocketpool_node— это фоновый процесс, который будет периодически проверять и получать вознаграждения RPL после контрольной точки вознаграждений (если у вас включено автоматическое получение, подробнее об этом позже), и отвечает за фактический стейкинг новых валидаторов, когда вы создаёте минипул.rocketpool_watchtower— используется Oracle Nodes для выполнения обязанностей оракула. Для обычных операторов узлов этот контейнер просто будет бездействовать.rocketpool_eth1— это будет ваш клиент Execution.rocketpool_eth2— это будет ваш клиент Consensus beacon node.rocketpool_validator— это будет ваш Validator client, который отвечает за ваши обязанности валидатора (такие как подтверждение блоков или предложение новых блоков).
В большинстве ситуаций это хороший вариант при создании нового узла с нуля. Это самая быстрая и беззаботная процедура. Он также будет обрабатывать обновления клиентов Execution и Consensus с каждым новым выпуском Smartnode, поэтому вам не нужно беспокоиться о них (хотя вы можете обновить их вручную в любое время, если захотите).
В настоящее время некоторые из Docker-контейнеров должны работать от имени пользователя root для правильного функционирования.
Хотя Docker-контейнеры, как правило, довольно хороши в предотвращении выхода пользователя в вашу основную операционную систему, вам может быть неудобно это требование по соображениям безопасности.
В этом случае мы предлагаем вам использовать режим конфигурации Native, перечисленный ниже.
Если вы хотите использовать этот режим, перейдите к разделу Настройка стандартного узла Rocket Pool с Docker.
Гибридная конфигурация с внешними клиентами
Гибридная конфигурация хорошо подходит для пользователей, которые заинтересованы в запуске узла Rocket Pool, но уже имеют свои собственные клиенты Execution и/или Consensus, работающие для других целей (например, потому что они уже занимаются соло-стейкингом).
В этом режиме Rocket Pool развернёт Docker-контейнеры для своих собственных процессов и для Validator client, которым он управляет, но будет игнорировать контейнеры клиента Execution и Beacon Node для внешних клиентов, которые вы уже запускаете и поддерживаете. Поскольку Rocket Pool будет создавать и поддерживать новые ключи валидатора для каждого из минипулов вашего узла, важно, чтобы он запускал свой собственный Validator client.
При использовании этой конфигурации Smartnode будет использовать следующие Docker-контейнеры (которые были описаны выше):
rocketpool_apirocketpool_noderocketpool_watchtowerrocketpool_validator
Контейнеры rocketpool_eth1 и rocketpool_eth2 будут включены или исключены в зависимости от того, какие клиенты у вас уже работают внешне.
Если вы хотите использовать этот режим, перейдите к разделу Настройка стандартного узла Rocket Pool с Docker. Когда будет предложено выбрать режим управления для ваших клиентов Execution и/или Consensus, выберите опцию Externally Managed, которая подробно описана в этом разделе.
Нативная конфигурация без Docker
Эта конфигурация полностью обходит Docker.
Вместо запуска стека Smartnode через Docker каждый процесс будет установлен как локальная системная служба (например, через systemd).
Это включает процессы node, watchtower, eth1, eth2 и validator.
Эта конфигурация предлагает наибольшую гибкость, поскольку позволяет вам тонко настроить параметры Rocket Pool (такие как его безопасность, где находятся клиенты Execution и Consensus, где находятся данные цепи, где находятся ваши ключи и так далее). Она также является наиболее сложной для настройки и обслуживания.
В этом режиме установщик Smartnode больше не актуален. Вы несёте ответственность за ручное создание экземпляров, поддержание и обновление инфраструктуры Smartnode, клиентов ETH и клиентов валидатора.
Хотя мы предоставляем некоторую примерную документацию о том, как это сделать, мы предлагаем, чтобы этот режим использовался только опытными системными администраторами.
Если вы хотите использовать этот режим, перейдите к разделу Настройка нативного узла Rocket Pool без Docker.