Using the role
Last updated
Was this helpful?
Last updated
Was this helpful?
The best place to start is to check the examples project. There are multiple example playbooks ranging from a simple single server deployment to a distributed deployment of 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
Each of the examples includes:
Playbook
Variables (inline in the playbook or in group_vars)
Inventory
To use the example playbook you only need to update the inventory to match your hosts.
To get started clone the examples repository and install the requirements:
This section outlines how to deploy all three layers or any combination of them on the same server. In these scenarios execution / consensus / validator run on the same server and communicate over the internal Docker network.
A high-level end state is:
peer-2-peer ports are exposed to the host and accessible from remote nodes
Execution client's JSON RPC API is exposed to the Docker network and not accessible from the host
Consensus client's beacon API is exposed to the Docker network and not accessible from the host
Validator API is not enabled (default behavior)
Metrics are enabled for all layers, exposed to the Docker network and not accessible from the host (Prometheus must be running on the same host and be connected to the same Docker network - check out role)
Shared JWT secret is generated automatically see for more details
In this example all three layers (execution, consensus, validator) are deployed per server. It can be a single or multiple servers. The only two variables you will want to modify are:
This example will deploy the default clients which are Geth and Lighthouse (consensus and validator).
This example will deploy Nethermind and Prysm. To specify the desired client mix, you can modify the "clients" variable:
To run the the playbook:
In this example only execution and consensus layer are deployed. Both on the same server. This can be a single or multiple servers. There are three variables that control which layer gets deployed by the role. With the values below the role will deploy execution and consensus but not the validator. You can toggle the values to achieve the required behavior. The role can deploy any combination.
This example will deploy the default clients which are Geth and Lighthouse.
This example will deploy Nethermind and Prysm (consensus only). To achieve this behavior the variables look as follows:
To run the sample playbook:
This section outlines how to mange split deployments where execution / consensus / validator run on separate servers or for example execution and consensus run on the same server and validator (or multiple validators) run on separate servers.
In these scenarios the clients communicate over the LAN, the API ports are exposed to the host and accessible from anywhere. This kind of deployment is suitable only when your hosts are protected by a network firewall or security groups.
Note: there are multiple ways of achieving similar results, the implementation depends on the goal you want to achieve. This is an example only and it should be adapted to your needs.
In split deployments we need to enable the clients to communicate with one another over the LAN, this means that we need to expose the required API ports to the host.
Furthermore we need to dynamically configure each layer to communicate with required servers.
A high-level end state is:
peer-2-peer ports are exposed to the host and accessible from remote nodes
Execution client's JSON RPC API is exposed to the host and accessible from remote hosts
Consensus client's beacon API is exposed to the host and accessible from remote hosts
Metrics are enabled for all layers, exposed to the host and accessible from remote hosts
Each layer is dynamically configured to connect to the required nodes (for example validator-01 -> consensus-01 -> execution-01)
In this example we deploy each layer on a separate server. The same clients will be deployed to all servers included in the play. The inventory is structured so that we can use group_vars to achieve the desired state.
The inventory:
group_vars:
To run the example playbook:
In this example we deploy each layer on a separate server. In this scenario the role deploys one type of the client to the first 25 servers in each host group and a different client to the remaining 25 servers in each host group.
The inventory is structured so that we can user group_vars to achieve the desired state.
The inventory:
group_vars:
To run the example playbook:
Validator API is not enabled (default behavior - check section for details)
Check the to see the exact variables.
Check the to see the exact variables.