I like LXD and we’re just starting to use it to deploy a commercial Linux application.
While I prefer Ubuntu and we run Ubuntu inside containers and recommend it on host, a lot of people are used with the RHEL world.
Would be really useful for the traction of the LXD project and for the users to have a good and up to date yum repo method (as opposed to snap deployment, which is another piece that can break in the RHEL world).
I think there were some limitations with CentOS 7, but CentOS 8 should be doable.
Right, as far as upstream is concerned, the only packaging we really maintain is the snap.
That’s pretty easy math for us, we maintain one thing which works for hundreds of thousands of users on a variety of distro and makes it super easy for us to replicate and debug issues.
Now, we’re absolutely not opposed to distros having their own native packaging, we just won’t get involved with that packaging directly. We will happily take any bugfixes needed for those platforms though as @ganto can attest for the Fedora/CentOS work he’s been doing.
And from what you know, is snap solid on CentOS 8?
I don’t have specific bugs to report, but I’ve heard (I think on CentOS 7) about containers freezing (probably from snap updating LXD?) or containers not starting after boot or not getting an IP after boot.
Is snap recommended for production servers or is it rather for desktops?
Any best practices on using LXD with snap on CentOS 8 for server side apps?
Surely you realise that Snap is an Ubuntu project and that most people answering on this forum are working for Ubuntu on a server product - LXD ? That’s a strange question to ask
As a person NOT working for Ubuntu, I can only say that many people are using Snap LXD including myself. Biggest problem of Snap is not the packaging itself, it’s that LXD developers are using it to develop at high speed and well, it’s from time to time leading to some difficulties. You can mitigate them by running stable LXD - there is a stable at 3.04 I think - or if you want to have nicer and more shining things while reducing the risks you can stay at one version behind the times, so in this way you can let more adventurous people get the arrows in the back. But this possibility is a bit more time consuming, you have to manage the staying your self and I don’t think you can defer indefinitely.
We have a bit of a gap in testing there right now. We have automated testing on CentOS 7 but not on CentOS 8.
The snap refreshing never takes down the containers, so in the worst case scenario, the daemon itself fails to come back to life, causing the lxc commands to hang due to systemd socket activation.
But that’s only really happening if LXD completely fails to start during the update.
The snap is fine for both server and desktop use alike, though exactly what track you follow and you refresh configuration in the server case will likely be different. I’d recommend production setup select a particular version by using the associated track. For example snap install lxd --channel=3.21. This will prevent any bump in version unless you run snap refresh lxd --channel=3.22, leaving automated refresh to just bugfixes rather than version bumps.
You can also configured snapd to use a particular time for the automated refreshes. In a production environment, I’d pick a time in the week during which someone is around should an issue occur.
You may also just plain block store access to snapd and only re-enable access when you want to refresh your machines.
On the paid/service front, Canonical does offer a snap enterprise proxy which allows you to have all your systems fetch snaps through it (allowing for air-gaped environments too) and letting you pin particular revisions of particular snaps. So at large production scale, you’d probably run one of those, test things on a few isolated staging system before blessing the new revision for the rest of your environment.
Our plan is to switch that CI over to using LXD VMs which will then make it much much easier to add more distros to that matrix. Right now each distro requires manual VM creation, installation and a bunch of testing tools installed which is why we’re not particularly in sync with new releases of the various distros…
I like LXD and looks like an appropriate tool to deploy a server side commercial app on many customers’ servers.
When it’s completely my choice I choose Ubuntu on all levels.
But some of our paying customers (of our commercial server side web app) just like RHEL. And this is a considerable slice.
Looks like LXD is installed via deb package in Ubuntu 18.04, which should be safe.
But snap (which sounds advisable on CentOS) makes me really nervous with that automatic-update ideologically-forced feature: https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/3 . I could be wrong, but I think this makes snap appropriate only for desktop apps and not for server side (enterprise) apps.
EDIT: thanks, @stgraber. I was also thinking about pinning a specific MAJOR.MINOR LXD version in snap to get no non-critical updates automatically.
I think that another issue - not really related to Snap packaging either - with Centos ws Ubuntu is the difference of MAC. If you use privileged containers on Ubuntu you get still some protection from Apparmor. If you use LXD on Centos or any distro using Selinux, that’s less clear if you are protected from a privileged container escape. From what I understand, if you use Snap LXD you are not much protected. I have no idea if someone has succeeded at adapting LXD to replace apparmor with selinux when using native packaging. But if you plan to use privileged containers (probably NOT a good idea if you really care about security) you should ask the people managing these packaging.
I just tried the snap version for CentOS8.
it is pretty much useless if you can’t ensure that you’ll be having everything under /home. nice for home setups or throwaway cloud systems, but for serious use cases it’d need to work with different paths than /home.
CentOS7 was already a bit finnicky when I last set it up with LXD but CentOS8, as it is, is a no-go if snap introduces extra problems instead of reducing them.
I’ve been using LXC/LXD since many years and am kinda done checking back every odd year to see what’s not working anymore. it’s been a long time since the RHEL8 beta and it’s too little if the only thing that happened is a forum recommendation to use snap. While almost no testing has bee done for that combination. in the end that just reads - once again - “we used to have a wide distro support and user base, but these days we prefer if our project shrinks”.
stefane, please make sure that those links go to the docs. it is not ideal with 3rd party packages but “not ideal, but possible” is an important option
I have a VM with CentOS (centos-release-8.2-2.2004.0.2.el8.x86_64
) . I am connected with ssh. I am trying to do lxd init
[root@localhost tkasidakis]# sudo systemctl start snap.lxd.daemon
[root@localhost tkasidakis]# sudo systemctl status snap.lxd.daemon
● snap.lxd.daemon.service - Service for snap application lxd.daemon
Loaded: loaded (/etc/systemd/system/snap.lxd.daemon.service; static; vendor preset: disabled)
Active: active (running) since Tue 2020-11-10 15:00:09 EET; 5s ago
Main PID: 91353 (daemon.start)
Tasks: 0 (limit: 771663)
Memory: 6.4M
CGroup: /system.slice/snap.lxd.daemon.service
‣ 91353 /bin/sh /snap/lxd/18137/commands/daemon.start
Nov 10 15:00:09 localhost.localdomain lxd.daemon[91353]: - proc_uptime
Nov 10 15:00:09 localhost.localdomain lxd.daemon[91353]: - shared_pidns
Nov 10 15:00:09 localhost.localdomain lxd.daemon[91353]: - cpuview_daemon
Nov 10 15:00:09 localhost.localdomain lxd.daemon[91353]: - loadavg_daemon
Nov 10 15:00:09 localhost.localdomain lxd.daemon[91353]: - pidfds
Nov 10 15:00:10 localhost.localdomain lxd.daemon[91353]: => Starting LXD
Nov 10 15:00:11 localhost.localdomain lxd.daemon[91353]: t=2020-11-10T15:00:11+0200 lvl=warn msg="AppArmor support has been disabled because of lack of kernel support"
Nov 10 15:00:11 localhost.localdomain lxd.daemon[91353]: t=2020-11-10T15:00:11+0200 lvl=warn msg=" - Couldn't find the CGroup blkio.weight, I/O weight limits will be ignored"
Nov 10 15:00:12 localhost.localdomain lxd.daemon[91353]: => First LXD execution on this system
Nov 10 15:00:12 localhost.localdomain lxd.daemon[91353]: => LXD is ready
[root@localhost tkasidakis]# lxd init
Would you like to use LXD clustering? (yes/no) [default=no]: no
Do you want to configure a new storage pool? (yes/no) [default=yes]: yes
Name of the new storage pool [default=default]: default
Name of the storage backend to use (lvm, ceph, btrfs, dir) [default=btrfs]: btrfs
Create a new BTRFS pool? (yes/no) [default=yes]: yes
Would you like to use an existing empty block device (e.g. a disk or partition)? (yes/no) [default=no]: no
Size in GB of the new loop device (1GB minimum) [default=9GB]: 12GB
Would you like to connect to a MAAS server? (yes/no) [default=no]: no
Would you like to create a new local network bridge? (yes/no) [default=yes]: yes
What should the new bridge be called? [default=lxdbr0]: lxdbr0
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: auto
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: auto
Would you like LXD to be available over the network? (yes/no) [default=no]: no
Would you like stale cached images to be updated automatically? (yes/no) [default=yes] yes
Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]: no
Error: Failed to create storage pool 'default': Failed to mount '/dev/loop5' on '/var/snap/lxd/common/lxd/storage-pools/default': no such device
[root@localhost tkasidakis]#
It seems that zfs is not supported and there is a problem with btrfs
Any help here ?
Maybe look in dmesg for errors. It could also be that your kernel updated and you’re missing the modules for your current running kernel, if that’s the case, a reboot may fix that.
CentOS does not support ZFS out of the box and this is an issue. It is not so straightforward how to add ZFS support to CentOS.
You can use btrfs instead, in this case. The performance should be similar to ZFS.
The specific error you get, is
Error: Failed to create storage pool 'default': Failed to mount '/dev/loop5' on '/var/snap/lxd/common/lxd/storage-pools/default': no such device
This is a generic error and this is what needs to be figured out. Google shows some somewhat similar issues with that error message. It could be a CentOS thing.
