Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tech Preview of Docker Desktop for M1

docker.com

Post reply on HN
Print view View original

141–150 of 231 posts

Re: Tech Preview of Docker Desktop for M1

#141

Post by wyldfire »

wmf wrote: post #132
mbreese wrote: post #131

After reading the article, I still don't quite understand how this works. I've used multi-platform Docker containers before, and that makes sense to me. What I don't understand is how they are running x86 containers on an ARM64 VM? Docker Desktop still works by building a Linux VM and running Docker there. But the VM would be an ARM VM. So, are they running qemu in the ARM VM to emulate an x86 processor in a nested V…

QEMU can (slowly) emulate any architecture on any other architecture. In this case, they're using QEMU to emulate x86-64 on ARM64. No nesting or Rosetta is needed.

I don't think that there's a TCG backend for all of the architectures in the frontend. So it's probably not quite any-on-any.

Re: Tech Preview of Docker Desktop for M1

#142

Post by dwaite »

wmf wrote: post #136
orf wrote: post #133

Earlier quoted context omitted.

Why wouldn’t they use Rosetta though? I’d wager the performance of Rosetta would be better than QEMU emulation, but perhaps it’s more optimised for desktop apps

Rosetta is limited to running Darwin/x86-64 user processes on Darwin/ARM64 but Docker needs to run Linux/x86-64 containers/processes on a Linux/x86-64 kernel on a Darwin/ARM64 host.

In addition, the CPU settings to have the high performance cores do TSO memory management are not supported under the hyper visor/virtualization layers.

Re: Tech Preview of Docker Desktop for M1

#143

Post by mbreese »

wmf wrote: post #136
orf wrote: post #133

Earlier quoted context omitted.

Why wouldn’t they use Rosetta though? I’d wager the performance of Rosetta would be better than QEMU emulation, but perhaps it’s more optimised for desktop apps

Rosetta is limited to running Darwin/x86-64 user processes on Darwin/ARM64 but Docker needs to run Linux/x86-64 containers/processes on a Linux/x86-64 kernel on a Darwin/ARM64 host.

I think the parent comment meant -- why not use Rosetta to run an x86 qemu process? Then the architecture emulation (translation?) would be done by Rosetta (potentially faster), as opposed to software emulation by qemu.

Now, this might not work, as I'm not sure Rosetta covers all of the x86 instructions/settings that qemu would need, so you might be stuck with ARM64 qemu emulating x86 anyway.

Re: Tech Preview of Docker Desktop for M1

#144

Post by nhoughto »

mulcahey wrote: post #55

Perhaps a dumb question but I'm curious why people don't use a VPS or a cloud linux machine more for Docker/K8s development instead of running Docker locally on a Mac. In my experience Docker Desktop has been such a resource hog, and Apple's hypervisor implementation pretty poor. I much prefer to have all that heavy lifting isolated away from my development machine to keep it responsive and cool.

feedback loop is longer, if my workflow is:

make change -> compile -> build image -> deploy to k8s

then running docker/k8s remotely would be great but i need great upload bandwidth to be pushing fresh images everytime I make a change. In theory docker layers/caching should fix this but the reality is that you don't add individual files to an image, you had the compiled artifact/bundle/whatevs and if any file changes its going to upload it again, made worse by a change that effects many components/images/k8s pods. If you can solve the upload bandwidth problem (local servers? giant pipe?) then becomes more possible.

Re: Tech Preview of Docker Desktop for M1

#145

Post by vocram »

mbreese wrote: post #140
wmf wrote: post #132

Earlier quoted context omitted.

QEMU can (slowly) emulate any architecture on any other architecture. In this case, they're using QEMU to emulate x86-64 on ARM64. No nesting or Rosetta is needed.

But if they are doing that, then why do they need to use the Mac Hypervisor Framework to setup the VM? That wouldn't be required if you were using qemu, would it? (How you mention it would be the simplest possible thing that would work)

A Linux VM is still needed because these are Linux containers, ie. they need namespaces, cgroups, layered rootfs, etc.

Re: Tech Preview of Docker Desktop for M1

#146

Post by tonyhb »

jeppesen-io wrote: post #27

Wow, that was fast. I was expecting to wait unil January. Key takeaway for me is the ability to run/build both x86 and Arm images on a M1. Can't see any reason M1s can't be used for everyone at my work now. Very nice.

Docker have had inside access to the whole M1 release since before it was announced. This is incredibly slow.

Re: Tech Preview of Docker Desktop for M1

#147

Post by vocram »

gmaster1440 wrote: post #57

I've tried one of the preview builds as part of their Developer Preview Program[1] and it's super fast when you're running an arm64 image, as opposed to an amd64 that will automatically be run via qemu (and therefore incur some overhead). By "super fast", I mean I was seeing speeds comparable to running the commands natively on the M1 mac (npm install and a heavy Gulp build). [1] - https://www.docker.com/community/ge…

Are users able to check if they are running a native arm64 container image, as opposed to an amd64 emulated one?

Or that’s something you have to infer from the execution speed?

Re: Tech Preview of Docker Desktop for M1

#148

Post by xyst »

As much as the m1 processors are praised, I won't upgrade from my intel mac until apple fixes their OS (by default the m1 Macs will have Big Sur).

There's still no word on whether or not apple applications still have exceptions from being filtered by the new network apis.

I usually upgrade after the second or third minor patch, but im going to be holding out.

Re: Tech Preview of Docker Desktop for M1

#149

Post by klelatti »

pjmlp wrote: post #129
cogman10 wrote: post #112

Earlier quoted context omitted.

I don't disagree. In fact, I'm assuming that's a major reason they've not done this sooner. Intel tried to setup a different more efficient architecture with IA64, but they failed there. That being said, with major players like Amazon and Google tinkering with ARM in the cloud and Apple getting ARM into the hands of a lot of developers, we could be on the eve of seeing ARM make a big entrance into the server realm. I…

That reason doesn't make any sense to me. I have been coding since the mid-80's, not having the same local UNIX machine for doing development than what the server was running was quite common in the world of commercial UNIXes. Then I moved into managed languages, where the actual CPU and even underlying OS, only matter to low level coding, again not using the same local OS/CPU combo as the server. Finally, cross comp…

Agreed that lack of desktop Arm wasn't the biggest issue. Arm didn't take off because:

- Intel had process leadership and x86 was 'good enough' - Process leadership was in turn supported by the volumes / margins that Intel had on their consumer PC business.

But now Intel has lost process leadership partly due to smartphone volumes supporting huge investment at TSMC / Samsung and the hyperscalers have an incentive to differentiate their offerings (e.g. Amazon Graviton).

Re: Tech Preview of Docker Desktop for M1

#150

Post by gmaster1440 »

vocram wrote: post #147
gmaster1440 wrote: post #57

I've tried one of the preview builds as part of their Developer Preview Program[1] and it's super fast when you're running an arm64 image, as opposed to an amd64 that will automatically be run via qemu (and therefore incur some overhead). By "super fast", I mean I was seeing speeds comparable to running the commands natively on the M1 mac (npm install and a heavy Gulp build). [1] - https://www.docker.com/community/ge…

Are users able to check if they are running a native arm64 container image, as opposed to an amd64 emulated one? Or that’s something you have to infer from the execution speed?

You can use manifest inspect[1] to see all supported architectures, and you should also be able to see on Docker Hub[2] as well.

EDIT: If you're asking specifically if you can tell what architecture a running container is using, a simple `docker inspect CONTAINER_ID` should show it.

[1] https://docs.docker.com/engine/reference/commandline/manifes... [2] https://hub.docker.com/_/node

Post reply on HN