Hacker News Reader

Comment by Eduard | Hacker News Reader

I hope this doesn't affect LXC negatively.

LXC and LXD share plenty of contributors.

https://github.com/lxc/lxc/graphs/contributors

https://github.com/canonical/lxd/graphs/contributors

I use an "unprivileged LXC container" setup on several Debian bullseye hosts. It works fantastic, and each LXC container feels like a real server.

Compare that to Docker's "one-container-one-process" philosophy, reinventing the wheel by awkwardly composing multiple containers.

View on HN

I thought so too ~10 years ago but switched to docker on all my machines some years ago. For me personally it seems much easier to manage docker-compose and Dockerfiles than individually managing lxc/lxd containers. And I do have some docker containers that run multiple processes where separation makes no sense. I'm not ever going back to lxd.

I now only wish docker either evolves or something entirely new replaces k8s since I do not really like k8s setup and usability.

Been using LXC for years via Proxmox. Just dipping my toes into docker to explore ways to distribute CPU bound workloads. Quite different and different use cases. I do like how the docker files provide a rock solid definition of the environment, that should come in very handy in the future when I have completely forgotten how something works and need to update it. I usually put a config.txt in the root of my LXC containers for a similar purpose, but the Dockerfiles are more explicit. I like to hotpatch my code and I hate complicated built processes, so I don't see going all in with Docker, but it is quite an elegant way to package an application. I always had the impression that it was overly complex, but after actually trying it I am surprised by all the things I like.

My original intention was to deploy a Gaussian Process Regression model built with PyMC on AWS Lambda. I need to build and run a few thousand of these each morning. Building the Docker image was fun and it worked great, but AWS Lambda was extremely disappointing. Even when configured with 10GB of RAM, it was pretty slow and running my predictions would cost hundreds of dollars per day. I can spin up a 128 core bare metal EPYC server on vultr for an hour at a cost of $8 that can finish the job faster. That's still more expensive than I had envisioned so if anyone can suggest any smaller providers that can run CPU bound workloads in ephemeral docker containers, let me know.

Well, Dockerfile is as solid as a bunch of bash scripts apt-get installing and wgetting things from the internet, that means not at all. Maybe nix could provide a real solution for that.

Yes, they are, but once it is built, you can store it so you do not have to run it every time and in every environment.

I use VS Code to hotpatch hotpatchable code. Half of the stuff I write is in Rust and I'm not smart enough to go and change bits of an executable.

But for Python it works out great, except for when the container doesn't start. If it doesn't start you can't connect VS Code to it.

The trick then is to use `docker cp` to pull out the file that breaks the python process, fix it, `cp` it back and try and start the container.

If possible I like to change the EXEC method to `/bin/bash`, the COMMAND to `tail -f /dev/null`, and execute the python process in an interactive terminal. That mitigates the container not starting issue... unless `tail -f /dev/null` fails. But if that's the case I've got bigger fish to fry.

Nomad is the better k8s.

Thanks for the suggestion, but it has put several important features behind an expensive paywall.

I understand people want to earn money but something as essential as this should somehow be free and available to everyone. Not sure how exactly big companies would split the bill, but it should be possible in our universe. After all, we have Linux, git, openssh, etc. I know that k8s was supposed to be that, but it sucks.

I run a similar setup: unprivileged LXC for hosting web applications. It works great, and has been way more stable and reliable than Docker.

I had planned to migrate to LXD now that current Debian has a package for it, but now ... nah, unfortunately. I was really looking forward to the live migration feature.

Can one create and run unprivileged LXC containers easily now? Last time I looked, some years ago, there were some problems (at least in stock Ubuntu) and you practically had to run them as root.

BTW, what does migrating LXC to LXD mean? I always used just LXC, and thought LXD was something at a upper layer to help manage them but you still used the same LXC containers underneath.

"easily" is a matter of opinion. It did take me a little effort to get it nailed down. Here's the markdown shell script I use to create new LXC containers: https://github.com/robsheldon/biphrost-shell/blob/biphrost/l... -- it should be easy enough to modify for other environments.

It's been a while since I looked into it, but IIRC there was a "migration" or "adoption" step. I think you're generally right that LXD worked like an extension of or administrative layer for LXC, but also: http://web.archive.org/web/20230605025133/https://linuxconta... (the documentation is no longer available on linuxcontainers.org now that Canonical has taken over the project).

Thanks!

Why is it awkward? I manage 5ish lines in a docker compose file describing each service and thats about it

The advantage of docker for me is having a docker-compose.yml. If an lxc-compose.yml existed, I would happily switch everything. As it is now, I have 10 unprivileged LXC on Proxmox with 25 Docker containers nested inside. Works flawlessly since 5 years. 1-2% CPU utilization of the whole system, on average.

> Compare that to Docker's "one-container-one-process" philosophy, reinventing the wheel by awkwardly composing multiple containers.

It depends on your mental model, I see containers as chroots on steroids so the one process per container feels very natural.

Reply on news.ycombinator.com