Curious why there is no official bitcoind Docker image? about packaging HOT 10 CLOSED

I think ideally a Dockerfile would build from source, rather than use downloaded binaries. Neither of the two most-used docker images do that (ruimarinho and kylemanna), though I haven't checked the others.

from packaging.

It is also a question of who maintains it. Certainly we can copy a random dockerfile from somewhere and bump the version for each release. #2 was closed because it added another build path for distribution. Our deterministic gitian/guix builds should be preferred over that. The "community" docker images also seem to be using the gitian binaries:

• https://github.com/lncm/docker-bitcoind/blob/master/0.20/Dockerfile
• https://github.com/jamesob/docker-bitcoind/blob/master/Dockerfile
• https://github.com/ruimarinho/docker-bitcoin-core/blob/master/0.20/Dockerfile
• https://github.com/NicolasDorier/docker-bitcoin/blob/master/core/0.19.1/Dockerfile
• https://github.com/kylemanna/docker-bitcoind/blob/master/Dockerfile

from packaging.

I see three solutions:

You (the devs) build and upload images to a third-party hub (ongoing maintenance for you)

• Easiest for users (simply run docker pull bitcoin/bitcoind:v0.20.1)
• More work for devs (every new version of bitcoind requires editing the Dockerfile with new versions and hashes)
  • Most of this could be automated with CI/CD (e.g., whenever a new release is tagged on bitcoin/bitcoin, build and upload the Docker image with a new tag to DockerHub). See this for an example.

You (the devs) create an official Dockerfile that users will use in their builds (ongoing maintenance for users)

• More difficult for users (requires users to build their own Docker image, but it's based on your official Dockerfile)
• Less work for devs compared to the first option
  • Devs provide a templated Dockerfile with things that change (i.e., version number, hash, etc...) set as arguments
  • Users run docker build or docker-compose up -d with arguments to specify version, hash, etc..
  • In effect, you only need to create the Dockerfile once, and when a new version comes out, you don't need to update the Dockerfile. See this for an example.

You (the devs) bless a community image as the preferred way to run in Docker

• Even if Bitcoin doesn't officially provide a Docker image or Dockerfile, you promote a community image as the "preferred" way to run in Docker.
• Would require you to select a trustworthy repository
• Preferably a repository like lncm/docker-bitcoind that provides multi-architecture support (for AMD64, ARM, and ARM64)

Personally, I like option 2. Specifically, the way this person does it (minimal code, no crazy scripts, build it yourself locally, specify defaults but allow overrides with build arguments). Someone wanting to run bitcoind in Docker probably has the level of technical knowledge needed to build, tag, and run their own image. Additionally, this would remove any risk of the image being tainted/changed on the third-party hub.

from packaging.

@MarcoFalke I'm not very familiar with docker, but it doesn't seem too hard to make our linux gitian build also produce either a docker image (with all binaries in it) or a Dockerfile (which fetches the binaries from bitcoincore.org and verifies their hash against the gitian output)?

from packaging.

I think ideally a Dockerfile would build from source, rather than use downloaded binaries

Why? This makes it more fragile because dependencies can be switched out by Ubuntu outside our control. Also, it makes it impossible to verify the resulting binary hash against other builders' hashes.

from packaging.

I understand that the "depends" system and Gitian are designed to produce reproducible output?

I think it would be a good idea to compare hashes / binaries. What would be keeping us from continuing to do that?

The more different builders, the better. For a user, running builds inside Docker has the advantage of not needing to trust the build as much as if s/he were running the build locally.

from packaging.

depends itself isn't reproducible, because it still uses the compiler of your OS, which obviously differs per OS. Though, the third party package versions are fixed. You'll need to build with depends inside gitian or guix to get reasonable reproducibility.

Though, those builds are expensive, so not suitable for the default docker file.

from packaging.

Closing due to lack of progress. Pull requests welcome, though.

from packaging.

I think ideally a Dockerfile would build from source, rather than use downloaded binaries

Why? This makes it more fragile because dependencies can be switched out by Ubuntu outside our control. Also, it makes it impossible to verify the resulting binary hash against other builders' hashes.

Not sure if it'd be stepping into Vagrant domain, but
given an ideal infinite developer resource,
I'd maintain up to three dockerfiles:

1. Dockerfile relies on dependencies.
2. Dockerfile downloads, hash checks, builds, every dependency.
3. (Maybe?) same as 2 but building using
   a toolchain previously downloaded and hash checked.

All checking Bitcoin tree hash.

from packaging.

The lncm Dockerfile is designed to be auditable and thus doesn't require being blessed by bitcoin-core. It also both builds from source and produces a final image with just just binaries. I think all that needs to be done is to document that a third party has made an auditable Dockerfile.

from packaging.