Update build scripts to use "docker buildx build"

[Chuxel]

As a part of the work to enable ARM64 for images, we'll need to switch the build system to use buildx instead of the default docker build. e.g.

docker buildx create --use --name multiarch
docker run --privileged --rm tonistiigi/binfmt --install all
docker buildx build .devcontainer -f .devcontainer/base.Dockerfile --platform linux/amd64,linux/arm64

[Chuxel]

The branch https://github.com/microsoft/vscode-dev-containers/tree/clantz/mutli-arch-build has a working version of the build, but buildx is reporting a native crash in a simple curl call (likely tied to something QEMU and openSSL) when trying to execute the build in GitHub Actions or emulated. This is blocking merge.

[imakahn]

Hi @Chuxel

I was working through the node-debian.sh script and also experienced the segfault on the curl call to fetch the yarn gpg file. The issue has been detailed here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989604

A immediate workaround would be to use wget, as such:

wget https://dl.yarnpkg.com/debian/pubkey.gpg -O /tmp/pubkey.gpg
cat /tmp/pubkey.gpg | gpg --dearmor > /usr/share/keyrings/yarn-archive-keyring.gpg

However this would still leave the global curl being shipped as broken for some https urls.

So to instead resolve that (and leave the curl call unchanged):

wget https://cloudfront.debian.net/debian/pool/main/o/openssl/libssl1.1_1.1.1k-1_arm64.deb -O /tmp/libssl1.1_1.1.1k-1_arm64.deb
sudo dpkg -i /tmp/libssl1.1_1.1.1k-1_arm64.deb

I hope this helps!

[Chuxel]

@imakahn Thanks for the tip! Yeah, beyond curl, its libssl itself that is broken, so I saw a number of issues. This one was just the really obvious one. I'm a bit wary to bring in testing bits into stable. I'd expect this will get pulled into stable (soon to be old-stable), but there's a lot of focus on bullseye right now.

[Dids]

Have there been any updates with this?

So far I've been creating my own images/forks of the definitions available in this repo, as well as replacing all curl calls with wget, to get rid of the QEMU crashes when doing multi-arch builds.

While this has worked fine, it's rather cumbersome to have to maintain forks/custom images, so I'd very much love to see this implemented as soon as possible, as well as platform selection in build scripts for images that have been tested against multiple architectures.

I'm definitely open and happy to help with this any way I can, as devcontainers are an extremely powerful tool for my workflows, as well as my client's.

---

On a likely unrelated note, when I was testing and building ARM64 images on my M1 MBP running macOS Monterey, I noticed that port 80 was being blocked for inbound traffic, which only happens on this device/OS configuration. macOS Monterey does include multiple networl related changes, but this particular issue isn't mentioned anywhere, at least that I could find.
This caused all apt repositories to fail to connect, which I could reproduce locally in all 3rd party browsers, except in Safari, which works as expected.
Simply switching all apt repositories from HTTP to HTTPS was enough to fix this, and I've yet to confirm from any official sources of macOS Monterey is the culprit here, but as of right now it seems plausible.

[Chuxel]

As mentioned in the other thread, things like SDKMAN are affected as well, so just switching to wget doesn't resolve the problem.

[Chuxel]

This part has been merged. Additional tracking of images using it will be tracked under #558.

[bourquep]

@Chuxel I have a Dockerfile-based devcontainer, whose FROM image is multi-arch and which can build properly with buildx.

But when I "build and open in devcontainer", the image is built for amd64 only, not multiarch. How can I tell vscode to use buildx --platform ...?

[eitsupi]

@bourquep I recommend reading the buildx documentation. It is not possible to load multiplatform images into local Docker.

https://github.com/docker/buildx/blob/master/docs/reference/buildx_build.md#load

The docker export type writes the single-platform result image as a Docker image specification tarball on the client.

[Chuxel]

@bourquep Docker will use your local architecture by default unless the upstream image does not support arm64.

If you want to force emulation, you can set the DOCKER_DEFAULT_PLATFORM environment variable when starting VS Code.