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

LXC vs. Docker

earthly.dev

Post reply on HN
Print view View original

101–110 of 147 posts

Re: LXC vs. Docker

#101

Post by lasftew »

My home server runs Nixos, which is an amazing server operating system: every service is configured in code and fully versioned. I also use this server for development (via SSH), but while Nixos can be used for development, it's relationship with VS Code, its plugins, and many native build tools (Golang, Rust) is very complicated, and I prefer not to do everything the Nix way, which is usually convoluted and poorly documented.

LXD is my perfect fit in this scenario: trivial to install on top of Nixos, and once running, allows for launching some minimal development instances of whatever distro flavor of the day in a few seconds. Persistent like a small VM, but booting up within seconds, much more efficient on resources (memory in particular), and - unlike docker - with the full power of systemd and all. Add tailscale and sshd to the mix, for easy, secure and direct remote access to the virtualized system.

Re: LXC vs. Docker

#102

Post by [deleted] »

whitepoplar wrote: post #57
yokem55 wrote: post #42

LXD (Canonical's daemon/API front end to lxc containers) is great -- as long as you aren't using the god awful snap package they insist on. The snap is probably fine for single dev machines, but it has zero place in anything production. This is because canonical insists on auto-updating and refreshing the snap at random intervals, even when you pin to a specific version channel. Three times I had to manually recover…

Just curious--how do you use LXD in production? It always struck me as something very neat/useful for dev machines, but I had trouble imagining how it would improve production workloads.

[deleted]

Re: LXC vs. Docker

#103

Post by jethro_tell »

djbusby wrote: post #69
agartner wrote: post #55

Earlier quoted context omitted.

We blocked the annoying snapd autoupdate behavior by setting a http proxy to a nonexistent server. Whenever we had a maintenance window we would unset the proxy, allow the update, then set the set the nonexistent proxy server again. Very annoying.

this feels both clever and stupid at the same time - not you but the software games you have to play.

theres a lot of wasted effort in the games we play to make software work in prod.

Re: LXC vs. Docker

#104

Post by mlrhazi »

Ajedi32 wrote: post #52
tra3 wrote: post #46

Earlier quoted context omitted.

Can you expand on how builds aren't reproducible? I though Dockerfile ensured that builds are indeed reproducible?

Running the same script every time doesn't necessarily guarantee the same result. Lots of docker build scripts have the equivalent of date > file.txt or curl https://www.random.org/integers/?num=1&min=1&max=1000&col=1&base=10&format=plain&rnd=new > file.txt Buried deep somewhere in the code. But yeah I don't see any reason why you couldn't theoretically make a reproducible build with Docker.

Would that not be cached? It would not actually run that date command again, right? unless you change that date line itself, in the Dockerfile.

Re: LXC vs. Docker

#105

Post by malkia »

I know very little about both, but I'm at the mercy everyday with lxc on my chromebook when running crostini (it's like a VM in a VM in a VM in a...) :) - works great though, at some perf cost, and less GPU support.

And still having troubles running most of the docker images out there (either this, or that won't be supported). I guess it makes sense, after all there is always the choice of going with full real linux reinstall, or some other hacky ways.

But one thing I was not aware was this: "Docker containers are made to run a single process per container."

Re: LXC vs. Docker

#106

Post by zibzab »

CSDude wrote: post #84
yokem55 wrote: post #42

LXD (Canonical's daemon/API front end to lxc containers) is great -- as long as you aren't using the god awful snap package they insist on. The snap is probably fine for single dev machines, but it has zero place in anything production. This is because canonical insists on auto-updating and refreshing the snap at random intervals, even when you pin to a specific version channel. Three times I had to manually recover…

I had a huge argument in 2015 with a guy that wanted to move our every custom .deb package (100+) to Snap, because they had talked with Canonical and it would be the future, Docker would be obsolete. Main argument was to make distribution easier to worker/headless/server machines. Not that Docker is a direct replacement, but Snap is an abomination. They are mostly out of date, most of them requires system privilleges…

pro tip: you can use lxc/lxd to run VMs under the same infrastructure.

I belive it is something as easy as

    lxc launch -vm ubuntu/20.04 myvm

Re: LXC vs. Docker

#107

Post by zibzab »

warent wrote: post #89
yokem55 wrote: post #42

LXD (Canonical's daemon/API front end to lxc containers) is great -- as long as you aren't using the god awful snap package they insist on. The snap is probably fine for single dev machines, but it has zero place in anything production. This is because canonical insists on auto-updating and refreshing the snap at random intervals, even when you pin to a specific version channel. Three times I had to manually recover…

On my Ubuntu 20 server, I tried setting up microk8s with juju using LXD and my god the experience was horrendous. One bug after another after another after another after another. Then I upgraded my memory and somehow snap/LXD got perma stuck in an invalid state. The only solution was to wipe and purge everything related to snap/LXD. After that I setup minikube with a Docker backend. It all worked instantly, perfectly…

Note that Canonical has special tools for installing and configuring that stuff (conjureup or something)

Re: LXC vs. Docker

#108

Post by arjvik »

zibzab wrote: post #106
CSDude wrote: post #84

Earlier quoted context omitted.

I had a huge argument in 2015 with a guy that wanted to move our every custom .deb package (100+) to Snap, because they had talked with Canonical and it would be the future, Docker would be obsolete. Main argument was to make distribution easier to worker/headless/server machines. Not that Docker is a direct replacement, but Snap is an abomination. They are mostly out of date, most of them requires system privilleges…

pro tip: you can use lxc/lxd to run VMs under the same infrastructure. I belive it is something as easy as lxc launch -vm ubuntu/20.04 myvm

What VM software does this make use of? KVM?

Re: LXC vs. Docker

#109

Post by fideloper »

dijit wrote: post #12
melenaboija wrote: post #10

I use LXC containers as my development environments. When I changed my setup from expensive Mac Books to an expensive work station with a cheap laptop as front end to work remotely this was the best configuration I found. It took me few hours to have everything running but I love it now. New project is creating a new container add a rule to iptables and I have it ready in few seconds.

FWIW I do the same thing but with docker. Exposing the docker daemon on the network and setting DOCKER_HOST I’m able to use the remote machine as if it was local. It’s hugely beneficial, I’ve considered making mini buildfarms that load balance this connection in a deterministic way.

How do you share code files (set volume mounts) with remote docker via setup?

Re: LXC vs. Docker

#110

Post by hpb42 »

pkulak wrote: post #59
yokem55 wrote: post #42

LXD (Canonical's daemon/API front end to lxc containers) is great -- as long as you aren't using the god awful snap package they insist on. The snap is probably fine for single dev machines, but it has zero place in anything production. This is because canonical insists on auto-updating and refreshing the snap at random intervals, even when you pin to a specific version channel. Three times I had to manually recover…

Not even kidding, a huge part of what made me move to Arch was that it's one of the few distros that packages LXD. Apparently it's a pain, but I'm forever grateful!

I did not know there were so few distros packaging LXD [0]. It does not come as a surprise that Canonical would not endorse non-snapded LXD though. And it is sad.

[0] https://repology.org/project/lxd/versions

Post reply on HN