Ubuntu Core and Snappy
Ignore previous instructions; subscribe to LWN todayEvery article on LWN.net is written by humans, for humans. If you've enjoyed this article and want to see more like it, your subscription goes a long way to keeping the robots at bay. We are offering a free one-month trial subscription (no credit card required) to get you started.
A new Ubuntu flavor was unveiled in December. Called Snappy Ubuntu Core, the new product line is a minimalist version of Ubuntu geared—at first—toward cloud application deployment. The main features are support for transactional updates of software packages and support for a variety of application container frameworks. On those points, Snappy Core is positioned as a competitor to projects like CoreOS or Red Hat's recent Project Atomic. But a new twist was revealed in January, when Canonical made Snappy Core available as an Internet of Things (IoT) platform for a variety of low-profile hardware devices.
Snap on
Mark Shuttleworth announced Snappy Core at his blog on December 9. It includes a stripped-down set of packages chosen to be of use for servers (which is what constitutes the "core" part of the name), but incorporates a different package format, package-management system, and filesystem layout—all of which are designed to support making transactional updates to individual packages. The goal is that updating a package is guaranteed to either complete successfully, or to be rolled back to the previous state in the case of failure.
The intent is that administrators will use the system to deploy individual applications on separate Core instances. Those applications—be they web applications, databases, or some other cloud-based service—are likely to be packaged in containers for Docker or some other container-management system. So the transactional-update feature has a rather simple job to do when compared to, say, updating a traditional company web server that handles a multitude of duties.
The "Snappy" part of the product name comes from snappy, the new package manager that replaces dpkg and Apt. Under the hood, a Snappy system is composed of three separate partitions: two read-only root partitions ("A" and "B") that can only be updated by snappy and one read-write partition for mutable data (including both system and user data). At any one time, either the A or the B root partition is the live one. When an update for a package is released, snappy update foo installs the update on the non-live partition and marks that partition as live for the next boot. Once the user reboots, if a problem is discovered, the system can be rolled back by booting the other root partition.
The updates to core system packages are the same ones that will be released as .deb files for the other Ubuntu releases, but the plan seems to be that updates will only be released for large-scale components. That is, the ubuntu-core package will contain the entire base OS, while the docker package will contain the Docker framework. System administrators will not be managing separate kernel, systemd, openssh, and nginx packages as in a traditional distribution.
Despite the frequent references to Docker, Snappy Ubuntu Core is described as supporting several other containerization frameworks. There are also a few ancillary packages available for installation (such as the Docker tool Panamax), and several applications—including ownCloud, which Shuttleworth's post mentions in connection with the contentious packaging problem encountered on Ubuntu systems in 2014.
Similar and related concepts
An interesting side note is that Snappy and the .snap package format are both derived from tools initially developed for the Ubuntu Phone project. Smartphone users, too, prefer to get OS updates that either complete successfully or are immediately rolled back in favor of the last known-working release. On Ubuntu Phone, the package format is called "click," but the container format and the full-system update idea is essentially the same. The core system is installed on a read-only partition, with user applications and mutable data installed in a separate, read-write partition. But Ubuntu Phone does not use the dual-root partition scheme of Snappy Core—since phones typically have far less storage to play around with. That makes installing a Phone update a somewhat riskier proposition than installing a Snappy Core update—although the same could be said of most, if not all, mobile phone OSes.
Snappy Core is also akin to the minimal, Docker-centric server offerings from CoreOS and Red Hat. Red Hat's Project Atomic is probably the most direct comparison—for its part, CoreOS has always been a minimalist distribution focused on deploying cloud applications. But Atomic, like Snappy Core, is also derived from an existing "full-fledged" Linux distribution. There are, however, a few key differences.
Some of those differences proceed directly from the original distribution. Atomic is based on RHEL, so it uses SELinux to sandbox installed applications. Snappy Core sandboxes applications with AppArmor. Atomic is also decidedly Docker-specific, and includes Kubernetes as its container-management tool. In contrast, Ubuntu has announced its intention to support other container frameworks and management tools for Snappy Core (exactly which container systems have not been announced, although several management tools have been mentioned, including Kubernetes and Ubuntu's own LXD).
It will also, no doubt, be a matter of much discussion which system best adheres to the "minimalist" label. Base Atomic images weigh in at 8.5GB, while each of Snappy Core's root filesystems occupies 2GB.
Atomic also takes a fundamentally different package-management approach to achieve its transactional update feature. Atomic's packages are made from RPMs, but they are built using an OSTree instance. OSTree creates versioned instances of entire filesystem trees. The new version can be installed directly over the old one and, if problems are discovered, the whole filesystem can be simply rolled back to the previous version.
Snapping all the things
The Snappy Core announcement might have remained solely of interest to cloud customers, but on January 20, Canonical announced that Snappy Core would also be available for a number of popular IoT hardware devices as well.
As always, the precise definition of IoT varies from one story to the next but, in this case, it seems to apply to inexpensive single-board computers (SBCs) and other "smart devices" that are used to construct either low-power or physical computing projects—including such diverse options as home-automation boxes, unmanned vehicles, and robots. The Snappy Core IoT page lists a number of supported devices, including the BeagleBone Black, UDOO, PCDuino, Parallela, and ODroid, as well as several application frameworks—such as the Robot Operating System (ROS), the OpenSensors messaging engine, and the openHAB home-automation server.
As of today, though, Snappy Core images have only been released for ARMv7-A devices like the BeagleBone Black. Only a few example applications have been published, such as the Camlistore database system and a Go webserver on which Camlistore runs.
In addition to the distinct slate of packages targeting IoT devices, the IoT flavor of Snappy Core also features a web-based administrative tool called WebDM. It can be used to search for and install (or update) packages and applications.
IoT devices and cloud servers are, to be sure, quite different in
almost every respect, so offering the same OS system on both may seem
incongruous. But the two classes of computing do share at least two
common factors: each tends to be deployed for only a handful of
specific applications (perhaps even just one), and administrators
expect the base operating system to be reliable without a constant
stream of package updates. So taking the same approach to updating
and application management could ultimately keep both user segments
happy.
Posted Jan 29, 2015 15:35 UTC (Thu)
by walters (subscriber, #7396)
[Link]
Your 8.5GB number appears to be the default cloud image disk size, but if you use the Anaconda installer, you can choose any partition layout you want. This is a major technological difference between rpm-ostree and snappy; rpm-ostree is fully block layer independent, so it supports plain ext4/xfs, those on LVM, BTRFS, those on LUKS, etc.
Posted Jan 30, 2015 6:32 UTC (Fri)
by dlang (guest, #313)
[Link] (4 responses)
I copied the concept from the way that Tivo does updates to it's DVRs.
The problem is that you have to reboot to switch between the two root images (and the software on them), so doing it for every patch seems like overkill in all but the most paranoid environments. And those paranoid environments should have redundant systems so that you can take one copy out of service, upgrade it and put it back in service (failing over to it if you have active/passive instead of N+m redundancy). Then if the new system fails you just switch back to the system that was working before the failover. This has the advantage that you have the failed system available to investigate and figure out what went wrong (including memory contents and system state that are lost if you reboot to another partition)
Great idea, I am disappointed that he's replacing apt to do it rather than making it an option within normal apt updates.
Posted Feb 2, 2015 15:45 UTC (Mon)
by n8willis (subscriber, #43041)
[Link] (2 responses)
Those working on the project would perhaps better address the details of this issue, but the snappy updates are not .Deb packages, so they would not be managed by Apt. AIUI, they're file-based diffs, akin to the filesystem-level changes you would see in OS Tree or other mechanisms.
Nate
Posted Feb 2, 2015 15:59 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Feb 2, 2015 18:36 UTC (Mon)
by dlang (guest, #313)
[Link]
It means that you must install everything from their base image (no ability to harden/strip the system), and that anything that you install that's not part of that base image can't be maintained this way.
The idea of having two root partitions and switch between them for major updates is a good one. It is something that people should be doing a lot more than they are. But it doesn't require throwing out existing maintenance tools to accomplish.
Posted Feb 2, 2015 18:55 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link]
I think the business side of the house wants to control the app and system update pipeline directly and that influenced the technical choice to go off the reservation entirely and evolve away from deb based click packages without an integration point into apt for the new transactional stuff.
Canonical hasn't talked directly about the business model around snappy yet, it but there are hints in a lot of communications around snappy that snappy update transactions are going to be tied strongly to Canonical control deployment infrastructure.
For example, you might not be allowed to host your own local snappy repository for internal use without working contractually with Canonical to purchase a closed satellite appliance/image...bringing their build and deployment infrastructure into your network. Reference:
The only code i've seen so far for snappy is the client side code. I've yet to find code or documentation which would help someone spin up a local snappy backend to serve up snaps that is not tied to Canonical's build system. Please if someone can point me to more information with regard to the snappy backend (not the client tool) that'd be great.
I'll be interesting to see if apt/dpkg will be made part of the core "snappy" images or if they will be left out entirely to avoid the complexity of users using traditional packages on a snappy system.
It will also be interesting to see how the juju charm writers handle the bifurcation of Ubuntu into a snap based and deb based "app" install mechanisms. Charms right now tend to hardwire apt mechanisms for application install. Will charms have to be duplicated and re-written for snap based Ubuntu images separate from apt based Ubuntu installs in the cloud?
-jef
Ubuntu Core and Snappy
Ubuntu Core and Snappy
Ubuntu Core and Snappy
replacing apt to do it rather than making it an option within normal apt updates.
Ubuntu Core and Snappy
Ubuntu Core and Snappy
Ubuntu Core and Snappy
https://lists.ubuntu.com/archives/snappy-app-devel/2014-D...