Live data from Hacker News

LXD containers on macOS at near-native speeds

beringresearch.github.io

81–90 of 134 posts

Re: LXD containers on macOS at near-native speeds

#82

Too bad almost all containers rely on bridged networking and different ports. Why not just bind to 127.0.x.y, where x is the project number, and y is the machine number. That way, you can just use default ports

Because the loopback address doesn't work like that. 127.0.0.0/8 is defined as all loopback, which means the OS shouldn't differentiate between them, so any VMs binding on 127.* are going to interfere with the OS binding there.

Re: LXD containers on macOS at near-native speeds

#83

Too bad almost all containers rely on bridged networking and different ports. Why not just bind to 127.0.x.y, where x is the project number, and y is the machine number. That way, you can just use default ports

Because the loopback address doesn't work like that. 127.0.0.0/8 is defined as all loopback, which means the OS shouldn't differentiate between them, so any VMs binding on 127.* are going to interfere with the OS binding there.

Any other (local) range would be fine. 127.* does seem to have some strange behaviors

Re: LXD containers on macOS at near-native speeds

#84
post #70
post #11

This is part of the bigger Macpine project, which to me is much more interesting than LXD: https://github.com/beringresearch/macpine """ The goal of this project is to enable MacOS users to: Easily spin up and manage lightweight Alpine Linux environments. Use tiny VMs to take advantage of containerisation technologies, including LXD and Docker. Build and test software on x86_64 and aarch64 systems """

It feels like lima and colima are much more mature. Being unable to remap the SSH port (or other ports) alone makes this a non-starter.

I ended up just getting a System 76 Meerkat computer for doing anything locally with LXC/Docker. Linux emulation in Windows or macOS is unbearably bad if you really need to do serious work.

Re: LXD containers on macOS at near-native speeds

#85

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?

Whatever it is, Colima seems to have faster image builds and faster container startup, which makes my life better.

Re: LXD containers on macOS at near-native speeds

#86

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?

Adding to other answers, not only containers of the docker and LXC/D types are Linux things that need a Linux kernel but often the software inside the container must be deployed and run on a Linux host. Often the build is done on a Linux server in a CI system and not on developers machines but developers do have to run that software too, kind of by definition.

Re: LXD containers on macOS at near-native speeds

#87
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.

What do you use to run the VM? Do you try to minimize overhead at all?

Re: LXD containers on macOS at near-native speeds

#88
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.

My whole team got M1s, so we just use ARM images on AWS. Haven't had any problems.

Re: LXD containers on macOS at near-native speeds

#89
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.

Not dog slow but slower than they could. My experience is: a Rails test suite takes 75 seconds on my 2014 Intel ZBook laptop with a SATA bus and a SSD. It takes 50 seconds on a M1 MacBook. I'm sure I could have found some expensive Intel laptop as fast as that back in 2014. Docker on the M1 runs with something called Mutagen and we have two different docker-compose.yml, but one Dockerfile.

Re: LXD containers on macOS at near-native speeds

#90
post #70

Earlier quoted context omitted.

It feels like lima and colima are much more mature. Being unable to remap the SSH port (or other ports) alone makes this a non-starter.

I ended up just getting a System 76 Meerkat computer for doing anything locally with LXC/Docker. Linux emulation in Windows or macOS is unbearably bad if you really need to do serious work.

Even systemd will run in Docker on macOS. Can you clarify what makes macOS unacceptable for emulating Linux?
Post reply on HN