Support building multi-platform images and add linux/arm64

[victorlin]

Description of proposed changes

Currently, the Docker images are built for linux/amd64 only. These changes build the Docker images for both linux/amd64 and linux/arm64.

This will substantially improve the performance of the Docker runtime for Apple silicon users, as it no longer needs to use slow Intel architecture emulation. A major drawback is the increased build time since building the linux/arm64 image on a linux/amd64 GitHub Actions runner requires emulation. However, IMO the benefit to users outweighs the increased build-time on our end, which can be improved in the future.

Cross-compilation (#98) is a major build-time improvement on top of this PR to be considered separately.

Changes made outside of PR

• Added docker/setup-qemu-action@* to allowed third party actions under @nextstrain

Related issue(s)

• Resolves Build multi-arch image with amd64 + arm64 for M1 Macs #35
• Supercedes/closes Add arm64 to image builds #48

Testing

• Checks pass
• Multi-arch images for the PR branch are available on Docker Hub for nextstrain/base and nextstrain/base-builder
• Run zika-tutorial on linux/arm64 image "natively" using M1 Mac (54s run time)
• Run zika-tutorial on linux/amd64 image natively using Linux on GitHub Codespace (50s run time)
• Run ncov-tutorial on linux/arm64 image "natively" using M1 Mac (2m 23s run time)
• Run ncov-tutorial on linux/amd64 image natively using Linux on GitHub Codespace (3m 6s run time)
• test linux/arm64 image without emulation (all my M1 Macs have Rosetta enabled, and it isn't easy to disable. Not doing this since this feature is targeted towards other Apple silicon users which should also have Rosetta enabled.

Summary of comment threads

• Local registry? (ref)
• Self-hosted runners to avoid emulation slowdowns? (ref)
• Cross-compilation? (ref)
• Emulation of pre-built binaries (ref)
• Compiling/runtime issues in arm64 build
  • RAxML (ref)
  • matplotlib (ref)
  • Nextclade (ref)
  • cvxopt (ref)

[victorlin]

Comparing to the failure in #48 (using build-push-action), which points to:

docker-base/Dockerfile

Line 39 in 163cba5

RUN make -f Makefile.AVX.PTHREADS.gcc # AVX should be widely-supported enough

and makes sense: #48 (comment)

The failure in this PR (using docker buildx build) is different:

error: failed to solve: process "/dev/.buildkit_qemu_emulator /bin/bash -c apt-get update && apt-get install …

Not sure what's the reason for the discrepancy This was before adding 63118ea.

[victorlin]

Made some progress today. Will investigate more another day.

[tsibley]

\o/ nicely done. I've read thru all the latest commits again and it looks great. One small typo fix and a bunch of non-blocking comments (though I do think some of thing should be addressed).

[victorlin]

Planning to merge after CI passes and I successfully re-run through manual testing with the updated test image.

[victorlin]

Update: the push-triggered CI failed on the build job with a seemingly transient network error. It's been >3 hours and still running. PR-triggered CI took >4 hours on ./devel/build. Looking at the raw logs, the long build times seem related to #115 (a few notable lines with timestamps pasted below):

2022-12-15T21:22:55.0645526Z #104 [linux/arm64 builder 44/47] RUN /builder-scripts/download-repo https://github.com/nextstrain/auspice release .  && npm update && npm install && npm run build && npm link
2022-12-15T21:51:04.8952185Z #104 1689.9 added 1528 packages, and audited 1529 packages in 28m
2022-12-15T21:55:10.3682075Z #104 1935.4 > node auspice.js build --verbose
2022-12-15T22:55:13.8493368Z #104 5538.7 changed 1 package, and audited 1529 packages in 1h
2022-12-15T22:55:39.0958178Z #104 5564.0 > node auspice.js build --verbose
2022-12-16T00:48:18.3439466Z #104 12323.4 added 1 package, and audited 3 packages in 58m
2022-12-16T00:48:18.8022211Z #104 DONE 12323.7s

I believe this is because Node.js 14 only came in amd64 flavors and thus somehow ran "natively" on the build platform, even with the implicit --platform=$TARGETPLATFORM. Now with Node.js 16 (which supports arm64 flavors), it is running with emulation which is much slower.

My opinions:

• 1 hour to build is somewhat acceptable, but 4 hours is not.
• There may be a slight runtime improvement with Node.js 14 → 16, but not enough to justify the drawbacks of increased build time.
• This Node.js upgrade is more fit to come alongside #98.

Based on the above points, my planned approach:

1. Revert back to Node.js 14 in this PR for an acceptable build time.
2. Confirm that upgrading to Node.js 16 works in #98 without negatively impacting build time.
3. Merge this PR.
4. The Node.js 16 upgrade will happen with merge of #98.

[tsibley]

@victorlin Sounds like a good plan. From the log snippet, it seems we're running

node auspice.js build --verbose

twice? Once as part of npm install (since the prepare lifecycle script in package.json is npm run build) and once explicitly as npm run build in our Dockerfile RUN line. We can drop the latter then, right?

[victorlin]

@tsibley that sounds right! I'll do it in a separate PR: #120