What are snaps?
Snaps were introduced a little while back as a cross-distro package format allowing upstreams to easily generate and distribute packages of their application in a very consistent way, with support for transactional upgrade and rollback as well as confinement through AppArmor and Seccomp profiles.
It’s a packaging format that’s designed to be upstream friendly. Snaps effectively shift the packaging and maintenance burden from the Linux distribution to the upstream, making the upstream responsible for updating their packages and taking action when a security issue affects any of the code in their package.
The upside being that upstream is now in complete control of what’s in the package and can distribute a build of the software that matches their test environment and do so within minutes of the upstream release.
Why distribute LXD as a snap?
We’ve always cared about making LXD available to everyone. It’s available for a number of Linux distribution already with a few more actively working on packaging it.
For Ubuntu, we have it in the archive itself, push frequent stable updates, maintain official backports in the archive and also maintain a number of PPAs to make our releases available to all Ubuntu users.
Doing all that is a lot of work and it makes tracking down bugs that much harder as we have to care about a whole lot of different setups and combination of package versions.
Over the next few months, we hope to move away from PPAs and some of our backports in favor of using our snap package. This will allow a much shorter turnaround time for new releases and give us more control on the runtime environment of LXD, making our lives easier when dealing with bugs.
How to get the LXD snap?
Those instructions have only been tested on fully up to date Ubuntu 16.04 LTS or Ubuntu 16.10 with snapd installed. Please use a system that doesn’t already have LXD containers as the LXD snap will not be able to take over existing containers.
- Make sure you don’t have a packaged version of LXD installed on your system.
sudo apt remove --purge lxd lxd-client
- Create the “lxd” group and add yourself to it.
sudo groupadd --system lxd sudo usermod -G lxd -a <username>
- Install LXD itself
sudo snap install lxd
This will get the current version of LXD from the “stable” channel.
If your user wasn’t already part of the “lxd” group, you may now need to run:
Once installed, you can set it up and spawn your first container with:
- Configure the LXD daemon
sudo lxd init
- Launch your first container
lxd.lxc launch ubuntu:16.04 xenial
Channels and updates
The Ubuntu Snap store offers 4 different release “channels” for snaps:
For LXD, we currently use “stable”, “candidate” and “edge”.
- “stable” contains the latest stable release of LXD.
- “candidate” is a testing area for “stable”.
We’ll push new releases there a couple of days before releasing to “stable”.
- “edge” is the current state of our development tree.
This channel is entirely automated with uploads triggered after the upstream CI confirms that the development tree looks good.
You can switch between channels by using the “snap refresh” command:
snap refresh lxd --edge
This will cause your system to install the current version of LXD from the “edge” channel.
Be careful when hopping channels though as LXD may break when moving back to an earlier version (going from edge to stable), especially when database schema changes occurred in between.
Snaps automatically update, either on schedule (typically once a day) or through push notifications from the store. On top of that, you can force an update by running “snap refresh lxd”.
- We don’t currently support live-migration (CRIU) with the LXD snap.
- The “lxd” group must exist prior to installation.
- Updating the snap restarts all LXD containers.
- The “lxd” snap can’t provide the “lxc” command (use “lxd.lxc”).
- LXD always runs even when it’s unused.
Those are all pretty major usability issues and will likely be showstoppers for a lot of people.
We’re actively working with the Snappy team to get those issues addressed as soon as possible and will keep maintaining all our existing packages until such time as those are resolved.
More information on snap packages can be found at: http://snapcraft.io
Bug reports for the LXD snap: https://github.com/lxc/lxd-pkg-ubuntu/issues
The main LXD website is at: https://linuxcontainers.org/lxd
Development happens on Github at: https://github.com/lxc/lxd
Mailing-list support happens on: https://lists.linuxcontainers.org
IRC support happens in: #lxcontainers on irc.freenode.net
Try LXD online: https://linuxcontainers.org/lxd/try-it
PS: I have not forgotten about the remaining two posts in the LXD 2.0 series, the next post has been on hold for a while due to some issues with OpenStack/devstack.
I’m pleased to see this, though I’m well within the showstopper-camp for the time being. Will watch its progression with interest 🙂
I assume you meant “transactional” not “transnational” ?
I do indeed, fixed. Looks like I just used the auto-correct and since transactional isn’t in the dictionary, ended up with transnational 🙂
Stéphane, I think you are a brilliant engineer and, rare gift, a highly competent documentation writer.
Your LXD series sets the bar high for quality step-by-step guidance, and this article is no exception.
I still have your “Ubuntu 12.04 networking” page in my bookmarks as the de-facto reference for networking setup in Ubuntu.
I can’t but wonder why such quality documentation is hosted on your blog instead of being stored in a single, well accessible page on Canonical’s website, maybe under “tutorials” or a similar name. It is pretty hard to hunt down information scattered around blogs, mailing lists, wikis, official docs and manuals.
No intention to point the finger at you, I’m more puzzled by Canonical’s stance on this matter. Documentation quality and retrievability are critical to a project’s success, and I’d love LXD to be more on the radar then how it is now.
Thanks for the work you and your team do.
LXD is pure magic!
I am very impressed with the quality and usability of the whole concept.
Well done. Great to see high quality Software Engineering and documentation
alive and well done Stéphane. Great work. Great concept. Great experience.
I love the idea of LXD becoming a snap. Like you pointed out, and Jason echoed, those are some big gotchas for running in production. I hope it gets fixed soon.
On a similar note, I found at https://lists.ubuntu.com/archives/snapcraft/2016-June/000139.html, that you can’t install snapd and run snaps inside of a LXD container (yet). That’s a real pity, as I think it would be fantastic to be able to do so. It would take LXD and snap packages to another level. Do you have any updates on your comment “My team is actively working on some kernel changes and some changes to snapd itself to allow this to work in the near future.”?
There is one kernel issue left that I’m aware of which is interfering with running snaps in containers, once it’s resolved, I have a blog post ready on running snaps in containers.
I appreciate the advantage of using snap but I am still very very very disappointed to read something like this :
Snapd team seems to absolutely refuse the idea to give a way to disable the auto-update.
I feel they don’t consider the needs of their users.
I like to “control” when I do the upgrade, like, imagine I am away for two month, what if the automatic update broke something (cause human errors will happen, it’s an universal fact, the question is when). And I don’t speak about the refresh restarting lxd containers where you ticket is ignored since 2016 by snapd.
So I hope that backports will still be maintained please ! 🙂
#Was fun to see you in the #debconf2017 ;).
Now i use
root@lxd0x:~/backups/lxd# snap refresh lxd –stable
lxd (4.4/stable) 4.4 from Canonical✓ refreshed
How I should change branch to version 4.6?