Розробка системи автоматичного розгортання нод

Розробка системи автоматичного розгортання нод

Ручне управління інфраструктурою блокчейн-нод не масштабується. Коли у вас 3 ноди — справляється один DevOps з Ansible playbook та написаними вручну скриптами. Коли нод 50–300 і вони працюють у 5 різних мережах, деякі з них — validator-ноди з stake — ручне управління перетворюється в головний операційний ризик. Одне неправильне оновлення бінарника на validator-ноді Tendermint може призвести до double-sign та slashing. Система автоматичного розгортання — це не зручність, це вимога надійності.

Вимоги до архітектури

Перед проектуванням потрібно відповісти на кілька запитань, які кардинально впливають на архітектуру:

• Які мережі? EVM (Geth, Reth, Erigon), Cosmos SDK, Solana, Substrate, кастомні — кожна має специфіку деплоя
• Які ролі нод? Full node, archive node, validator, RPC endpoint — різні вимоги до залізниці, конфігурації, моніторингу
• Який cloud/bare metal? AWS/GCP/Azure через Terraform, Hetzner/OVH через API, власний datacenter через IPMI
• Які вимоги до uptime? Validator-ноди потребують zero-downtime оновлень та окремого аварійного playbook
• Хто управляє? Одна команда чи мультиарендна система для кількох клієнтів

Ключові компоненти системи

1. Infrastructure provisioning

Основа — Terraform для декларативного опису інфраструктури. Кожен тип ноди описується модулем:

module "ethereum_validator" {
  source = "./modules/ethereum-node"
  
  count         = var.validator_count
  instance_type = "c6i.4xlarge"  # 16 vCPU, 32GB RAM
  
  # NVMe SSD обов'язковий для Ethereum full node
  root_volume_size = 50
  data_volume_size = 3000  # ~2.5TB для mainnet archive
  data_volume_type = "io2"
  data_volume_iops = 16000
  
  vpc_id            = module.vpc.id
  security_group_id = module.node_sg.id
  
  tags = {
    Network  = "ethereum"
    NodeType = "validator"
    ManagedBy = "terraform"
  }
}

Критично важна стратегія зберігання даних: блокчейн-ноди мають специфічні I/O паттерни (послідовна запис під час sync, випадкове читання при запитах). Для Ethereum mainnet — мінімум NVMe SSD з 4000+ IOPS. Використання gp2/gp3 без налаштування IOPS — часта помилка, яка призводить до того що нода завжди відстає від chain head.

2. Configuration management

Ansible для конфігурації нод. Кожна мережа — окремена роль:

# roles/ethereum-node/tasks/main.yml
- name: Deploy Geth via Docker
  docker_container:
    name: geth
    image: "ethereum/client-go:{{ geth_version }}"
    restart_policy: unless-stopped
    volumes:
      - "/data/ethereum:/root/.ethereum"
    ports:
      - "30303:30303/tcp"
      - "30303:30303/udp"
      - "8545:8545"
      - "8546:8546"
    command: >
      --mainnet
      --syncmode snap
      --http --http.api eth,net,web3,txpool
      --ws --ws.api eth,net,web3
      --metrics --metrics.addr 0.0.0.0
      --maxpeers 50
      --cache {{ geth_cache_mb }}

- name: Deploy consensus client (Lighthouse)
  docker_container:
    name: lighthouse
    image: "sigp/lighthouse:{{ lighthouse_version }}"
    command: >
      lighthouse bn
      --network mainnet
      --execution-endpoint http://geth:8551
      --jwt-secrets /secrets/jwtsecret
      --checkpoint-sync-url https://mainnet.checkpoint.sigp.io

Ключовий момент: версії завжди пінити явно. image: ethereum/client-go:latest в production — це катастрофа, що чекає на свій час. Оновлення мають бути керованими, не автоматичними.

3. Оркестрація та CI/CD

Управління життєвим циклом нод через control plane. Залежно від масштабу це може бути Kubernetes (для великих операцій) чи простіше рішення на базі черг задач.

Типова схема оновлення validator-ноди без downtime для Cosmos SDK:

1. Provision нової ноди → очікування повної синхронізації через snapshot
2. Перевіряємо sync status (lag < 10 блоків)
3. Graceful shutdown старої ноди (очікуємо commit блоку)
4. Переносимо validator key на нову ноду
5. Запускаємо validator на новій ноді
6. Переконуємося що нода підписує блоки
7. Припиняємо стару ноду

Цей процес має бути повністю автоматизованим та відтворюваним. Якщо крок 4 виконується вручну — це точка відмови. Validator key мають бути збережені у Vault (HashiCorp Vault або AWS Secrets Manager) та видані ноді через автоматизацію, не через ручне копіювання.

4. Мониторинг та алертинг

Stack моніторингу блокчейн-нод:

Для validator-нод критичні специфічні метрики:

• Missed blocks (Cosmos: tendermint_consensus_validator_missed_blocks)
• Double sign ризик — мониторинг що одночасно підписує тільки одна інстанція
• Slash events — on-chain мониторинг через event subscription

5. Управління снапшотами

Sync з нуля для Ethereum mainnet — 3–7 днів. Для Cosmos-мереж — години чи дні. Система має управляти снапшотами:

class SnapshotManager:
    def __init__(self, storage: S3Storage, networks: list[str]):
        self.storage = storage
        self.networks = networks
    
    async def create_snapshot(self, node: Node) -> Snapshot:
        # зупинити ноду чи використовувати online snapshot якщо підтримується
        await node.pause_if_needed()
        
        snapshot = await self.storage.upload_compressed(
            source=node.data_dir,
            key=f"snapshots/{node.network}/{node.height}.tar.lz4",
            compression="lz4",  # швидше ніж gzip, прийнятне стиснення
        )
        
        await node.resume()
        await self.storage.update_latest_pointer(node.network, snapshot)
        return snapshot
    
    async def restore_from_snapshot(self, node: Node) -> None:
        snapshot = await self.storage.get_latest(node.network)
        await self.storage.download_and_extract(
            key=snapshot.key,
            destination=node.data_dir,
        )

Снапшоти мають створюватися автоматично за розкладом (щотижня для повільних мереж, щодня для активних) та використовуватися при створенні нових нод — це скорочує час готовності ноди з днів до годин.

Специфіка різних мереж

EVM-ноди (Ethereum, Polygon, BSC)

• Подвійний клієнт: execution layer (Geth/Reth/Erigon) + consensus layer (Lighthouse/Prysm/Teku)
• JWT secret для Engine API між клієнтами
• Erigon для archive nodes: ~2.5TB проти ~12TB у Geth

Cosmos SDK-ноди

• Бінарник специфічний для кожної мережі (gaiad, osmosisd, evmosd...)
• Cosmovisor для автоматичних chain upgrade через governance
• State sync vs snapshot відновлення
• Validator key — Ed25519, зберігається окремо від node key

Solana

• Вимоги до залізниці принципово вище: 512GB RAM рекомендовано для validator
• RPC ноди та validator ноди — різна конфігурація
• Catchup через known validator, не з genesis

Substrate (Polkadot, Kusama, parachains)

• Parachain ноди потребують relay chain ноди
• Runtime upgrades відбуваються on-chain через governance — бінарник оновлюється автоматично

Безпека інфраструктури

Validator-ноди потребують окремої threat model:

• Network isolation: validator не має бути публічно доступний. Тільки через sentry ноди (sentry node architecture)
• Key management: private signing key ніколи не зберігається у plaintext на диску
• HSM: для великих операцій — Ledger або спеціалізовані HSM (YubiHSM) для підпису
• Firewall: мінімальний набір відкритих портів, whitelist по IP для управління
• Audit log: всі змінення конфігурації логуються з авторством

Автоматизація деплоя не означає втрату контролю — це означає що кожна зміна проходить через code review та CI/CD pipeline, а не застосовується на сервері вручну інженером.