Support ARM64 containers / images

[Chuxel]

UPDATE - Images previously built out of this repository are now at https://github.com/devcontainers/images

Please raise issues there. Jammy and Bullseye images now exist and are broadly supported. We have no plans for arm64 support for Focal or Buster image nor other distros like centos:8 that experience random crashing. See here for details.

---- ORIGINAL TEXT ---

Currently the definitions in this repository are x86_64 based. Some scripts will likely need to be modified to support ARM64. In addition, pre-built definitions will need to be compiled for ARM64 after this has been done.

---

UPDATE

Images listed below should now all be released with arm64 variations (you can now omit the dev prefix and use 0- or another sub-version as you see fit). UX in the Add Dev Container Configuration Files command in VS Code will be getting updated incrementally in Remote - Containers and Codespaces to list -bullseye variants with amd64/Apple Silicon support (along with other variants where possible for backwards compatibility).

To update existing dev container configuration files from this repository, you can append -bullseye to the VARIANT argument. For many configuration, this will be in devcontainer.json. For example, for Python:

"build": {
    "dockerfile": "Dockerfile",
    "args": {
        "VARIANT": "3-bullseye"
    }
}

Cases where the VARIANT argument is in docker-compose.yaml are similar. For example, for Python 3 & Postgres:

#...
    build:
      dockerfile: Dockerfile
      args:
        VARIANT: 3-bullseye
#...

We have also updated mcr.microsoft.com/vscode/devcontainers/base:alpine and related tags now that Remote - Containers supports Alpine arm64 as of the release of VS Code 1.61.

After the C#/.NET extension added support for ARM, arm support for the dotnet images's bullseye variations have ARM64 support starting with version 0.203.0 of the .NET images (e.g. mcr.microsoft.com/vscode/devcontainers/dotnet:0.203.0-6.0-bullseye) in release v0.224.0.

[gfmatthews]

Hey y'all - I have a Surface Pro X and am interested in helping to get some of these containers supported on the ARM64 platform. I've seen that javascript-node builds correctly without modification already for ARM64 so for that container, the only thing missing is getting the pre-built containers updated.

Is there a build pipeline or something similar somewhere that can be used to test this out? Happy to reach out internally (@microsoft) if that would be helpful.

[jasonsummers]

Hi all, new to GitHub - apologies in advance for breaches of etiquette, please correct any mistakes I make.

I'm keen to help make progress in on this issue and plan to look at how multi-arch images can be used as well as cleaning up / automating debugging linux on ARM. As a temporary solution I've managed to get a working .net core devcontainer working by building from the arm64 sdk image and using the scripts from this repo.

If work is already in progress on resolving this issue, please let me know if and how I can be of help.

[philliphoff]

I've run into a qemu issue when building upon one of the base amd64 images with a new M1 Mac (for testing our Docker tooling on the new platform). It would be great to have arm64 images to test.

[tkreindler]

I'm on an Apple M1 and although I totally understand this is beta and low priority, it would seem as simple as building and publishing an aarch64 container for each dev environment.

I got the dotnet devcontainer to work perfectly locally in docker simply by changing
FROM mcr.microsoft.com/dotnet/sdk:5.0-focal
to
FROM mcr.microsoft.com/dotnet/sdk:5.0-buster-slim-arm64v8
in the parent dockerfile.

[jroes]

I've been hacking around with things to get my m1 mac going and I've had a little success. Here's a recent Dockerfile I put together in case it's helpful to anyone. It's pretty ugly and I'm sure could be done better, but it seems to work okay so far for now!

I imagine this is the path to officially supporting such things here in this repo: https://docs.docker.com/docker-for-mac/multi-arch/

[chrmarti]

@Chuxel Maybe we should introduce an automatic build arg in Remote-Containers for the architecture that can be appended to the image name in FROM to avoid duplication?

[jamesthurley]

Would the eventual solution be likely to use multi-arch container builds? It feels like the aim should be to open the same repository on either an x86 or ARM machine without (either automatically or manually) modifying any configuration files.

[chrmarti]

@jamesthurley Thanks for pointing this out. That looks like it might be the preferred solution.

[Chuxel]

@chrmarti Yeah we'll need some sort of architecture arg because of external feeds and curl'd tools. The build scripts need to be architecture aware. I'd added the idea of an env file in a sample Go implementation along with autodetection in an exploration here. The architecture needs to be translated into the appropriate format for the URI/packaging system which isn't consistent.