template-devnets

KO | EN

gitlite — search

#python #golang #go #android #deep-learning #docker #macos #nodejs #java #cli #kubernetes #awesome-list #pytorch #ios

template-devnets

(★ 14)

This repository is meant to be used as a template for any future devnets/testnets

template-devnets Latest Version Download

Download Latest Version (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

<div align="center"><img src="./docs/images/panda.png" width="300"/></div>
<h2 align="center">🐼 ❤️.oO<br>"Pandas love everything"</h2>
<h1 align="center">Infrastructure code for Dev/Testnets</h1>

This repository contains the infrastructure code used to setup ~all~ dev/testnets. A lot of the code uses reusable components either provided by our [ansible collection](https://github.com/ethpandaops/ansible-collection-general) or our [helm charts for kubernetes](https://github.com/ethpandaops/ethereum-helm-charts/).

# Networks

Status   | Network    | Links   | Ansible                                                      | Terraform | Kubernetes
------   | --------   | ----     |  -----                                                       | -------   | ------
 🟢Template🔴 | [devnet-0](https://template.devnet.io/)   | [Network config](network-configs/devnet-0) / [Inventory](https://bootnode-1.devnet-0.ethpandaops.io/meta/api/v1/inventory.json) / [Validator ranges](https://bootnode-1.devnet-0.ethpandaops.io/meta/api/v1/validator-ranges.json)    | [🔗](ansible/inventories/devnet-0) | [🔗](terraform/devnet-0) | [🔗](kubernetes/devnet-0)

# Development
## Version management for tools

We're using [asdf](https://github.com/asdf-vm/asdf) to make sure that we all use the same versions across tools. Our repositories should contain versions defined in .tools-versions.

You can then use [`./setup.sh`](./asdf-setup.sh) to install all dependencies.

## Terraform
From [`./terraform/devnet-0/`](./terraform/devnet-0/)

Make sure you select either hetzner or digitalocean (default is digitialocean), if you want to use hetzner rename digitalocean.tf to digitalocean.tf.disabled and rename hetzner.tf.disabled to hetzner.tf and vice versa.

```shell
terraform init
terraform apply
```

Be sure to set the correct terraform backend at `main.tf` and provide correct S3 credentials.

## Ansible
To install the nodes according to the inventory file that is generated by the terraform template run the following commands from [`./ansible/`](./ansible/)
```shell
./install_dependencies.sh
ansible-playbook -i inventories/devnet-0/inventory.ini playbook.yaml
```
In order to clean up the deployment
```shell
ansible-playbook -i inventories/devnet-0/inventory.ini cleanup_ethereum.yaml
```

# Spinning up a New Testnet
To create a new testnet using the infrastructure code, follow these steps:

## Validator Configuration
1. Open the [node.tf](terraform/devnet-0/node.tf) file located in the terraform/devnet-0/ directory.

2. This file contains variables for each different nodes, containing node count, size, and validator ranges.

3. Adjust the validator indexes in the terraform/node.tf file based on your desired allocation of validators to nodes.

For example, let's say you want to assign validator index 0-24 to a single lodestar-besu node and validator index 25-224 to two lighthouse-nethermind nodes. Update the node.tf file as follows:
```terraform
    variable "lodestar-besu" {
      default = {
        name            = "lodestar-besu"
        count           = 1
        validator_start = 0
        validator_end   = 25
      }
    }

variable "lighthouse-nethermind" {
      default = {
        name            = "lighthouse-nethermind"
        count           = 2
        validator_start = 25
        validator_end   = 225
      }
    }
```

This will create loadstar-besu-1 with validator index 0-24, and lighthouse-nethermind-1 and lighthouse-nethermind-2 with validator indexes 25-124 and 125-224, respectively.

If you want to generate the validator indexes for multiple clients easily, use [scripts/split-calculator.py](scripts/split-calculator.py), adjusting the `total_validators`, `validator_per_machine`, and cl/el split ratios according to your needs.

Make sure to adjust the validator ranges according to your requirements and the number of validators in your network. This configuration ensures that validators within the specified ranges will be allocated to the corresponding nodes during the deployment. By customizing the validator indexes in the Terraform configuration, you can allocate validators to specific nodes in your network according to your desired configuration.

4. `terraform apply` will create a the machines and the inventory file for you. The inventory file will be located in the [ansible/inventories/devnet-0](ansible/inventories/devnet-0/) directory.

5. The inventory.ini file will have the list of all the nodes that were created by Terraform. The inventory file will also have the validator ranges that were specified in the Terraform configuration. The validator ranges will be used by the Ansible playbook to allocate validators to the corresponding nodes.
```ini
[lodestar_besu]
lodestar-besu-1 ansible_host=167.99.34.241 cloud=digitalocean cloud_region=ams3 validator_start=0 validator_end=25
...
```

6. Adjust the total number of validators in the [ansible/inventories/devnet-0/group_vars/all/all.yaml](ansible/inventories/devnet-0/group_vars/all/all.yaml) file (ethereum_genesis_generator_config_files.values.env.NUMBER_OF_VALIDATORS) to match with your total number of validators that you are running.. This will be used by the Ansible playbook to generate the validator keys and deposit data for the network.

## Network Configuration
1. [ansible/inventories/devnet-0/group_vars/all/all.yaml](ansible/inventories/devnet-0/group_vars/all/all.yaml) has all the network configuration parameters. Adjust the parameters according to your requirements. Most likely you will not need to adjust these, unless you would like to use a custom setup. The default configuration will work for most networks.

## Secret Configuration
There are multiple secrets used throughout the ansible files, defined in [ansible/inventories/devnet-0/group_vars/all/all.sops.yaml](ansible/inventories/devnet-0/group_vars/all/all.sops.yaml).

If you want to modify the secrets,

1. Install [sops](https://github.com/getsops/sops)
2. Add your pgp key to [.sops.yaml](.sops.yaml) like:
```yaml
creation_rules:
  - pgp: >-
      ABDCE15BD6212E579B3813B78DC0A30AA95F49A1
```
3. Create a `secrets.yaml` file like:
```yaml
secret_zerossl:
    ACME_EAB_KID:
    ACME_EAB_HMAC_KEY:
secret_prometheus_remote_write:
    username:
    password:
secret_loki:
    endpoint:
    username:
    password:
secret_nginx_shared_basic_auth:
    name:
    password:
secret_ethstats:
secret_genesis_mnemonic:
```
4. Encrypt it to `all.sops.yaml`
```bash
sops encrypt secrets.yaml --output ansible/inventories/devnet-0/group_vars/all/all.sops.yaml
```

This will encrypt the elements in the yaml file and put it as ansible yaml file. Each element in the yaml file will be decrypted and used as variables using the configured PGP key.

## Deploying the Network
1. Run
```shell
ansible-playbook -i inventories/devnet-0/inventory.ini playbook.yaml
```
from the [ansible/](ansible/) directory to deploy the network. This will generate the genesis file, validators and deploy the network according to the configuration parameters specified in the [ansible/inventories/devnet-0/group_vars/all/all.yaml](ansible/inventories/devnet-0/group_vars/all/all.yaml) file. The generated files are located at [network-configs/devnet-0/metadata](network-configs/devnet-0/metadata).

Don't forget the following gotchas:
- Change the `ethereum_genesis_chain_id` value in [ansible/inventories/devnet-0/group_vars/all/all.yaml](ansible/inventories/devnet-0/group_vars/all/all.yaml) to avoid clashing with an existing network
- Ensure you have `docker` running on your local machine, this is essential for generating some post-testnet files
- Make sure you add the github usernames to `bootstrap_default_user_authorized_keys_github_...`, otherwise ansible will fail on the bootstrap step

## Accessing the nodes
After deploying the network with ansible, you can access the nodes via ssh-ing into the host adresses listed in `inventory.ini` and the `ansible_user` defined in [ansible/inventories/devnet-0/group_vars/all/00-defaults.yaml](ansible/inventories/devnet-0/group_vars/all/00-defaults.yaml). You will need to have your github username or ssh public key added to `bootstrap_default_user_authorized_keys` before the bootstrap step.

```bash
ssh devops@167.99.34.241
```

Most client software or other plugins are deployed via docker:
```bash
docker inspect execution // for execution client
docker inspect beacon // for consensus client
```

## Cleaning up the Network
1. Run
```shell
ansible-playbook -i inventories/devnet-0/inventory.ini cleanup_ethereum.yaml
```
from the [ansible/](ansible/) directory to clean up the network. This will delete the genesis file, validators and clean up the network on all the nodes.

2. Run
```shell
ansible-playbook -i inventories/devnet-0/inventory.ini ansible-playbook playbook.yaml -t ethereum_genesis -e ethereum_genesis_cleanup=true
```
from the [ansible/](ansible/) directory to clean up the network-configs and validators directories on your local machine. This step is required if you would like to reuse the nodes but with a different genesis configuration. (For example, if you would like to change the validator indexes assigned to the nodes, due to a relaunch).

3. Run `terraform destroy` from the [terraform/devnet-0/](terraform/devnet-0/) directory to delete the nodes. This will remove all the virtual machines and the inventory file. Be careful when running this command, as it will delete all the nodes and the inventory file. You will need to run `terraform apply` again to create the nodes and the inventory file.

## Tooling and Infrastructure
* The tooling for the different test networks is managed by our Kubernetes stack. These tools utilize the [ethereum-helm-charts](https://github.com/ethpandaops/ethereum-helm-charts) repository. The deployment of the tooling is handled by ArgoCD, a continuous delivery and GitOps tool for Kubernetes. (Warning, this will not work, unless ArgoCD is configured to monitor the repository).
* Place any custom tooling in the [kubernetes/devnet-0](kubernetes/devnet-0) directory. The tooling will be deployed to the Kubernetes cluster by ArgoCD.
* Keep the format of kubernetes/devnet-name/tool-name/ as this will be used by ArgoCD to deploy the tooling to the Kubernetes cluster.
* To update a kubernetes helm chart, remove Chart.lock and run `helm dependency update` from the tool directory. This will update the dependencies for the helm chart. Commit the changes to the repository and ArgoCD will automatically deploy the updated tooling to the Kubernetes cluster.
* To add a new tool, create a new directory in the [kubernetes/devnet-0](kubernetes/devnet-0) directory. The directory name will be used as the tool name. Place the helm chart in the tool directory. Commit the changes to the repository and ArgoCD will automatically deploy the new tooling to the Kubernetes cluster.
* To modify the configuration of a tool, modify the values.yaml file in the tool directory. Commit the changes to the repository and ArgoCD will automatically deploy the updated tooling to the Kubernetes cluster.
* To delete a tool, delete the tool directory or move the devnet to kubernetes-archive directory, as this will not be monitored by ArgoCD. Commit the changes to the repository and ArgoCD will automatically delete the tooling from the Kubernetes cluster.

## Additional tips and tricks
* To get the IP addresses of the nodes, run `terraform output` from the [terraform/devnet-0/](terraform/devnet-0/) directory.
* To get the validator ranges run
```shell
curl -s https://bootnode-1.devnet-0.ethpandaops.io/meta/api/v1/validator-ranges.json
```
* To get which validator proposed a specific block run
```shell
ethdo --connection=https://user:password@bn.lighthouse-nethermind-1.devnet-0.ethpandaops.io block info --blockid 100 --json | jq -r .message.proposer_index | ./whose_validator.zsh
```
from the [ansible/](ansible/) directory.
* Getting execution layer client ENRs
```shell
curl -s https://config.devnet-0.ethpandaops.io/api/v1/nodes/inventory | jq -r '.ethereum_pairs[] | .execution.enr'
```
* Getting execution layer client enodes
```shell
curl -s https://config.devnet-0.ethpandaops.io/api/v1/nodes/inventory | jq -r '.ethereum_pairs[] | .execution.enode'
```
* Getting conseus layer client ENRs
```shell
curl -s https://config.devnet-0.ethpandaops.io/api/v1/nodes/inventory | jq -r '.ethereum_pairs[] | .consensus.enr'
```
* Update all sops files
```shell
# Find all .sops.* and *.enc.* files and update their keys
find . -type d -name "vendor" -prune -o \( -type f \( -name "*.sops.*" -o -name "*.enc.*" \) \) -exec sops updatekeys {} -y \;
```

## Genesis allocation used:
Here's a table of where the keys are used

| Account Index | Component Used In | Private Key Used | Public Key Used | Comment                           |
|---------------|-------------------|------------------|----------------|-----------------------------------|
| 0             | tx_fuzz blobs     | ✅               |                | Spams blobs on the network        |
| 1             | tx_fuzz_txs       | ✅               |                | Spams tx on the network           |
| 2             | mev_flood_signing_key| ✅            |                | Spams mev-able txs on the network |
| 3             | mev_flood_user_key| ✅               |                | Spams mev-able txs on the network |
| 4             | faucet-1          | ✅               |                | Faucet 1                          |
| 5             | faucet-2          | ✅               |                | Faucet 2                          |
| 6             | mev_flood_private_key | ✅           |                | Spams mev-able txs on the network |
| 7             | manual-deposits   |   ✅             |                | Used to make manual deposits      |
| 8             | Marius is rich    |                  |                |                                   |
| 9             | goomy             | ✅               |                | Spams blobs on the network        |
| 10            | assertoor         | ✅               |                | Runs various test scenarios       |
| 11            | mev_signing_key   | ✅               |                | Subsidizes mev-able txs on the network |
| 12            | buildoor wallet   | ✅               |                | Pre-funded wallet for buildoor lifecycle deposits/top-ups |
| 13-29         | available         |                  |                |                                   |

template-devnets

template-devnets Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

template-devnets

template-devnets Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

Download README