将子图部署到托管服务上

Reading time: 11 min

This page explains how to deploy a subgraph to the hosted service. To deploy a subgraph you need to first install the Graph CLI. If you have not created a subgraph already, see creating a subgraph.

Before using the hosted service, create an account in our hosted service. You will need a Github account for that; if you don't have one, you need to create that first. Then, navigate to the hosted service, click on the 'Sign up with Github' button, and complete Github's authorization flow.

创建帐户后，导航到您的 仪表板。 复制仪表板上显示的访问令牌并运行 graph auth --product hosted-service <ACCESS_TOKEN>。 这会将访问令牌存储在您的计算机上。 如果您不需要重新生成访问令牌，您就只需要这样做一次。

Before deploying the subgraph, you need to create it in Graph Explorer. Go to the dashboard and click on the Add Subgraph button and fill in the information below as appropriate:

Image - 选择要用作子图的预览图和缩略图的图像。

Subgraph Name - 子图名称连同下面将要创建的子图账户名称，将定义用于部署和 GraphQL 端点的account-name/subgraph-name样式名称。 此字段以后无法更改。

Account - 创建子图的账户。 这可以是个人或组织的账户。 以后不能在账户之间移动子图。

Subtitle - 将出现在子图卡中的文本。

Description - 子图的描述，在子图详细信息页面上可见。

GitHub URL - 存储在 GitHub 上的子图代码的链接。

Hide - Switching this on hides the subgraph in Graph Explorer.

After saving the new subgraph, you are shown a screen with help on how to install the Graph CLI, how to generate the scaffolding for a new subgraph, and how to deploy your subgraph. The first two steps were covered in the Creating a Subgraph section.

Deploying your subgraph will upload the subgraph files that you've built with yarn build to IPFS and tell Graph Explorer to start indexing your subgraph using these files.

您可以通过运行 yarn deploy来部署子图。

After deploying the subgraph, Graph Explorer will switch to showing the synchronization status of your subgraph. Depending on the amount of data and the number of events that need to be extracted from historical blocks, starting with the genesis block, syncing can take from a few minutes to several hours.

一旦Graph节点从历史区块中提取了所有数据，子图状态就会切换到Synced。在挖掘这些区块时，Graph节点将继续检查子图的区块。

例如，在更改子图定义以修复实体映射中的问题时，再次运行上面的 yarn deploy 命令以部署子图的更新版本。子图的任何更新都需要 Graph 节点 重新索引整个子图，再次从 gensis 区块开始。

如果您之前部署的子图仍处于Syncing状态，系统则会立即将其替换为新部署的版本。 如果之前部署的子图已经完全同步，Graph 节点会将新部署的版本标记为Pending Version，在后台进行同步，只有在新版本同步完成后，才会用新的版本替换当前部署的版本。 这样做可以确保在新版本同步时您仍然有子图可以使用。

在某些情况下，您需要将相同的子图部署到多个网络，而不复制其所有代码。随之而来的主要挑战是这些网络上的合约地址不同。

graph build（从0.29.0版本开始）和graph deploy（从0.32.0版本开始）都接受两个新选项：

选项：

...

--network<name>   从网络配置文件中使用的网络配置

--networkfile<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
        }
    },
    ...
}

注意：您不必在配置文件中指定任何模板（如果有），只需指定dataSources。如果subgraph.yaml文件中声明了任何模板，则其网络将自动更新为--network选项指定的模板。

Now, let's assume you want to be able to deploy your subgraph to the mainnet and sepolia networks, and this is your 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..."
    }
  }
}

现在我们可以运行以下命令之一:

# Using default networks.json file
yarn build --network sepolia

# Using custom named file
yarn build --network sepolia --network-file path/to/config

The build command will update your subgraph.yaml with the sepolia configuration and then re-compile the subgraph. Your subgraph.yaml file now should look like this:

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

现在可以进行 yarn deploy了。

**注意: **如前所述，由于 graph-cli 0.32.0，您可以使用 --network选项直接运行yarn deploy:

# Using default networks.json file
yarn deploy --network sepolia

# Using custom named file
yarn deploy --network sepolia --network-file path/to/config

对于允许参数化诸如合约地址等方面的旧的 graph-cli 版本，一种解决方案是使用诸如 Mustache 或 Handlebar 之类的模板系统生成部分内容。

To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:

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

和

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

除此之外，您还可以使用可变占位符{{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"
  }
}

To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:

# Mainnet:
yarn prepare:mainnet && yarn deploy

# Sepolia:
yarn prepare:sepolia && yarn deploy

这里可以找到一个实际的例子。

**注意: **这种方法也可以应用于更复杂的情况，在这种情况下，需要替换的不仅仅是合约地址和网络名称，或者也需要从模板生成映射或 ABI。

如果子图成功同步，这是一个好信号，表明它将永远运行良好。然而，网络上的新触发器可能会导致子图遇到未经测试的错误条件，或者由于性能问题或节点操作符的问题，子图开始落后。

Graph Node exposes a graphql endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at https://api.thegraph.com/index-node/graphql. On a local node, it is available on port 8030/graphql by default. The full schema for this endpoint can be found here. Here is an example query that checks the status of the current version of a subgraph:

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

这将为您提供 chainHeadBlock，您可以将其与子图上的 latestBlock 进行比较，以检查它是否在后面运行。如果子图已经赶上了链将获取synced。如果没有错误发生，health 可以获取healthy 值，如果有错误发生则获取failed 值。在这种情况下，可以检查fatalError字段以获得有关此错误的详细信息。

The hosted service is a free Graph Node Indexer. Developers can deploy subgraphs indexing a range of networks, which will be indexed, and made available to query via graphQL.

To improve the performance of the service for active subgraphs, the hosted service will archive subgraphs that are inactive.

A subgraph is defined as "inactive" if it was deployed to the hosted service more than 45 days ago, and if it has received 0 queries in the last 45 days.

Developers will be notified by email if one of their subgraphs has been marked as inactive 7 days before it is removed. If they wish to "activate" their subgraph, they can do so by making a query in their subgraph's hosted service graphQL playground. Developers can always redeploy an archived subgraph if it is required again.

A subgraph version in Studio is archived if and only if it meets the following criteria:

• The version is not published to the network (or pending publish)
• The version was created 45 or more days ago
• The subgraph hasn't been queried in 30 days

In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.

受此策略影响的每个子图都有一个选项，可以回复有问题的版本。