I am running the Plutus Pioneer code in a nixos/nix based Docker container and it works a treat. I use the
nix-shell as recommended in the pioneer program repo and I only needed to set up the IOHK binary caches and install
nix) as a prerequisite. I added
tmux to make it more user friendly. I use
tmux to set up a three pane session containing the Plutus server, the playground GUI and one for interactive cabal. Below is the contents of the Dockerfile I use to buid the image.
RUN echo "substituters = https://hydra.iohk.io https://iohk.cachix.org https://cache.nixos.org/" >> /etc/nix/nix.conf && \
echo "trusted-public-keys = hydra.iohk.io:f/Ea+s+dFdN+3Y/G+FDgSq+a5NEWhJGzdjvKNGv0/EQ= iohk.cachix.org-1:DpRUyj7h7V830dp/i6Nti+NEO2/nhblbov/8MW7Rqoo= cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=" >> /etc/nix/nix.conf && \
nix-env --install git && \
nix-env --install curl && \
nix-env --install tmux
It is important to map the /nix folder to a data volume for better performance and to keep the size of the running container down. This folder can easily contain a few tens of Gb of data.
I keep the Plutus and Pioneer code repos on the host and map a data volume to bring it into the container:
docker run -it -p 8009:8009 -v hkvb_nixos_plutus:/nix -v $(pwd):/plutus hkvb/nixos.plutus:original sh
This command only exposes the port of the Playground UI. The
hkvb/nixos.plutus image was built using the Dockerfile above and is available on Docker Hub.
There is one minor change required in the Plutus code to make the playground accessible from outside the container. This is in the webpack.config.js file of the plutus-playground-client. THe DevServer is only bound to the localhost network interface (of the container). Adding the line
makes the server available external to the container.
I have found out that it is best to start from a freshly cloned (or new copy) of the Plutus repository when changing commits for build. Changing commit on a Plutus repository that was already used for a build often resulted in problems for me, often leading to never ending builds, especially when building the documentation.