A while ago, I spent some time to make LXC run in a docker container. The idea is to have a statefull system managed by LXC run in a docker environment so that management (e.g. Volumes, Ingress and Load Balancer) from K8S can be used for the LXC containers. I still run a few desktops which are accessible by x2go with it on my kubernetes instances.
LXC vs. Docker
81–90 of 147 posts
Re: LXC vs. Docker
#82Earlier quoted context omitted.
Makes you wonder whether Canonical has any idea about operating servers. Auto-updating packages is the last thing you want. Doing that for a container engine, without building in some jitter to avoid the scenario you described is absolutely insane. Who even uses snap in production? If I squint my eyes I can see the use for desktops, but why insist on it for server technologies as well?
Canonical would gladly hand back full control of updates if you pay them for an "enterprise edition" snap store. https://ubuntu.com/core/docs/store-overview#:~:text=Brand%20... .
And even then, controlling the package versions is only one of the problems. The bigger problem which isn’t solved with this (as far as I can tell) is not having the machines automatically update due to how the snap software works.
Re: LXC vs. Docker
#83This would have been an ok article in 2013-2015. Nothing really has changed wrt. these two technologies since.
Re: LXC vs. Docker
#84LXD (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, unstable and the way they mount compressed rootfs is making starts very slow, even on a good machine.
That all being said, LXD is great way to run non-ephemeral containers that behave more like a VM. Also checkout multipass, by Canonical that also makes spinning up Ubuntu VMs as easy as Docker.
Re: LXC vs. Docker
#85I 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?
The big missing feature that's lacking is to pull Docker images and run them without resorting to hacks.
Re: LXC vs. Docker
#86I 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?
The big missing feature that's lacking is to pull Docker images and run them without resorting to hacks.
searched and found this: https://raw.githubusercontent.com/moby/moby/master/contrib/d...
Re: LXC vs. Docker
#87Earlier quoted context omitted.
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.
Is there a benefit to this over SSH or VSCode remote?
Neither SSH not VSCode offer any kind of isolation out of the box.
Re: LXC vs. Docker
#88Earlier quoted context omitted.
> 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 info…
My initial reaction was that having schedules upgrades like that would be great, but then 5 seconds later I realized it's much better suited to Cron, SystemD, Ansible (etc.).
I think the reason for auto-updates like this is because selling the control back to us is the business plan. It's the same thing Microsoft does.
Re: LXC vs. Docker
#89LXD (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 aligned with my mental model, zero bugs, zero hassle. Canonical builds a great OS, but their Snap/VM org is... not competitive.
Re: LXC vs. Docker
#90LXD (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.