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

41–50 of 147 posts

Re: LXC vs. Docker

#41

Post by Lifelarper »

bamboozled wrote: post #4

One major limitation of LXC is that there is no way to easily self host images. Often the the official images for many distributions are buggy. For example, the official Ubuntu images seem to come with a raft of known issues. Based on my limited interactions with it, I'd recommend staying away from LXC unless absolutely neccesary.

> there is no way to easily self host images

When you run lxd init there's an option to make the server available over the network (default: No), if enabled you can host images from there.

    lxc remote add myimageserver images.bamboozled.com
    lxc publish myimage
    lxc image copy myimage myimageserver
    
    lxc launch myimageserver:myimage

Re: LXC vs. Docker

#42

Post by yokem55 »

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 a cluster of lxd systems that broke during a snap refresh because the cluster couldn't cope with the snaps all refreshing at once.

Going forward we built and installed lxd from source.

Re: LXC vs. Docker

#43

Post by orthecreedence »

adamgordonbell wrote: post #9
merlinscholz wrote: post #5

Earlier quoted context omitted.

I recently started using containerd inside Nomad, a breath of fresh and simple air after failed k8s setups!

Oh, Nomad looks interesting. Why should someone reach for it vs K8S?

I have used nomad at my work for a few years now. I'd say where it shines is running stateless containers simply and easily. If you're trying to run redis, postgres, etc...do it somewhere else. If you're trying to spin up and down massive amounts of queue workers hour by hour, use it as a distributed cron, or hell just run containers for your public api/frontend and keep them running, nomad is great.

That said, you're going to be doing some plumbing for things like wiring your services together (Fabio/Consul Connect are good choices), detecting when to add more host machines, etc.

As far as how it compares to k8s, I don't know, I haven't used it materially yet.

Re: LXC vs. Docker

#44

Post by petre »

buybackoff wrote: post #16

LXC via Proxmox is great for stateful deployments on baremetal servers. It's very easy to backup entire containers with the state (SQLite, Postgres dir) to e.g. NAS (and with TrueNAS then to S3/B2). Best used with ZFS raid, with quotas and lazy space allocation backups are small or capped. Nothing stops one from running Docker inside LXC. For development I usually just make a dedicated priviledged LXC container with…

It's an annoying that you can only make snapshots on a stopped container. With VMs it works in a running VM.

Re: LXC vs. Docker

#45

Post by yjftsjthsd-h »

chriswarbo wrote: post #38
dottedmag wrote: post #3

Apples to oranges. LXC can be directly compared with a small, and quite insignificant, part of Docker: container runtime. Docker became popular not because it can run containers, many tools before Docker could do that (LXC included). Docker became popular because it allows one to build, publish and then consume containers.

> Docker became popular because it allows one to build, publish and then consume containers. True, but Docker is an awful choice for those things (builds are performed "inside out" and aren't reproducible, publishing produces unauditable binary-blobs, consumption bypasses cryptographic security by fetching "latest" tags, etc.)

It's still superior to everything that came before it (at least, that I'm aware of), and cleared the "good enough" bar. Actually, I'm still not aware of anything that solves those issues without making it way harder to use - ex. nix addresses your points but has an awful learning curve.

Re: LXC vs. Docker

#46

Post by tra3 »

chriswarbo wrote: post #38
dottedmag wrote: post #3

Apples to oranges. LXC can be directly compared with a small, and quite insignificant, part of Docker: container runtime. Docker became popular not because it can run containers, many tools before Docker could do that (LXC included). Docker became popular because it allows one to build, publish and then consume containers.

> Docker became popular because it allows one to build, publish and then consume containers. True, but Docker is an awful choice for those things (builds are performed "inside out" and aren't reproducible, publishing produces unauditable binary-blobs, consumption bypasses cryptographic security by fetching "latest" tags, etc.)

Can you expand on how builds aren't reproducible?

I though Dockerfile ensured that builds are indeed reproducible?

Re: LXC vs. Docker

#47

Post by numlock86 »

sickygnar wrote: post #31

I never hear systemd-nspawn mentioned in these discussions. It ships and integrates with systemd and has a decent interface with machinectl. Does anyone use it?

> I never hear systemd-nspawn mentioned in these discussions. It ships and integrates with systemd and has a decent interface with machinectl.

I couldn't have said it better. And yes, I use it. Also in production systems.

Re: LXC vs. Docker

#48

Post by alyandon »

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.

https://gist.github.com/alyandon/97813f577fe906497495439c37d...

Re: LXC vs. Docker

#49

Post by theteapot »

> Saying that LXC shares the kernel of its host does not convey the whole picture. In fact, LXC containers are using Linux kernel features to create isolated processes and file systems.

So what is Docker doing then??

Re: LXC vs. Docker

#50

Post by tyingq »

dottedmag wrote: post #3

Apples to oranges. LXC can be directly compared with a small, and quite insignificant, part of Docker: container runtime. Docker became popular not because it can run containers, many tools before Docker could do that (LXC included). Docker became popular because it allows one to build, publish and then consume containers.

The confusion is because LXD is more comparable (build/publish/consume) to Docker, but the command you use to run it is called "lxc", so some people call LXD "LXC".
Post reply on HN