Live data from Hacker News

LXD containers on macOS at near-native speeds

beringresearch.github.io

71–80 of 134 posts

Re: LXD containers on macOS at near-native speeds

#71

Earlier quoted context omitted.

QEMU can use the MacOS virtualization framework layer to run a VM built for the same arch without going through any translation. From there you can register Rosetta as a runtime and use it to run x86-64 Linux apps on ARM64 if you want. ( https://developer.apple.com/documentation/virtualization/run... )

I don't understand why one needs to emulate a virtual machine to run a container. Why do you need a kernel? Why emulate physical devices, interrupts and everything else? Why cannot one run a container as a protected mode application?

You don't and that's the idea behind gVisor.

Re: LXD containers on macOS at near-native speeds

#72

Earlier quoted context omitted.

Canonical has a product of their own: https://multipass.run/ They all use the underlying OS hypervisor so I’m not sure you can get perceivable performance out of one solution over the other.

Sometime it can be buggy on macOS and quite slow to boot with Ubuntu VM, wish there is a cloud VM image.

> wish there is a cloud VM image

What do you mean? Multipass only runs Ubuntu server cloud images.

Re: LXD containers on macOS at near-native speeds

#73
post #40

So is there some canonical guide to running a docker compose style app on Mac m1 machines that has good filesystem performance? It seems like there’s many ways to approach the topic now so it’s hard to tell which one is “winning”. I’d love to containerize all of my local development efforts (scripts and rails apps) but the slow ass filesystem always ruined it in the past.

I've recently switched to using nix-shell and overmind with a Procfile to officially retired docker-compose from all of my projects. Such a breath of fresh air.

Like Mitchell Hashimoto (Hashicorp), I no longer do any development on macOS directly; I have a Linux VM where all my projects live and have their environments managed with a shell.nix file. Highly highly recommend it.

Re: LXD containers on macOS at near-native speeds

#76
post #73
post #40

So is there some canonical guide to running a docker compose style app on Mac m1 machines that has good filesystem performance? It seems like there’s many ways to approach the topic now so it’s hard to tell which one is “winning”. I’d love to containerize all of my local development efforts (scripts and rails apps) but the slow ass filesystem always ruined it in the past.

I've recently switched to using nix-shell and overmind with a Procfile to officially retired docker-compose from all of my projects. Such a breath of fresh air. Like Mitchell Hashimoto (Hashicorp), I no longer do any development on macOS directly; I have a Linux VM where all my projects live and have their environments managed with a shell.nix file. Highly highly recommend it.

Would you elaborate on the setup? I recall seeing a comment or article where Mitchell mentioned this setup previously. I’ve been using Make + Docker for development on macOS for a long time now and perhaps it’s time for a change. I’ve looked at nix once or twice over the years but it never really clicked.

Re: LXD containers on macOS at near-native speeds

#77
post #56
post #42

Earlier quoted context omitted.

so arm macbooks are still problematic for developers who use containers and x86 servers... it's still surprising to me that they did this as i always got the sense that developer word of mouth helped drive a lot of macbook adoption in the 2000s.

In what way? I use ARM containers locally to dev and test locally, check in the code and the build server creates an x86 image for deployment to the server. Worst case you have to build the ARM container yourself locally and tag it with the "remote" name and docker will just use it instead of pulling the remote version.

you have to add support for your infrastructure to support building of everything for two architectures. sometimes problems are architecture dependent. if you have to use x86 containers for some reason, they will be dog slow because you'll be running the kernel under emulation and in userland rosetta won't help.

Re: LXD containers on macOS at near-native speeds

#78
post #77
post #56

Earlier quoted context omitted.

In what way? I use ARM containers locally to dev and test locally, check in the code and the build server creates an x86 image for deployment to the server. Worst case you have to build the ARM container yourself locally and tag it with the "remote" name and docker will just use it instead of pulling the remote version.

you have to add support for your infrastructure to support building of everything for two architectures. sometimes problems are architecture dependent. if you have to use x86 containers for some reason, they will be dog slow because you'll be running the kernel under emulation and in userland rosetta won't help.

Rosetta absolutely does help. You register rosetta (which can be mounted into the VM using macOS's virtualization framework) with binfmt_misc and your x86 binaries inside the VM will run through Rosetta.

Re: LXD containers on macOS at near-native speeds

#79
post #30

I like the progress that is being made for running containerized workloads on macOS. In my case I like some of the benefits of running the workload on a remote machine; such as no fan noise, less heat, less power consumption (especially on laptops). However the downsides can be also quite annoying, such as file sync times or IDE input lag. My current setup is to have both data and workload run on a remote machine and…

Mutagen is what you're looking for!

- Local and remote copy of files - Two way sync

I've been using this for years, editing locally with Sublime, while running everything on a remote Linux vm. Because it's two way sync, anything created/modified on the server is also sync'd back to your local filesystem. I end up syncing most of the remote $HOME so I can easily fire up a new VM, sync, and go. It really is fantastic.

https://mutagen.io/documentation/synchronization

Re: LXD containers on macOS at near-native speeds

#80

Earlier quoted context omitted.

I've been using Colima lately and it's been a great experience. The only thing that didn't quite work was pushing an image to AWS ECR, but pulling images, building images (with BuildKit), and running containers all worked fine, and faster than Docker.

isn’t Buildkit Docker?

https://github.com/moby/buildkit it looks like it is not, kind of?
Post reply on HN