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

151–160 of 231 posts

Re: Tech Preview of Docker Desktop for M1

#151

Post by ogre_codes »

cogman10 wrote: post #138
pjmlp wrote: post #129

Earlier quoted context omitted.

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…

> 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. Things change. Why is x86 the primary server platform? It isn't a great micro architecture. The fact that ARM and others (Like power pc) have been eating their lunch in terms of price, performance, and power consumption is proof enou…

I know your question is rhetorical, but worth addressing because it's relevant.

> Why is x86 the primary server platform?

Cheap PC prices plus Linux meant you could deploy Linux for a fraction of what deploying any other Unix (save the *BSD family which shares similar advantages).

Cheap ARM CPUs and reasonably priced, performant ARM development machines pretty much harpoons that big advantage x86 had.

> The issue is that there are always differences that are hard to compare when switching platforms if the one you are developing on isn't the same as the one you are targeting.

Yes and no. We've been developing on MacOS and deploying to Linux for some time. The issues we end up fighting are minimal and we're going from one OS to another. I suspect most of the ARM-x86 issues that haven't already cropped up and been dealt with will be soon.

Re: Tech Preview of Docker Desktop for M1

#152

Post by duskwuff »

mbreese wrote: post #143
wmf wrote: post #136

Earlier quoted context omitted.

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.

Efficient use of qemu on x86 requires the Hypervisor framework, which isn't available under Rosetta.

It's possible to run qemu without Hypervisor.framework, but that means it's doing its own second layer of translation. This would be horribly inefficient under Rosetta.

Re: Tech Preview of Docker Desktop for M1

#153

Post by thescriptkiddie »

mbreese wrote: post #143
wmf wrote: post #136

Earlier quoted context omitted.

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.

Qemu is only able to achieve native performance when running in conjunction with a hypervisor like KVM. Hypervisors don't do binary translation, so the guest architecture needs to match the host architecture. Running x86_64 qemu under rosetta would likely be much slower than running aarch64 qemu, because it would be running an emulator inside of an emulator.

Re: Tech Preview of Docker Desktop for M1

#154

Post by ytch »

orf wrote: post #133
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.

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 2 doesn't support x86 hypervisor:

https://developer.apple.com/documentation/apple_silicon/abou...

> What Can't Be Translated?: Virtual Machine apps that virtualize x86_64 computer platforms

Re: Tech Preview of Docker Desktop for M1

#155

Post by TimTheTinker »

mulcahey wrote: post #81
ogre_codes wrote: post #72

Earlier quoted context omitted.

If you have multiple developers working on the same product, you want each developer to have their own environment. In my experience, for cost, convenience, and productivity its made most sense to do this with local Docker. It also eliminates a lot of connectivity issues with running on a remote machine. > In my experience Docker Desktop has been such a resource hog Not sure if this is related to the specific project…

Here is an example thread of many users experiencing resource utilization issues with various root causes: https://github.com/docker/for-mac/issues/3499 Some root causes have been addressed. If they are significantly changing the architecture with the Apple Silicon rollout, I'm very much looking forward to see if that improves things!

Docker for Mac is a really bad resource hog for devs at my company. It's a common refrain that comes up again and again.

We build a SaaS web app with a MERN stack deployed to AWS. Local development usually involves running about 12 containers.

Personally, I got fed up and installed Ubuntu 20.04 in Parallels and have been running the Docker containers there for several months. What a night and day difference... the entire VM sits at about 13% CPU when idling, whereas Docker for Mac would whine my fans at around 150% CPU continuously when idling, and spike up to 300+% when clicking around the app.

Re: Tech Preview of Docker Desktop for M1

#156

Post by GGfpc »

ploxiln wrote: post #51
outworlder wrote: post #37

Earlier quoted context omitted.

> Docker on Mac has never felt as snappy as on Linux It's extremely slow compared to Linux and I'm pointing my fingers at the virtualization layer without any hard evidence because it's the most likely suspect. With all this focus on sandboxing apps of late, I'm wondering how far the OSX kernel is from having a feature set that resembles cgroups and network namespaces.

I used docker inside a vagrant+virtualbox VM running ubuntu, on macOS, for a few years. It's more reliable, and more debuggable, than docker for mac. It's some easy-auto-transparent storage and networking layers that make docker-for-mac so flaky.

So you have your setup documented anywhere?

Re: Tech Preview of Docker Desktop for M1

#157

Post by jacques_chester »

cogman10 wrote: post #112
ogre_codes wrote: post #102

Earlier quoted context omitted.

Intel's fat margins are largely based on their duopoly on x86. With ARM, it's far more competitive and margins are far lower. With Nvidia owning ARM, it seems likely we'll see more ARM CPUs from them. Samsung, Qualcomm, and Mediatech also have ARM CPUs all the way down to a few dollars per CPU. Intel isn't going to be able to come in and charge $50-500+ unit the way they do with their x86 chips. Unless Intel can rebo…

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…

> Intel tried to setup a different more efficient architecture with IA64, but they failed there.

A big part of the IA64 strategy was to thoroughly mine the area with patents. They were held in a company jointly owned with HP. In theory it would be impossible for anyone else to reimplement IA64 and "impossible" for IA64 to be licensed to another manufacturer.

Re: Tech Preview of Docker Desktop for M1

#158

Post by TimTheTinker »

ogre_codes wrote: post #118
luhn wrote: post #114

Earlier quoted context omitted.

M1 Docker still needs a Linux VM, Virtualization Framework is just a different way of doing that. I'm not aware of any VM that can share memory with the host, but maybe Apple has some black magic up their sleeve.

Yeah, fundamentally Docker is Linux on Linux. If you are running Linux on MacOS, it's not Docker, it's a VM. So Docker installs are Linux Docker Image -> Linux VM -> MacOS Virtualization Framework. For that reason alone, I suspect Linux will always be the best host system for Docker images.

> I suspect Linux will always be the best host system for Docker images.

It seems that for more than 1-2 containers, running Docker inside a Linux VM on macOS is better resource-wise.

Re: Tech Preview of Docker Desktop for M1

#159

Post by stephenr »

haswell wrote: post #127
stephenr wrote: post #111

Earlier quoted context omitted.

> This is what you said: The “one sentence” I was referring to is right above the bit you quoted: > I’m talking about understanding that containers are inherently tied to the kernel, and thus are limited to running software written for the same kernel as the host running the container.

You've lost me. This sentence does not explain how Docker, or containers work. It explains one aspect/limitation related to the execution of code in a container, but does not foster a deeper understanding of container architecture for the uninformed reader, and is actually somewhat misleading considering Docker's use of a VM behind the scenes in some situations (in which case the "host running the container" is techn…

> considering Docker's use of a VM behind the scenes in some situations (in which case the "host running the container" is technically the VM, not the user's PC).

That is exactly the point. If you want to run Linux binaries you need a Linux container. On windows or macOS that means a Linux vm.

If you want to run windows binaries you need a windows container.

Conversely if you had a macOS container you’d only be able to run macOS binaries.

This is my point. It’s not a hard concept to understand. I’m not asking people to learn about cgroups or Chroots or network namespaces or any of that.

Re: Tech Preview of Docker Desktop for M1

#160

Post by daragrin »

luhn wrote: post #114
ogre_codes wrote: post #78

Earlier quoted context omitted.

I think the Virtualization Framework mitigates that to some extent. The way Docker was required to run on x86 it needed a Linux VM which I believe the Docker images ran atop. Under the new model, I think they run on bare metal and share memory. Regardless, for me the cost of adding enough RAM to support Docker is less than the headache and expense of spinning up Docker images in the cloud.

M1 Docker still needs a Linux VM, Virtualization Framework is just a different way of doing that. I'm not aware of any VM that can share memory with the host, but maybe Apple has some black magic up their sleeve.

Seems like Apple's Virtualization Framework supports some sort of memory ballooning mechanism (https://developer.apple.com/documentation/virtualization/mem...), which could hopefully enables in the near future dynamic memory support like Docker Desktop on WSL 2 is able to do (if it's not already the case, I haven't tried the M1 preview).
Post reply on HN