Add scripts to simplify creation of multiarch images

[wohali]

Overview

The two new scripts represent the final step in the multi-architecture journey for the CouchDB Docker images.

./build.sh includes the magic incantation necessary to build a CouchDB image on x86_64 for another platform, such as arm64v8 or ppc64le.

./build-manifest.sh builds those images for all 3 platforms CouchDB supports today.

Note: "Support" is defined by us running those machines in our CI infrastructure regularly. This is true today for arm64v8 (aka aarch64) and is about to be true for ppc64le. I feel very strongly that it is irresponsible to add another architecture to this image, or to the downstream Docker top-level couchdb image, without regular CI occurring. You can revisit that decision after I eventually leave the CouchDB project, but know that it'll be with my disappointment. ;)

Testing recommendations

On a native ppc64le or aarch64/amd64v8 platform:

docker pull apache/couchdb:2.3.1
docker run apache/couchdb:2.3.1

The images have already been tested under qemu; we don't need any more testing in that environment.

Testing with actual workloads on actual hardware would be really, really nice before a downstream PR is opened.

GitHub issue number

Closes #68
Closes #85

[wohali]

/cc @lag-linaro @sarveshtamba @rhenwood-arm

[wohali]

FYI the dev image is breaking because of apache/couchdb-fauxton#1233 and hopefully will be resolved by the time this PR is ready to land, next week sometime.

[willholley]

@wohali did you look at docker buildx at all? The main benefit to my mind is that it removes the dependency on DockerHub multi-arch conventions; any multi-arch base image can be used (UBI, for example ;) ).

An example workflow is:

1. Configure a builder:

docker buildx create --name mybuilder
docker buildx use mybuilder
docker buildx inspect --bootstrap

2. Build a multi-arch container and push to Docker Hub:

docker buildx build --platform linux/amd64,linux/arm64,linux/ppc64le -t apache/couchdb:2.3.1 --push 2.3.1

[wohali]

@willholley I did, and it didn't work for the alternate platforms. And I do have experimental enabled for both the CLI and the daemon. I wrote about my experiences in the first draft here moby/moby#36552 (comment) (view prior versions) but removed it when I realized that if you've already pulled e.g. debian:stretch for one platform locally, it won't re-pull it for another architecture, meaning you get 3x images all with the same architecture rather than 1 for each different ones. Can you test it locally?

Also I'm very unhappy about the pressure from IBM/RedHat on UBI images. CouchDB is a volunteer led project by volunteers and I'll not have it taken over by corporate interests any more than it already is with FDB.

[willholley]

@wohali testing docker buildx locally appears to work for me, but I'm not able to verify on physical hardware. What I did:

$ docker buildx build --no-cache --platform linux/amd64,linux/arm64,linux/ppc64le -t wilhol/couchdb-multi:2.3.1 2.3.1 --push
...(build output - I observe platform-specific packages being installed in each log)

$ docker manifest inspect wilhol/couchdb-multi:2.3.1
{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 2614,
         "digest": "sha256:d29c130a0fff5b76663915513623605f0bba27ccb6a758669f858d0b1037bd41",
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 2614,
         "digest": "sha256:22d08e967e1caa6d3f717e40aa8255be1985f7408abdfd640a258888685b7b39",
         "platform": {
            "architecture": "arm64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 2614,
         "digest": "sha256:5bdd4f9d8eb7a572c22822b1d08c986882e16fa5d4b29433d9adfbe7ad8e3f6a",
         "platform": {
            "architecture": "ppc64le",
            "os": "linux"
         }
      }
   ]
}

$ docker run --rm wilhol/couchdb-multi:2.3.1@sha256:d29c130a0fff5b76663915513623605f0bba27ccb6a758669f858d0b1037bd41 uname -m
x86_64

$ docker run --rm wilhol/couchdb-multi:2.3.1@sha256:22d08e967e1caa6d3f717e40aa8255be1985f7408abdfd640a258888685b7b39 uname -m
aarch64

$ docker run --rm wilhol/couchdb-multi:2.3.1@sha256:5bdd4f9d8eb7a572c22822b1d08c986882e16fa5d4b29433d9adfbe7ad8e3f6a uname -m
ppc64le

$ docker run wilhol/couchdb-multi:2.3.1@sha256:5bdd4f9d8eb7a572c22822b1d08c986882e16fa5d4b29433d9adfbe7ad8e3f6a
...(CouchDB starts)...

I'm sorry you feel IBM is putting pressure on the project to support UBI images - that's certainly not the intention. Given it's a contentious issue, let's remove the UBI containers from this repository for now and IBM can maintain them independently.

[wohali]

The UBI Dockerfile can live here...the issue is that it feels like we're being pressured to make those images the default, or that in the future all the effort I've put into binary packaging for other platforms will be thrown out for that Docker container. Let's discuss this offline.

I'll look into the buildx stuff in a separate issue, and taking the +1 to merge this for now.

[wohali]

And, of course, I can't get this merged until:

1. We have testing on the other architecture containers, ideally on real ppc64le or arm64v8 hw
2. The fauxton fix is merged.

[willholley]

Fauxton fix is merged (apache/couchdb#2257). I'll see whether I can get hold of a ppc64le machine to run some tests.

[wohali]

OK, I've solved the buildx problem, it seems that for whatever reason locally I have to reinstall the multiarch/qemu-user-static after each reboot. Strange.

I'll enhance the PR with that change and push it. Thanks for the tip, @willholley

[wohali]

Walking this one back...that doesn't work unless you need to push, since manifests don't exist locally. I'm going to "yes, and" this and provide both approaches, depending on whether you want to build locally (and test), or just build-and-push in one go.

Jumped on an issue in buildx to highlight this use case: docker/buildx#166 (comment)