Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Ideas] Apple Silicon (ARM64) Docker bitfmt support in Whalebrew #138

Open
andrewcrook opened this issue Jun 14, 2021 · 5 comments
Open

Comments

@andrewcrook
Copy link

andrewcrook commented Jun 14, 2021

As you may know Docker Desktop for Mac for Apple Silicon allows you to run x86/x86_64/amd64 via its inbuilt emulation
I believe Docker calls this bitfmt and originated in buildx but is now in mainstream.

To pull a particular platform version of an image you can use an switch in the docker file
FROM --platform linux/amd64 <image name>

It is also possible to do the same on Intel Macs, Linux and Windows to run Linux ARM64 code
[Windows Docker also has the added feature of Windows containers but I don't know much about that it is currently outside my scope of usage but I can see good to have .]

My 2 cents

So the concept for me would to be able to run Linux tools and tools yet to have ARM64 support and their dependencies on Apple Silicon in a Docker container integrated into Darwin almost seamlessly. e.g Pandoc , TeX , development environments etc

Also a user might want to use specific platform version or specific version.

So my proposal would be to first have a mechanism to list platforms available
then to have an argument, config dot file and/or environment variable to select which platform to install.
I don't now the best way to do this

  1. have multiple Dockerfiles with different FROM lines (--platform) and have the platform in the package name possibly?

2 The other idea, more complex , to have each package have a meta file or comments in the dockerfile to parse showing the different platforms and versions available then have whalebrew alter the docker file or Dockerfile template FROM lines (--platform) automatically before building the image. If you use the meta file idea you can add descriptions and info as well which can be used by the client and be extended for new features in the future.

@tjamet
Copy link
Contributor

tjamet commented Sep 7, 2021

Hi! sorry about the late reply

This is indeed a good idea to support apple silicon.
I personally don't have one, but I tend to think there are 2 sides to the problem:

  1. building whalebrew for it (this should now be easy with latest go versions)
  2. making packages compatible. For this, I don't know exactly what is required. Is docker always x86 emulated?

@tjamet
Copy link
Contributor

tjamet commented Feb 7, 2022

Hi!
I have added the support to build mac arm64 binary here: https://github.com/whalebrew/whalebrew/actions/runs/1809369861
soon I will release a new version

@glensc
Copy link

glensc commented Feb 27, 2022

binfmt not bitfmt, and it's linux kernel thing:

@andrewcrook
Copy link
Author

@glensc

I don't think it’s the same thing I would have put the ‘_misc’, but does emulate that functionality and yes that was a typo 🫢

https://github.com/tonistiigi/binfmt

I think its this image used by buildkit which is a bundle of qemu emulators for different platforms.
It can be used by BuildKit to to run and more importantly build multiple images for different platforms.

While Docker Desktop comes preconfigured with binfmt_misc support for additional platforms, for other installations it likely needs to be installed using [tonistiigi/binfmt](https://github.com/tonistiigi/binfmt) image.

@andrewcrook
Copy link
Author

@tjamet

making packages compatible. For this, I don't know exactly what is required. Is docker always x86 emulated?

Docker for macOS M1 already packs QEMU with AMD64 support.
I presume, the Intel version comes with ARM64 support?
That would make sense with the move to Apple Silicon
via docker hub, it will always try to use the native version to your platform first. I am not sure if it would automatically fallback to the emulated version or if you would have to provide the platform argument.

If a system isnt supported by emulation or otherwise you have to install binfmt image , as mentiond
$ docker run --privileged --rm tonistiigi/binfmt --install all

I don't think that this will be needed though. Unless you plan to build for and run a lot more platforms.

video demo here: https://youtu.be/hWSHtHasJUI?t=268

So I think would mean you could upload the various platforms as the one named item to docker hub and docker would automatically download the native version if possible unless over ruled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants