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

71–80 of 147 posts

Re: LXC vs. Docker

#71

Post by [deleted] »

richardwhiuk wrote: post #67
m463 wrote: post #66

Earlier quoted context omitted.

I would say docker's killer feature is the Dockerfile. It makes it understandable, reproducible and available to a broad range of people. At least they mentioned it in their apple:oranges comparison. there's also the global namespace thing. "FROM ubuntu:18.04" is pretty powerful. I run a proxmox server with LXC but if I could use a dockerfile or equivalent, my containers would be much much more organized. I wouldn't…

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

[deleted]

Re: LXC vs. Docker

#72

Post by heresie-dabord »

fuzzy2 wrote: post #28

I’ve been using LXC as a lightweight “virtualization” platform for over 5 years now, with great success. It allows me to take existing installations of entire operating systems and put them in containers. Awesome stuff. On my home server, I have a VNC terminal server LXC container that is separate from the host system. Combined with ipvlan I can flexibly assign my dedicated server’s IP addresses to containers as requ…

> . It allows me to take existing installations of entire operating systems and put them in containers

Friend, do you have documentation for this process? Please share your knowledge. ^_^

Re: LXC vs. Docker

#73

Post by alyandon »

agartner wrote: post #55
alyandon wrote: post #48

Earlier quoted context omitted.

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.…

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.

That certainly works too but with my approach you can run "snap refresh" manually whenever you feel like updating.

Re: LXC vs. Docker

#74

Post by fulafel »

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.

LXD does all of that since a long time, eg here's a tutorial from 2015: https://ubuntu.com/blog/publishing-lxd-images

Re: LXC vs. Docker

#75

Post by razerbeans »

petre wrote: post #44
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.

Weird, I just tested on my proxmox instance and I was able to create a snapshot of a running container (PVE 7.1-10)

Re: LXC vs. Docker

#76

Post by rlpb »

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…

> This is because canonical insists on auto-updating and refreshing the snap at random intervals, even when you pin to a specific version channel.

You can control snap updates to match your maintenance windows, or just defer them. Documentation here: https://snapcraft.io/docs/keeping-snaps-up-to-date#heading--...

What you cannot do without patching is defer an update for more than 90 days. [Edit: well, you sort of can, by bypassing the store and "sideloading" instead: https://forum.snapcraft.io/t/disabling-automatic-refresh-for...]

Re: LXC vs. Docker

#77

Post by alyandon »

rlpb wrote: post #76
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…

> This is because canonical insists on auto-updating and refreshing the snap at random intervals, even when you pin to a specific version channel. You can control snap updates to match your maintenance windows, or just defer them. Documentation here: https://snapcraft.io/docs/keeping-snaps-up-to-date#heading--... What you cannot do without patching is defer an update for more than 90 days. [Edit: well, you sort of ca…

Why would any sysadmin that maintains a fleet of servers with varying maintenance windows (that may or may not be dependent on the packages installed) want to feed snapd a list of dates and times to basically ask it pretty please not to auto-update snaps?

It is much easier to give sysadmins back the power they've always had to perform updates when it is reasonable to do so on their own schedule without having to inform snapd of what that schedule is.

I really don't appreciate being told by Canonical that I have to jump through additional hoops and spend additional time satisfying snapd to maintain the systems under my control.

Re: LXC vs. Docker

#78

Post by ruhrharry »

LXC is quite different from Docker. Docker is used most of the time as an containerized package format for servers and as such is comparable to snap or flatpak on the desktop. You don't have to know Linux administration to use Docker, that is why it is so successfull.

LXC on the other hand is lightweight virtualization and one would have a hard time to use it without basic knowledge of administering Linux.

Re: LXC vs. Docker

#79

Post by zelphirkalt »

richardwhiuk wrote: post #67
m463 wrote: post #66

Earlier quoted context omitted.

I would say docker's killer feature is the Dockerfile. It makes it understandable, reproducible and available to a broad range of people. At least they mentioned it in their apple:oranges comparison. there's also the global namespace thing. "FROM ubuntu:18.04" is pretty powerful. I run a proxmox server with LXC but if I could use a dockerfile or equivalent, my containers would be much much more organized. I wouldn't…

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 work, but sometimes it is worth it.

Re: LXC vs. Docker

#80

Post by khimaros »

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…

it looks like there has been considerable progress packaging in debian bookworm: https://blog.calenhad.com/posts/2022/01/lxd-packaging-report...
Post reply on HN