LXC and LXD: a different container story
1–10 of 102 posts
Re: LXC and LXD: a different container story
#2These seem like cool tech and I know things like proxmox can run them pretty easily.
Still Dockerfiles and all the magic that goes with them was just so much easier to pick up and convince others on the team to try.
Re: LXC and LXD: a different container story
#3No layer caching mechanisms
Re: LXC and LXD: a different container story
#4I use an LXC to run Docker and a bunch of containers on my Proxmox VE machine :). LXC is interesting, but you can't beat the ecosystem of Docker images available (and maintained, updated, etc.)
Have a few apps running in plain LXC containers (like AdguardHome) but maintenance is non-free (unlike a docker-compose stack with Watchtower keeping everything nice and fresh).
Re: LXC and LXD: a different container story
#5I use an LXC to run Docker and a bunch of containers on my Proxmox VE machine :). LXC is interesting, but you can't beat the ecosystem of Docker images available (and maintained, updated, etc.) Have a few apps running in plain LXC containers (like AdguardHome) but maintenance is non-free (unlike a docker-compose stack with Watchtower keeping everything nice and fresh).
What do you mean by Watchguard? I did a search but didn't find anything. Did you mean Watchtower maybe?
Re: LXC and LXD: a different container story
#6I use LXD + ansible for my personal projects. IMO the main benefit I see is it requires very low cognitive overhead. It's insanely easy to set up a container, I only need to remember like 3 commands ever. These programs will never be clustered either so theres no point in having a scheduler.
Re: LXC and LXD: a different container story
#7I have been running a handful of Debian systems in containers since OpenVZ was state-of-the art. As the hardware expired, I moved to linux-vserver, then LXC, then LXD ... at which point it all shifted from straightforward text configuration files to SQLite mediated by CLI programs. When I could not figure out the incantation required for some gnarly configuration rotations ("computer says no"), I was forced to shut everything down, alter the SQLite files directly, and spin it all back up again. On the next hardware refresh, I switched back to LXC.
This sort of mediation makes sense and works great for ephemeral containers in Kubernetes. For full virtual servers, LXD is the worst of both worlds.
Re: LXC and LXD: a different container story
#8I use an LXC to run Docker and a bunch of containers on my Proxmox VE machine :). LXC is interesting, but you can't beat the ecosystem of Docker images available (and maintained, updated, etc.) Have a few apps running in plain LXC containers (like AdguardHome) but maintenance is non-free (unlike a docker-compose stack with Watchtower keeping everything nice and fresh).
What do you mean by Watchguard? I did a search but didn't find anything. Did you mean Watchtower maybe? https://github.com/containrrr/watchtower
Yes, watchtower, sorry.
Re: LXC and LXD: a different container story
#9I use LXD + ansible for my personal projects. IMO the main benefit I see is it requires very low cognitive overhead. It's insanely easy to set up a container, I only need to remember like 3 commands ever. These programs will never be clustered either so theres no point in having a scheduler.
What would those 3 commands be? As a developer who has not used LXD, I’m curious for insight into the developer experience.
Re: LXC and LXD: a different container story
#10I use both lxc and docker and have uses cases for both, I think it really comes down to how stateful something is or how lazy I feel about writing a Dockerfile. I had a really hard time with learning lxd and really only got into using lxc without the daemon.
One trend with docker that I personally don't like is that a lot of projects prefer docker-compose over regular Dockerfiles (though some of them support both), and this leads to a lot of bloat with how many containers it takes to run one application and duplication where each app will need its own database, redis, webserver, etc. containers.
That's not a problem when you are at the scale to need that kind of orchestration and have the resources to run that many containers, but personally I would rather have one database host that all my containers can talk to and one reverse proxy/webserver to make them accessible to make better use of resources and get better density on one host.
One downside with lxc is that there's been some fragmentation with the image creation side of it, I had been used to using lxc-templates for years, which are just shell scripts for bootstrapping and configuring your container and pretty common between distros. I found a bug with creating containers for the latest version of Alpine that I fixed, and only then did I find out that lxc-templates are deprecated and essentially unmaintained, and that now distrobuilder is the preferred way to build lxc containers, at least per Canonical. That seems to be another Canonical-ism, since the distrobuilder docs say that snap is the only way to install it unless you build from source, so that's a huge no from me, and I also didn't feel like learning the yaml config for it.
I was actually considering moving my docker daemon into an unprivileged lxc container like the article mentions, but haven't gotten around to it.