Building your own Parity Docker image

Why?

I've found it useful to build my own Docker images for a couple of reasons. First, the builds on Docker Hub are sometimes delayed or fail. Second, you're never quite sure exactly which version you're getting from there. Parity's build system seems to trigger interim builds between official releases that may contain code that is later rolled back. I've had one blokchain database trashed by this; building my own images give me full version control.

The downside is that a build from scratch takes over an hour. Docker caches some bits automatically, but this only saves a few minutes.

Using the official Docker file

This helps with the first of the issues above, but doesn't address the second.

For the latest stable release just execute the following commands at the QNAP admin command line.

wget https://raw.githubusercontent.com/ethcore/parity/master/docker/ubuntu-stable/Dockerfile
docker build -t my-parity-stable .

For the latest beta release just use this.

wget https://raw.githubusercontent.com/ethcore/parity/master/docker/ubuntu/Dockerfile
docker build -t my-parity-beta .

All being well. after an hour or so you should have a shiny new Parity Docker image called my-parity-stable or my-parity-beta that you can reference in your Docker Compose files.

Building a specific Parity version

What I actually do is build the commit hash of a specific Parity release. The commit hash is shown in the bar on the left of the Releases page.

For example, to build v1.4.5, the commit hash is a028d04. Just change the hash value in the git checkout line to build a different commit. Note that we need to create a temporary branch in order to avoid getting into a "headless" state, and we removed the following git pull line.

FROM ubuntu:14.04
WORKDIR /build
# install tools and dependencies
RUN apt-get update && \
        apt-get install -y \
        g++ \
        build-essential \
        curl \
        git \
        file \
        binutils

# install rustup
RUN curl https://sh.rustup.rs -sSf | sh -s -- -y

# rustup directory
ENV PATH /root/.cargo/bin:$PATH

# show backtraces
ENV RUST_BACKTRACE 1

# show tools
RUN rustc -vV && \
cargo -V && \
gcc -v &&\
g++ -v

# build parity
RUN git clone https://github.com/ethcore/parity && \
        cd parity && \
        git checkout -b tmp a028d04 && \
        cargo build --release --verbose && \
        ls /build/parity/target/release/parity && \
        strip /build/parity/target/release/parity

RUN file /build/parity/target/release/parity

EXPOSE 8080 8545 8180
ENTRYPOINT ["/build/parity/target/release/parity"]

Save the above to Dockerfile and run

docker build -t my-parity-v1_4_5 .

You can list your available images with docker images, and remove old ones with docker rmi.

Avoiding hangups

One problem I had was that sometimes my ssh connection into the QNAP would drop during the build. As a result, the build would eventually fail. This is a big waste of time on such a long build.

Ordinarily on Linux/Unix I'd use the nohup command to avoid this, but it is not available on the QNAP command line. Instead I learnt something new: the screen command. screen is a basic in-terminal "window manager" that can own the processes for you if your session hangs up.

1. Run screen -L -S PARITY.
2. Execute the long-running docker build command.
3. Do Ctrl-A Ctrl-D to disconnect from the screen session.
4. Use screen -r PARITY to reconnect to the session later if necessary.

You can use screen -ls to check what sessions are running. (The QNAP also uses screen itself so you may see other sessions listed.) The -L flag to screen logs its output to a file; you can use tail -f screenlog.0 after detaching from the session to monitor progress.

References for screen:

• Man page: http://manpages.ubuntu.com/manpages/xenial/en/man1/screen.1.html
• Simple info: http://www.howtogeek.com/howto/ubuntu/keep-your-ssh-session-running-when-you-disconnect/
• Info: http://askubuntu.com/questions/8653/how-to-keep-processes-running-after-ending-ssh-session