Exposing ports
Last updated
Was this helpful?
Last updated
Was this helpful?
The role defaults to a "single server" deployment and only exposes client p2p ports to the host. All other ports are accessible only over the . This means that (when enabled) execution layer JSON RPC API, consensus layer beacon API and metrics can be accessed only from other containers connected to the same . This default configuration is considered a "safe default" and will work with observability services (such as Prometheus) running on the same server. However, you will not be able to access them from the Docker host or other hosts.
In most cases you will want to customize this behavior to suite your needs. This page describes the main variables that can be used to customize the configuration.
The default port mapping looks as follows when viewed using docker ps (the exact command is: docker ps --format '{{ .Names }}\t{{ .Ports }}'
As explained before, by default the container ports (with exception of the p2p ports) are accessible only over the Docker network. Each port (service) has a corresponding variable that when set to "true" will expose it to the host by mapping it to the loop-back interface (127.0.0.1) of the host. This will make the ports accessible from the host running Docker engine but not from remote hosts. To access the exposed services you'll need to use either a reverse proxy (such as Nginx) or setup .
To expose the following ports to the host:
execution client's authenticated JSON RPC
consensus client's beacon API
metrics for all clients
we would set the following variables to true:
This is what it looks like viewed using docker ps:
To expose ports to the host and make them accessible from remote hosts you can override the following variable:
This is what it looks like viewed using docker ps:
This configuration makes the services accessible over the network.
The variables that can used to define how ports are exposed use the following naming convention:
Refer to for another example.
Configuration outlined in this section is suitable only if you run your servers on a private network behind a network firewall (or security groups), otherwise sensitive APIs and metrics will be exposed to the Internet even if your server has FirewallD or UFW enabled due to how Docker modifies IPTables. Refer to section for details.