Support ARM64 containers / images #558
Comments
|
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. |
|
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. |
|
I've run into a |
|
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 |
|
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/ |
|
@Chuxel Maybe we should introduce an automatic build arg in Remote-Containers for the architecture that can be appended to the image name in |
|
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. |
|
@jamesthurley Thanks for pointing this out. That looks like it might be the preferred solution. |
|
@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. |
|
Seriously, I'd love to have |
|
Recently purchased an M1 mac for dev purposes, and only use dev containers for all of my projects. Unfortunately, it's an expensive paperweight at the moment as the containers are fairly unusable (poor performance, constant disconnects), so I'd love to help test this out. I have the base model M1 Mac Mini.
These are the images I use currently:
|
|
A number of us are working to get our hands on M1 macs but they're quite backlogged - we're hearing months to get our hands on them. That said, there is a branch that has versions of the scripts in the script-library folder that support arm64 (and in some cases armhf). Right now I'm seeing a seg fault in curl when using buildx in a couple spots that is blocking merge. From there we can get the CI system set up to do automated image generation as described in #914. |
|
Script updates have been merged and there's a branch that supports the build system updates. However, buildx is reporting a native crash in a simple |
|
Anyone have an example of a good enough image to use for container development that is arm native? |
|
Bullseye is very new, but in concept this problem that has been blocking us should be resolved there. However, many images have not moved their defaults yet. (E.g. The A hack that unblocks RUN . /etc/os-release \
&& if [ "${VERSION_CODENAME}" = "buster" ]; then \
apt-get update && apt-get -y install wget \
&& 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 \
&& dpkg -i /tmp/libssl1.1_1.1.1k-1_arm64.deb; \
fiUpdate: This issue repros on both physical mac M1 hardware with Docker Desktop and cross-compiling using |
|
The primary reason for this feature request has been M1 Macs. With Docker Desktop not working with Debian Upstream images that have switched to bullseye by default, should add buster variants for back compat:
Default not updated, so add bullseye variant, but pin to buster:
Uses Ubuntu 20.04/focal:
We will leave the codespaces-linux image as is and stay with x86_64 support since its primary use case is in the cloud (on x86 hardware) and the upstream Oryx image is also x86_64 and switching off of Ubuntu focal would affect quite a bit. |
|
There are now development builds of the following images with arm64/aarch64 support that can be tested. We will update this list as new image builds are available: Base images
Node
Python
PHP
.NET
Go
Ruby, Jekyll
Java
Rust
C++
|
Shouldn't these Python images be |
|
@fdanielsen Yes, thanks - corrected. |
Great, thanks. I assume once these pass development stage all new builds of these devcontainers will be multi arch with arm64 support, eg. the |
|
@fdanielsen For a given image, type
The |
|
Images listed above should now all be released so you can now omit the For images like Locking this issue so this note remains easily visible to people new to the discussion. Please open up new issues if you run into problems. UPDATE .NET Bullseye images are available and arm64 support is in the extension, so this is also resolved. |
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
devprefix and use0-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-bullseyevariants 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
-bullseyeto theVARIANTargument. For many configuration, this will be in devcontainer.json. For example, for Python:Cases where the VARIANT argument is in docker-compose.yaml are similar. For example, for Python 3 & Postgres:
We have also updated
mcr.microsoft.com/vscode/devcontainers/base:alpineand 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
dotnetimages'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.The text was updated successfully, but these errors were encountered: