5 ms·

Soooo does this mean that Docker will suck less on macOS, Real Soon Now?

• saagarjha 4y ago
  This can't boot x86-64 containers, but you can create an arm64 container and run x86-64 code in it.
  • duskwuff 4y ago
    I have to admit to a little bit of trepidation about the Rosetta mount point. Will this work for Docker without explicitly passing that mount point through to the containers?
    • saagarjha 4y ago
      Yeah I'm not entirely sure how they're going to make this work, but I kind of understand why it's so weird, because there's really not any very good way to communicate between macOS userspace and some arbitrary kernel running inside the VM…
    • cpuguy83 4y ago
      The way this would work is Docker would be setting this up for you (maybe through some option to switch between qemu and Rosetta). The containers should not need the mount. What happens is Rosetta gets registered with the kernel (binfmt_misc) to execute x86 binaries. The is the same mechanism that allows seamless qemu support.
  • WatchDog 4y ago
    Docker on macOS already has some kind of qemu based solution for running x86_64 containers on m1. Potentially this could be used as an alternative?
    • zamalek 4y ago
      It's QEMU emulation. It's slow. It also segfaults a lot. I am able to run a select few containers on it, but I needed to sort out native arm64 for the vast majority.
      • zekica 4y ago
        The main reason for segfaults is that not all syscalls (syscalls on linux are different per architecture - not even 32bit and 64bit x86 use the same) are implemented in a 100% compatible way.
    • zekica 4y ago
      Yes, this is exactly what Apple has done - created Rosetta that handles Linux ELF binaries, translates code and syscalls.
    • mxey 4y ago
      Yes, Docker on macOS can switch from qemu-user to this. It uses the same binfmt mechanism, so it should be mostly a drop-in replacement. This is only available in combination with Virtualization.framework, but Docker is already migrating from Hypervisor.framework to Virtualization.framework.
  • akdor1154 4y ago
    I don't think that's right - containers are just userspace code, nothing to boot. By my reading of TFA, your container runtime (eg Docker for Mac) should be able to provide an ARM VM, and use this Rosetta feature to run amd64 containers directly.
    • cromka 4y ago
      Containers that you and everyone else think of use Linux distros as a base, so yeah, anything else than Linux actually had to boot a VM to use them. That’s what eg Docker does on macOS.
  • mhio 4y ago
    Why does the rosetta binfmt_misc setup exclude starting amd64 containers? It's the same functionality the Docker desktop arm64 VM currently uses to run the process for an amd64 container via qemu (or any non arm64 container).
• samwillis 4y ago
  I believe the main issue is file syncing between macOS and the container host OS. I don’t have a M1 mac, but on my Mac a standard Linux VM has no impact on performance or battery life. The minute I use Docker the machine become sluggish and halves (literally) the batter life, I now avoids is as much as possible.
  • laurencerowe 4y ago
    Have you tried enabling "Use the new virtualization framework" in experimental features? This removed the background CPU usage for me.
  • zamalek 4y ago
    Try out Colima with the experimental 9p mount type. Network performance is improving. It's as good as it will likely get on the platform.
  • eckza 4y ago
    I have a M1 Macbook Pro with 16 GB RAM, and qemu ballons in RAM when I try to stand up our backend microservice stack locally - it uses RAM until there's none left, and falls over. My teammates running Linux report ~30mb of RAM usage by the Docker processes to run the same containers.
  • dmt0 4y ago
    Vagrant solved most of my problems. Docker Desktop was unusable to me as well.