Simplified Docker setup using eosio_build.sh script

[liamcurry]

This PR simplifies the Docker setup by using the standard eosio_build.sh script. This makes the builder and dev images unnecessary so they have been removed.

This should help to avoid problems where the Dockerfiles become out of sync with the standard build scripts.

I've tested that this is working and starts a node that produces blocks with these commands:

cd eos/Docker
docker-compose build
docker-compose up

[ericiles]

We initially had our Dockerfile configured in a similar way, which is indeed much easier to maintain. However, through discussion both internally and with the community, it was determined that a one size fits all approach was not the best solution, and led to the approach we currently have (eosio/builder, eosio/eos and eosio/eos-dev images).

eosio/builder

The purpose of the builder image is to compile and store the EOS dependencies, which do not change often, and take an extremely long time to compile, especially on slower systems.

Additionally, the dependencies are well over 1GB in size. This means that without the builder image, every image would unnecessarily be 1GB+ in size uncompressed.

eosio/eos

This image is intended to be a small (~83 MB) image that contains the compiled binaries from the EOS repository. It is targeted at the end-user, and Its intended use is to quickly run a node, or to work with cleos/keosd. In order to keep it small, the Dockerfile utilizes Docker's multistage build functionality along with the eosio/builder image to compile the binaries. It then copies only the resources it needs from the build stage, keeping the image lightweight.

eosio/eos-dev

This image is intended to be used for contract development or working on the EOS codebase. It contains all the binaries found within the eosio/eos image, as well as the binaries required to compile smart contracts. As it is intended to do compilation within the container, it requires the dependencies found in the builder image. Because of this, the Dockerfile does not take the multistage approach, and uses the eosio/builder image as its base. As such, this image is also 1GB+ uncompressed.

---

Now that we have the 1.0 release behind us, we are definitely looking into ways to simplify the Docker situation. However, we will likely still look to make use of both multistage builds, and multiple images with specific purposes, due to the reasons listed above.

[liamcurry]

Thanks @erichim for the detailed response, that makes a lot of sense. I know @heifner has already closed this PR, but I was already working on some changes based on your feedback so I thought I'd share what I have.

Here are some changes I made, you can see them here: https://github.com/sagan-software/eos/tree/simplified-docker/Docker

• Re-added the dev folder which has the Dockerfile that builds EOS
• Changed the primary Dockerfile to use the dev image as a builder
• Added an ENTRYPOINT and some default CMDs for the images
• Added an example docker-compose-mongo.yml file (should be working with 1.1)

The entrypoint changes are kind of nice since they let users pass arguments to nodeos really easily. For example:

# Quickly startup a node that produces blocks, no other configuration necessary
docker run -it eosio/eos
# Print nodeos help test
docker run -it eosio/eos --help
# Print default config
docker run -it eosio/eos --print-default-config

This PR shouldn't be merged, but I'm hoping it could help inform some changes to these Dockerfiles eventually. I'm still concerned about maintaining/syncronizing two different build scripts (eosio_build.sh and the Docker files). I've seen issues before the 1.0 release where the Dockerfiles became outdated -- it's an easy thing to miss after all.

I think a good solution might be to break up the scripts/eosio_build_ubuntu.sh script into two pieces, one for building dependencies and one for building EOS. Then the eosio/builder image could use the Ubuntu dependency builder script, and the eosio/dev and eosio/eos images could use the EOS builder script.

[heifner]

@liamcurry We appreciate your work and would entertain a new PR.