## Issue Addressed Closes #1395 ## Proposed Changes * Add a feature to `lighthouse` and `lcli` called `portable` which enables the `portable` feature on our fork of BLST. This feature turns off the `-march=native` C compiler flag that produces binaries highly targeted to the host CPU's instruction set. * Tweak the `Makefile` so that when the `PORTABLE` environment variable is set to `true`, it compiles with this feature. * Temporarily enable `PORTABLE=true` in the Docker build so that the image on Docker Hub is portable. Eventually I think we should enable `PORTABLE=true` _only on Docker Hub_, so that users building locally can take advantage of the tasty compiler magic. This seems to be possible by setting a Docker Hub environment variable: https://docs.docker.com/docker-hub/builds/#environment-variables-for-builds ## Additional Info Tested by compiling on a very new CPU (Intel Core i7-8550U) and copying the binary to a very old CPU (Intel Core i3 530). Before the portability fix, this produced the SIGILL crash described in #1395, and after the fix, it worked smoothly. I'm in the process of testing the Docker build and running some benches to confirm that the performance penalty isn't too severe.
2.8 KiB
Docker Guide
This repository has a Dockerfile in the root which builds an image with the
lighthouse binary installed.
A pre-built image is available on Docker Hub and the
sigp/lighthouse repository
contains a full-featured docker-compose environment.
Obtaining the Docker image
There are two ways to obtain the docker image, either via Docker Hub or building the image from source. Once you have obtained the docker image via one of these methods, proceed to Using the Docker image.
Docker Hub
Lighthouse maintains the sigp/lighthouse Docker Hub repository which provides an easy way to run Lighthouse without building the image yourself.
Download and test the image with:
$ docker run sigp/lighthouse lighthouse --help
Note: when you're running the Docker Hub image you're relying upon a pre-built binary instead of building from source.
Note: due to the Docker Hub image being compiled to work on arbitrary machines, it isn't as highly optimized as an image built from source. We're working to improve this, but for now if you want the absolute best performance, please build the image yourself.
Building the Docker Image
To build the image from source, navigate to the root of the repository and run:
$ docker build . -t lighthouse:local
The build will likely take several minutes. Once it's built, test it with:
$ docker run lighthouse:local lighthouse --help
Using the Docker image
You can run a Docker beacon node with the following command:
$ docker run -p 9000:9000 -p 127.0.0.1:5052:5052 -v $HOME/.lighthouse:/root/.lighthouse sigp/lighthouse lighthouse --testnet medalla beacon --http --http-address 0.0.0.0
To join the altona testnet, use --testnet altona instead.
The
-pand-vand values are described below.
Volumes
Lighthouse uses the /root/.lighthouse directory inside the Docker image to
store the configuration, database and validator keys. Users will generally want
to create a bind-mount volume to ensure this directory persists between docker run commands.
The following example runs a beacon node with the data directory mapped to the users home directory:
$ docker run -v $HOME/.lighthouse:/root/.lighthouse sigp/lighthouse lighthouse beacon
Ports
In order to be a good peer and serve other peers you should expose port 9000.
Use the -p flag to do this:
$ docker run -p 9000:9000 sigp/lighthouse lighthouse beacon
If you use the --http flag you may also want to expose the HTTP port with -p 127.0.0.1:5052:5052.
$ docker run -p 9000:9000 -p 127.0.0.1:5052:5052 sigp/lighthouse lighthouse beacon --http --http-address 0.0.0.0