As there's absolutely no way to have deterministic builds of Docker images 😭, we need to figure out the best way forward.

Our images need to be build in 2-3 architectures: amd64, arm32v6 and/or aarch64. The first one is absolutely trivial to build on either (Travis, Docker Cloud, Codeship, circleci etc…). However, the last two are a bit more challenging, as neither of the popular CI tools offers builds native to these architectures.

AFAIK there are three main paths forward. Let's discuss them.

1. Cross-compile using qemu

• The biggest advantage of this approach is that it offers users the highest degree of auditability - they can look how build/deploy pipeline is setup, see build logs, and verify that the log corresponds to a correct Dockerfile and that the container IDs match between build log and images hosted on Docker Cloud
• The biggest disadvantage is the necessity to use qemu:
  • in most cases (pretty much anything other than bitcoin-core), it's enough to DL a qemu-arm-static binary from an official source, and just COPY it into the correct location in the container and alter FROM sources to explicitly request images in the desired architecture. Example of all pre-build steps here.
  • the case of bitcoin-core is unfortunately much more involved and hacky/patchy, as currently only Codeship has an execution time that's long enough, and AFAIK they don't allow for neither sudo access nor execution of any commands prior to image build. And because of that building bitcoin-core requires all these files (some can be compiled from source directly some others need to be DLed from a Github repo) as well as some extra changes to the Dockerfile itself (example)
  • I think qemu is also not guaranteed to be correct as it's just a mere CPU emulation layer
• Using a big/popular CI provider also somewhat ensures they won't risk their reputation to tamper with the images (esp. as there are probably other images build built on their platform that would be more profitable to tamper with)
• it's possible some of the CI providers will eventually offer servers with different architecture

2. Our own dedicated build server

• The biggest advantage here is that we don't need to deal with qemu at all, and we can script building of native images
• The biggest disadvantage is that it's a black box for anyone using our images - they need to trust us completely as to whether or not the images were tempered with
• and even though our box is "bare metal", it's still someone else's computer so we need to trust them not to temper with our process
• can be scripted easier than # 3
• needs to be paid for periodically

3. Builds on our own HW device

• The biggest advantage and disadvantage are exactly the same as above
• the difference is that we don't need to trust the company hosting the device
• this option is likely also slower than the 2nd one
• likely requires manual builds every time an update to bitcoin core, lnd etc is released
• might be one of the devices we use anyway, so no extra maintenance effort nor cost is involved

Tl;dr:

1st: much easier to audit for anyone; need to use qemu; completely scriptable;
2nd: a lot of trust involved; maybe easier to script; needs maintenance; costs;
3rd: n-1 trust involved; more manual; needs no extra maintenance; no extra cost;

Note: if I did miss something please let me know, so we can get it to be more complete.

Either use some already existing image (if is sane and has multi-arch), or create a new one.

Right now lnd provides its own Dockerfile, however there are some issues with it:

1. provided Dockerfile does not specify tag/version, and always builds from master which is terrible for us if we want any sanity of debugging
2. it unnecessarily installs bash in the final stage
3. it unnecessarily clones entire repo with its history

This issue can be closed when:

• there's a new repo lncm/docker-lnd
• repo is set to have automated amd64 build on Docker Hub
• all lnd stuff is removed from lncm/dockerfiles
• arm builds are somehow addressed (either by figuring out how to skip apk add ca-certificates, so Go's native cross-platform builds can be used, or qemu, or manual RBP builds a'la bitcoind)

Change bitcoin dockerfile to include wallet support

The whole # Build and Install Berkley DB 4.8.30 block can be replaced with

./contrib/install_db4.sh $(pwd)

run from the root of bitcoin repo, it also puts berkleydb in the standard location:

bitcoin/db4/

https://github.com/djmelik/lndash

For whatever reason they have a Dockerfile, but don't push it to Docker Hub…

Perhaps we should prefix somehow images that are experimental

Self-explanatory

Please point official downloads to the appropriate repo in https://hub.docker.com/u/lncm/dashboard/

This is something to look at in the future but this will further let invoicer-ui and invoicer do its thing without both interfering with each other

This can be useful:

https://medium.com/@pierreprinetti/the-go-1-11-dockerfile-a3218319d191

Already done in lncm/docker-bitcoind.

The way it's currently envisioned is:

1. Each minor bitcoind version gets its own Dockerfile in it's own 0.X directory,
2. All bitcoind versions are build atop of lncm/berkeleydb:db-4.8.30.NC which was build through an automated pipeline (amd64 on Docker Hub, and arm using qemu on Travis),
3. amd64 image of bitcoind is build on docker hub upon tagging,
4. arm image of bitcoind is build manually on our RBP,
5. A manifest binding both together is created manually upon both builds completion,

Also, @nolim1t please take a look at https://github.com/lncm/docker-bitcoind/blob/master/0.17/Dockerfile and comment. Note that some things change, ex:

1. /home/bitcoin/.bitcoin is abandoned in favour of the default /root/.bitcoin,
2. upstream maintainers are removed
3. BDB is now an external build stage

TODO for this issue: create Docker Hub automation pipeline that builds amd64 image, so that each 0.X.Y git tag triggers a build of a Dockerfile from 0.X/ folder.

Issue can be closed after:

• build automation is added to lncm/docker-bitcoind
• bitcoind stuff is removed from dockerfiles
• at least one successful bitcoind has been deployed to lncm/bitcoind (with manifest)

Seems like copying stuff there from upstreams might not be very maintainable long term and AFAIK it's possible to override CMD calls to ex. bitcoin image (with exec or run?) in a way that removes the need for an extra image to maintain.

For reference see here: https://github.com/StefanScherer/whoami/blob/a0d189114a99df47756f41694b98cab3414e7ad6/Dockerfile#L12-L18

1. the binary is build for the correct arch
2. binary is copied to an image based on FROM scratch - beautiful!

That would make our lnd docker image basically as tiny as the lnd binaries themselves!

One benefit to doing that is that we can automate image generation upon version tag creation:

1. We change (add new minor version) Dockerfile and tag it
2. A CI tool automatically picks up that tag and
3. CI builds both amd64 and arm images
4. CI uploads all images to Docker Cloud
5. CI creates manifest
6. Everything's dandy

It should also be possible to have all images in one repo, but that might necessitate some odd and complicated setup.

cc. @AnotherDroog @nolim1t - opinions?

Hotfix for arm:
RUN ./configure CPPFLAGS="-I/usr/local/BerkeleyDB.4.8/include -O2" LDFLAGS="-L/usr/local/BerkeleyDB.4.8/lib" --with-boost-libdir=/usr/lib/arm-linux-gnueabihf --without-gui --disable-wallet --prefix=/usr/local/bitcoin --disable-tests --disable-bench

Any volunteers to make a arm6 lncm image... @meeDamian ?

May be possibly required because invoicer needs to check a few things.

Should possibly build in lnd / lncli too?

example

db:
    image: mysql:5.7.20
    healthcheck:
      test: >
        mysql \
          --host='localhost' \
          --user='${mysql_database_user}' \
          --password='${mysql_database_password}' \
          --execute='USE ${mysql_database_name}' \
      interval: ${healthcheck_interval}
      timeout: ${healthcheck_timeout}
      retries: ${healthcheck_retries}
...

We can discuss the architecture naming scheme here

Pi Zero & Pi 1 / Pi 1+
Single-core ARMv6 (32-bit)

Pi 2
Quad-core ARMv7 (32-bit)

Pi 2 v1.2
Quad-core ARMv8 (32/64-bit)

Pi 3
Quad-core ARMv8 (32/64-bit)

PC
x86_64 could be abbreviated to x64.

You can check if your OS is 32/64 bit like so:
getconf LONG_BIT