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

111–120 of 147 posts

Re: LXC vs. Docker

#111

Post by warent »

zibzab wrote: post #107
warent wrote: post #89

Earlier quoted context omitted.

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)

That's what I was using, and is largely how Juju is used

Re: LXC vs. Docker

#112

Post by GauntletWizard »

zelphirkalt wrote: post #79
richardwhiuk wrote: post #67

Earlier quoted context omitted.

Understandable? Yes. Reproducible? No. Most Dockerfiles are incredibly unreproducible.

Most are not, that's true. It is possible to get to reproducibility though, by involving lots of checksums. For example you can use the checksum of a base image in your initial FROM line. You can download libraries as source code and install them. You can use package managers with lock files to get to reproducible environments of the language you are using. You can check checksums of other downloaded files. It takes…

That work is hard and the tooling is bad and it only takes one mistake, like forgetting to suppress the mtime of your files.

Docker was good enough, simple enough, and got the job done. It won for good reason, but the next generation should learn from it's mistakes.

Re: LXC vs. Docker

#113

Post by cpuguy83 »

wanderr wrote: post #92
adamgordonbell wrote: post #2

I like the docker way of one thing, one process, per container. LXC seems a bit different. However, an exciting thing to me is the Cambrian explosion of alternatives to docker: podman, nerdctl, even lima for creating a linux vm and using containerd on macos looks interesting.

That seems weird for some stacks though, like nginx, php-fpm, php. At least I still haven't wrapped my head around what's the right answer for the number of containers involved there.

It is workload dependent. My general way of thinking about it is containing a unit of work. Sometimes that is a single process, others it is a bunch of things. Sometimes I may want to run a database separate from my application code, sometimes not.

How do you scale it, how do you manage it, how will it get deployed, all questions that go into the answer of what should go into it.

Re: LXC vs. Docker

#114

Post by cpuguy83 »

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.

Hopefully you are doing this securely :)

BTW, no need to expose DOCKER_HOST, you can connect to docker over ssh, e.g. `DOCKER_HOST=ssh://1.2.3.4`.

Re: LXC vs. Docker

#115

Post by NorwegianDude »

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…

That's strange. I've had no issues using microk8s. Super easy to set up on Ubuntu 20.04.

Re: LXC vs. Docker

#116

Post by NorwegianDude »

conradfr wrote: post #90
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…

Maybe two years ago I wanted to use LXD on a fresh Ubuntu server (after testing it locally). First they had just moved it to Snap which was not a great install experience compared to good old apt-get, and then all my containers had no IPv4 because of systemd for a reason I can't remember. After two or three tries I just gave up, installed CapRover (still in use today) and have not tried again since.

The install experience should be the same. Using apt install lxd should give you snap. I've installed LXD quite a few times with different storage and network setups without any issues, so I do find it strange that it didn't work for you.

Re: LXC vs. Docker

#117

Post by amarshall »

mlrhazi wrote: post #104
Ajedi32 wrote: post #52

Earlier quoted context omitted.

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.

If you’re using a cached version, you haven’t really reproduced anything but the cache itself. Reproducibility means creating the same output given the same input, every time, regardless of some local cache.

That said, the above example isn’t specific to Docker.

Re: LXC vs. Docker

#118

Post by curt15 »

_448 wrote: post #95
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…

> The snap is probably fine for single dev machines It is not good even on single dev machines.

I normally use podman for my dev machine. Unlike LXD, it can run rootless.

Re: LXC vs. Docker

#119

Post by amarshall »

tra3 wrote: post #64
Ajedi32 wrote: post #52

Earlier quoted context omitted.

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.

If you have dynamism like this in your build, doesn't that imply that no build system is reproducible?

Yes, but previous commenter said

> I [thought] Dockerfile ensured that builds are indeed reproducible?

The example straightforwardly disproves that.

Re: LXC vs. Docker

#120

Post by tomrod »

alyandon wrote: post #48
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 got so annoyed with snapd that I finally patched the auto-update functionality to provide control via environment variable. It's ridiculous that this is what I have to personally go through in order to maintain control of when updates are applied on my own systems. If enough people were to ever decide to get together and properly fork snapd and maintain the patched version I'd totally dedicate time to helping out.…

> If enough people were to ever decide to get together and properly fork snapd and maintain the patched version I'd totally dedicate time to helping out.

Is that the gist of flatpak?

Post reply on HN