slingnode.ethereum is an Ansible role that facilitates deployment of Ethereum clients. Its objective is to enable a consistent way of deploying and upgrading the chosen client mix. The role can be used to deploy:
- a single node running execution, consensus and validator layers
- hundreds of nodes running all three layers
- a distributed set up with each layer running on a separate server on a single or hundreds of servers
- change client mix (as seamlessly as this can be done)
- upgrade clients
Execution clients:
- Geth
- Nethermind
- Besu
- Erigon
Consensus clients:
- Lighthouse
- Prysm
- Teku
- Nimbus (checkpoint sync currently not supported)
Validator clients:
- Lighthouse
- Prysm
- Teku
- Nimbus
The role has been tested on the following operating systems
RedHat based:
- AlmaLinux 9.1
- AlmaLinux 8.7
- RockyLinux 9.1
- RockyLinux 8.7
- AmazonLinux 2
Debian based:
- Ubuntu 22.04
- Ubuntu 20.04
The README file provides a basic overview only. Full documentation describing the role in details is available at https://docs.slingnode.com/slingnode.ethereum/.
Ansible Docker module is required on the Ansible controller. It can be installed using the below command:
ansible-galaxy collection install community.docker:==3.8.0
The role requires a running docker daemon and docker compose plugin installed on the target server. The role has been tested with "geerlingguy.docker" role. Refer to examples repository for sample Playbooks.
Role variables are defined in 'defaults'. This means they have the lowest precedence and can be easily overridden. See Ansible documentation for details on the precedence.
All client specific variables are defined in their corresponding variable file. All client specific variables have unique names (prefixed with clientname_) so there's no risk of a clash.
Variable location | Purpose |
---|---|
defaults/main/main.yml | generic variables for the role; common variables for all clients |
defaults/main/{{client}}.yml | variables specific to the client |
vars/{{os_family}}.yml | variables specific to the OS |
This section outlines variables that you will most likely want to modify.
clients
"clients" variable defines what clients will be deployed. It defaults to geth and lighthouse. Possible values are:
- execution: geth / nethermind / erigon / besu
- consensus and validator: lighthouse, prysm, teku, nimbus
clients:
execution: geth
consensus: lighthouse
validator: lighthouse
deploy_execution / deploy_consensus / deploy_validator
These three variables define which layer of the stack will be deployed. By default all three layers are deployed. Check out examples to see how they can be used.
deploy_execution: true
deploy_consensus: true
deploy_validator: true
enable_firewall
By default set to true, the role will make sure the firewall package is installed and will configure rules for the client that is being deployed.
enable_firewall: true
This is meant to be a safe default for anyone who uses the role to deploy on a server that is directly exposed to the internet (for example an OVH bare metal server). It is expected that for more enterprise type of deployments this would be set to false. Refer to [Host firewall]https://docs.slingnode.com/slingnode.ethereum/architecture/security#host-firewall) section for details and notes on SSH port.
network
Specifies Ethereum network to connect to.
network: goerli
consensus_checkpoint_sync_enabled
Enable/disable consensus client checkpoint sync feature. Defaults to "true" (sync from checkpoint).
consensus_checkpoint_sync_enabled: true
Refer to Checkpoint sync section for details.
consensus_checkpoint_sync_url
Beacon endpoint to sync from. This needs to match the network you are deploying on. Defaults to Goerli.
consensus_checkpoint_sync_url: https://sync-goerli.beaconcha.in
Refer to Checkpoint sync section for details.
suggested_fee_recipient
A priority fee recipient address on your validator client instance and consensus node.
suggested_fee_recipient: "0xa10214731A6D9eC03d36d1437796D1cEe6a061f7"
graffiti
graffiti: SlingNode.com
The best place to start is to check the examples project. There are multiple example playbooks ranging from a simple single node deployment to a distributed deployment of a large number of nodes. The examples project includes sample playbooks, inventories and group vars that you can adapt to your needs. The examples project is available here https://github.com/SlingNode/slingnode-ethereum-examples
Sample Playbook:
---
- name: Deploy ethereum stack - whole stack per node - default clients (geth & lighthouse)
hosts: all
become: true
vars:
suggested_fee_recipient: "0xa10214731A6D9eC03d36d1437796D1cEe6a061f7"
graffiti: SlingNode.com
roles:
- role: geerlingguy.docker
vars:
docker_package_state: present
docker_install_compose_plugin: true
- role: slingnode.ethereum
If you have any questions join our Discord server or log a GitHub issue.
MIT