Eris is a unique architecture which has taken a very useful advantage of containerizing the data, services - contracts, js, into separate container instances themselves. With the intent of running eris inside docker, I created a docker image using the instructions on 'Getting Started' into a Dockerfile. However, upon setting a CMD/ENTRYPOINT to the instruction, eris init, I cannot create a container instance using docker run -i -t --name test_eris . This makes sense, as the eris server is connecting to the docker daemon to pull images for eris-db, eris-keys, eris-actions, etc. My question around approach to run eris server within a container? 1. Install another docker-daemon inside the Dockerfile for the eris_image. However, this would create a container within container architecture. I suspect this might unnecessarily complicate a much desired laterally scalable architecture. Suggestions? 2. An alternate approach I can think of is building separate container images for eris-cli, eris-db, eris-keys, etc. using the Dockerfiles from eris-ltd github repo. If this were to be the approach, what are the recommendations to ensure that upon creating a private chain, eris can function as expected, with this customer container set up?


Eris is a cli tool focused on container orchestration for blockchainized applications. Normally we recommend it be installed on the host. It's certainly possible to run from inside docker but it will be much less convenient.

That said, we have images available for eris on quay.io. You can also pull the eris-cli repo and build the canonical dockerfile from there.

If you're building your own you will want to have eris init as a RUN command in the dockerfile. The ENTRYPOINT should just be eris. Not eris init.

The easy way, though, to run eris from inside docker is below.

docker pull quay.io/eris/eris && docker run -v /var/run/docker.sock:/var/run/docker.sock ... quay.io/eris/eris erisCommand

Where ... are any other flags you need for your docker container.

  • Change this line and rebuild the docker image. May 31 '16 at 13:00
  • Thanks! In addition to the above suggested change, I had to call wrapdocker - which helped the user connect to the daemon, in case of the usage of privileged flag. Binding docker.sock files from host to container, ensured containers created by the eris commands are actually sibling containers. But this raises questions on how this can be handled in cloud. I have retraced back and separately built images for keys, contracts, ipfs, etc - which may be a better option than dockerizing eris-cli. Are there any suggestions to keep in mind while making custom calls to the containers or adding nodes?
    – skarred14
    Jun 7 '16 at 1:33
  • Shouldn't need to build images yourself, but you always can. We keep images for everything in quay.io/eris ... If you want to handle in the cloud, for now the better way is to utilize kubernetes or docker cloud or another similar system and then utilize the images directly. Eris the tool is really just an automation framework for setting up, turning on, and connecting containers. You could use it from a cloud based container system, but it would likely be more work than is necessary if you are in a relatively stable environment where you just need to turn on and off chains. Jun 8 '16 at 14:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.