subgraphs > Developing > Deploying > Развертывание субграфа в нескольких сетях

Развертывание субграфа в нескольких сетях

Reading time: 5 min

На этой странице объясняется, как развернуть субграф в нескольких сетях. Чтобы развернуть субграф, сначала установите [Graph CLI] (https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). Если Вы еще не создали субграф, смотрите раздел [Создание субграфа] (/developing/creating-a-subgraph/).

Развертывание подграфа в нескольких сетях

⁠Ссылка на этот раздел

В некоторых случаях вы захотите развернуть один и тот же подграф в нескольких сетях, не дублируя весь его код. Основная проблема, возникающая при этом, заключается в том, что адреса контрактов в этих сетях разные.

Использование `graph-cli`

⁠Ссылка на этот раздел

Как graph build (начиная с v0.29.0), так и graph deploy (начиная с v0.32.0) допускают две новые опции:

Опции:
      ...
      --network <name> Конфигурация сети для использования из файла конфигурации сетей
      --network-file <path> Путь к файлу конфигурации сетей (по умолчанию: "./networks.json")

Вы можете использовать опцию --network для указания конфигурации сети из стандартного файла json (по умолчанию используется networks.json), чтобы легко обновлять свой субграф во время разработки.

Примечание: Команда init теперь автоматически сгенерирует networks.json на основе предоставленной информации. Затем Вы сможете обновить существующие или добавить дополнительные сети.

Если у Вас нет файла networks.json, Вам нужно будет вручную создать его со следующей структурой:

{
    "network1": { // the network name
        "dataSource1": { // the dataSource name
            "address": "0xabc...", // the contract address (optional)
            "startBlock": 123456 // the startBlock (optional)
        },
        "dataSource2": {
            "address": "0x123...",
            "startBlock": 123444
        }
    },
    "network2": {
        "dataSource1": {
            "address": "0x987...",
            "startBlock": 123
        },
        "dataSource2": {
            "address": "0xxyz..",
            "startBlock": 456
        }
    },
    ...
}

Примечание: Вам не нужно указывать ни один из templates (если они у Вас есть) в файле конфигурации, только dataSources. Если есть какие-либо templates, объявленные в файле subgraph.yaml, их сеть будет автоматически обновлена до указанной с помощью опции --network.

Теперь давайте предположим, что Вы хотите иметь возможность развернуть свой субграф в сетях mainnet и sepolia, и это Ваш subgraph.yaml:

# ...
dataSources:
  - kind: ethereum/contract
    name: Gravity
    network: mainnet
    source:
      address: '0x123...'
      abi: Gravity
    mapping:
      kind: ethereum/events

Вот как должен выглядеть файл конфигурации ваших сетей:

{
  "mainnet": {
    "Gravity": {
      "address": "0x123..."
    }
  },
  "sepolia": {
    "Gravity": {
      "address": "0xabc..."
    }
  }
}

Теперь мы можем запустить одну из следующих команд:

# Использование стандартного файла networks.json
yarn build --network sepolia

# Использование файла с пользовательским именем
yarn build --network sepolia --network-file path/to/config

Команда build обновит Ваш subgraph.yaml конфигурацией sepolia, а затем повторно скомпилирует субграф. Ваш файл subgraph.yaml теперь должен выглядеть следующим образом:

# ...
dataSources:
  - kind: ethereum/contract
    name: Gravity
    network: sepolia
    source:
      address: '0xabc...'
      abi: Gravity
    mapping:
      kind: ethereum/events

Теперь Вы готовы выполнить команду yarn deploy.

Примечание: Как упоминалось ранее, начиная с версии graph-cli 0.32.0 Вы можете напрямую выполнить команду yarn deploy с опцией --network:

# Использование стандартного файла networks.json
yarn deploy --network sepolia

# Использование файла с пользовательским именем
yarn deploy --network sepolia --network-file path/to/config

Использование шаблона subgraph.yaml

⁠Ссылка на этот раздел

Одним из способов параметризации таких аспектов, как адреса контрактов, с использованием старых версий graph-cli является генерация его частей с помощью системы шаблонов, такой как Mustache или Handlebars.

Чтобы проиллюстрировать этот подход, давайте предположим, что субграф должен быть развернут в майннете и в сети Sepolia с использованием разных адресов контракта. Затем Вы можете определить два файла конфигурации, содержащие адреса для каждой сети:

{
  "network": "mainnet",
  "address": "0x123..."
}

{
  "network": "sepolia",
  "address": "0xabc..."
}

Наряду с этим, необходимо заменить имя сети и адреса в манифесте на variable placeholders {{network}} и {{address}} и переименовать манифест, например, subgraph.template.yaml:

# ...
dataSources:
  - kind: ethereum/contract
    name: Gravity
    network: mainnet
    network: {{network}}
    source:
      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
      address: '{{address}}'
      abi: Gravity
    mapping:
      kind: ethereum/events

Чтобы сгенерировать манифест для любой сети, можно добавить две дополнительные команды в package.json вместе с зависимостью от mustache:

{
  ...
  "scripts": {
    ...
    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
  },
  "devDependencies": {
    ...
    "mustache": "^3.1.0"
  }
}

Чтобы развернуть этот субграф для основной сети или сети Sepolia, Вам нужно просто запустить одну из двух следующих команд:

# Mainnet:
yarn prepare:mainnet && yarn deploy

# Sepolia:
yarn prepare:sepolia && yarn deploy

Наглядный пример можно найти здесь.

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

Это предоставит Вам chainHeadBlock, который Вы сможете сравнить с latestBlock своего субграфа, чтобы проверить, не отстает ли он. synced сообщает, попал ли субграф в чейн. health в настоящее время может принимать значения healthy, если ошибки отсутствуют, или failed, если произошла ошибка, остановившая работу субграфа. В этом случае Вы можете проверить поле fatalError для получения подробной информации об этой ошибке.

Политика архивирования подграфов в Subgraph Studio

⁠Ссылка на этот раздел

Версия субграфа в Studio архивируется, если и только если выполняются следующие критерии:

Версия не опубликована в сети (или ожидает публикации)
Версия была создана 45 или более дней назад
Субграф не запрашивался в течение 30 дней

Кроме того, когда развертывается новая версия, если субграф не был опубликован, то версия N-2 субграфа архивируется.

У каждого подграфа, затронутого этой политикой, есть возможность вернуть соответствующую версию обратно.

Проверка работоспособности подграфа

⁠Ссылка на этот раздел

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

Graph Node предоставляет конечную точку GraphQL, которую Вы можете запросить для проверки статуса своего субграфа. В хостинговом сервисе он доступен по адресу https://api.thegraph.com/index-node/graphql. На локальной ноде он по умолчанию доступен через порт 8030/graphql. Полную схему для этой конечной точки можно найти здесь. Вот пример запроса, проверяющего состояние текущей версии субграфа:

{
  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
    synced
    health
    fatalError {
      message
      block {
        number
        hash
      }
      handler
    }
    chains {
      chainHeadBlock {
        number
      }
      latestBlock {
        number
      }
    }
  }
}