Deployments
This section describes the various types of deployments and options used for each.
- +From 241d8a9253f1c31d37f234111f2182a1e10e1b80 Mon Sep 17 00:00:00 2001
From: PierreBesson This section describes the various types of deployments and options used for each.Parachain Devops Guide
Deployments
Proxy accounts also let you limit the permission that an account or multisig account has on a particular target account (e.g. only staking functions can be executed by the staking controller multisig account and require 3 of 5 people to approve).
- +KEY_SCHEME
: an encryption scheme (eg. sr25519
, ed25519
, ecdsa
)
KEY_FILE
: a plain text file which contains the seed or private keyThis section provides useful guides for getting started with Polkadot infrastructure.
- +ws://127.0.0.1:9944
.
Note: if you look at the node logs, it should be starting to sync the relay-chain (Rococo in our case). You don’t have to wait until it is fully synced.
+Note: if you look at the node logs, it should be starting to sync the relay-chain (Rococo in our case). For this dry-run step, you don’t have to wait until it is fully synced. However, after deployment, a node needs to be fully synced in order to collate parachain blocks.
You can use any method you choose to set up your nodes on your machines, we recommend either Ansible
Note: any account with enough funds can buy and assign coretime for a parachain.
TODO
- +runtime=debug
, sync=debug
, author=debug
, xcm=debug
, etc.
This section provides a deployment guide for an RPC node via Ansible and Kubernetes.
- +As previously mentioned, Kubernetes deployments are only recommended for people with good prior operating experience of Kubernetes.
- +The testnet-manager is deployed in the same Kubernetes namespaces as nodes deployed with the node helm-chart. As node pods deployed with the chart are tagged with the appropriate labels (e.g. chain name, para ID), the manager is able to query the Kubernetes API and list the running nodes for each network (relay-chain, parachains).
By combining this list of nodes with the on-chain state retrieved from RPC endpoints (e.g. list of active validators accounts), the manager can automate node key setup (by interacting directly with each node RPC endpoint) and registration (by submitting sudo extrinsics). Behind the scenes, it uses a derivation formula for generating deterministic Validator/Collator accounts addresses: "${VALIDATORS_ROOT_SEED}//${node-name}".
- +An example of the metric dashboard from polkadot-monitoring-mixin:
- +To avoid confusion caused by running metrics on different ports, it is recommended to maintain uniformity by using the same Prometheus port (default is 9615) for all relay chain metrics. The chain label in the metrics helps determine which metric belongs to which chain, ensuring clarity and organization.
By following this guide, you can effectively expose and manage Prometheus metrics for both the Polkadot relay chain and parachain binaries.
- +subkey
is a cli tool for generating substrate based account. It can also be used for signing and verifying messages, but in this doc we only cover account creation and node key (libp2p) generation.
In order to install the tool, please reference the substrate documentation: https://docs.substrate.io/reference/command-line-tools/subkey/#installation
@@ -238,9 +238,9 @@This section provides useful guides for getting started with Polkadot infrastructure.
-This guide demonstrates the deployment of a parachain test network composed of 2 collators (nodes authoring blocks) and 1 RPC node. We are using Rococo as an example, but this approach would work similarly for any Relaychain, whether it is a testnet (Westend, Rococo, Paseo) or a mainnet (Polkadot, Kusama).
ws://127.0.0.1:9944
.
Note: if you look at the node logs, it should be starting to sync the relay-chain (Rococo in our case). You don’t have to wait until it is fully synced.
+Note: if you look at the node logs, it should be starting to sync the relay-chain (Rococo in our case). For this dry-run step, you don’t have to wait until it is fully synced. However, after deployment, a node needs to be fully synced in order to collate parachain blocks.
You can use any method you choose to set up your nodes on your machines, we recommend either Ansible
Note: any account with enough funds can buy and assign coretime for a parachain.
TODO
-An RPC node is a server that allows external applications to interact with the Polkadot chain. This interaction is facilitated through a set of standardized APIs which enable the execution of various operations and retrieval of blockchain data. Here are some key points about an RPC node in Polkadot:
Functions of an RPC Node: Querying Blockchain Data: RPC nodes can be used to fetch information from the blockchain, such as block details, transaction histories, account balances, and other state information. @@ -598,7 +598,7 @@
This section provides a deployment guide for an RPC node via Ansible and Kubernetes.
-This guide demonstrates the deployment of an RPC node via Helm chart in Kubernetes.
Parity maintains a helm GitHub repo @ https://github.com/paritytech/helm-charts - Inside this repo is the node chart which can be used for deploying your Substrate/Polkadot binary.
@@ -757,7 +757,7 @@Collators are members of the network that maintain the parachains they take part in. Collators produce the state transition proof for relay chain validators but also author the blocks for the parachain and pass them to relay chain. There are some requirements that need to be considered prior to becoming a collator candidate including machine, bonding, account, and community requirements. For more info regarding collators, reference collator section on Polkadot wiki page.
This doc demonstrates how to add new collators to an already running parachain.
Before launching your parachain network, verify the readiness of your network infrastructure by reviewing the following five key points.
runtime=debug
, sync=debug
, author=debug
, xcm=debug
, etc.
It is highly recommended that projects deploying networks have an infrastructure as code mindset. The infrastructure components in deployments should be written in code and put in a version control system.
This ensures that:
@@ -993,9 +993,9 @@Proxy accounts also let you limit the permission that an account or multisig account has on a particular target account (e.g. only staking functions can be executed by the staking controller multisig account and require 3 of 5 people to approve).
-This section describes the various types of deployments and options used for each.
-A non exhaustive list of some common roles assumed by nodes:
Role | Description |
---|---|
Validator | Secures the Relay Chain by staking DOT, validating proofs from collators on parachains and voting on consensus along with other validators. |
Type | Description |
---|---|
Physical Server | Usually a rack mounted server sitting in a data center. |
When deploying our blockchain nodes, we will need an inventory which contains a list of our hosts and the groups they are in (e.g. validator, collator, rpc) and maybe some secrets which can be encrypted inline within the inventory using Ansible vault. We will then call a playbook which links hosts/groups in the inventory with roles to execute on each host.
Some examples of using Ansible can be found in the Paritytech's Ansible Galaxy GitHub repo. Specifically the node role.
- +You can do this with multiple variables to abstract the configuration from the systemd file running on your hosts.
- +