It's a Snap!

     Special Thanks: This article was made possible by support from Linux Professional Institute

Those with a smattering of gray hair might be forgiven for mentioning that containers have been around for a relatively long time and that their evolution is not quite as magical as it may seem at first. Docker [1], however, is an undeniably fantastic advancement in the way infrastructure is created and operated. From a DevOps perspective, software deployments are no doubt possible considerably more often than before. It's unlikely in the long-term however that Docker will be the only popular container runtime daemon as rkt [2] and the Open Container Initiative [3] take off.

Since 2014, a major player in the Linux market has been touting a different type of container that is a real eye-opener. I'll take a look at Canonical's Snapcraft [4] package manager (also called the Snappy package manager), which is a concerted effort to mature and nurture a different way of placing applications in containers.

What, Where, Why

Ubuntu bravely states that snaps can "package any app for every Linux desktop, server, cloud or device, and deliver updates directly." As the product has matured, it's been used in Internet of Things (IoT) technologies and gained some momentum. The premise is that mobile devices, refrigerators, and parking meters should all be able to use portable containers packaged in a way that makes them device agnostic. In other words, you get to run lightweight applications without the fear that missing dependencies will break them. Intrigued? I think you should be.

If you're still not convinced, you should consider this note from the snaps GitHub [5] page before you get started:

Snaps are faster to install, easier to create, safer to run, and they update automatically and transactionally so your app is always fresh and never broken. You can bring your own build infrastructure or use ours.

When you install a snap for the first time, another small snap is also pulled down (at the time of writing, it's around 85MB), known as the core or ubuntu-core snap. It offers other snaps a read-only filesystem that can also rely on basic libraries, an init package (systemd), and networking. This is called an OS snap, because it is a minimal operating system of sorts. The clever part is that this OS snap allows you to run your snaps on any Linux distribution without fear of compatibility issues. Note that these OS snaps won't include the Apt package manager. I'll explain how to develop within an environment like this later.

The high-level view of a snap is that they're actually a SquashFS filesystem filled up with your application. To configure a snap, you mainly focus on a single pre-build config file called snapcraft.yaml, which Ubuntu has described as a fancy ZIP file brimming with all the dependencies you'll ever need for your app. You'd be correct in noticing that YAML-formatted files are taking over the planet.

What are the fundamental differences between a Docker image and a snap, for example? A snap's raison d'être is usually to have a read-only view of the operating system for security reasons and piggyback its networking onto the host's network stack, whereas Docker containers instead focus on being more autonomous (e.g., with their own internal IP address).

Really, snaps are just a different type of container for your app, with the emphasis on being completely portable. The snap will generally be able to access other snaps because they're read-only, and it will have its own predefined, independent writeable filesystem. Systemd also comes into play, and your snap's services are handled by the init daemon in the same way as host services (i.e., stops and starts are handled for you).

One key thing to bear in mind is that, because the filesystems for these autonomous containers are locked away from the host's filesystem, it's important to use relative paths in your snap's configuration and not absolute paths. Otherwise, everything will break!

Strictly Speaking

From a security perspective, the read-only mode to keep successful attacks from persisting after a container stop/restart is very welcome. When running your snaps, you get to choose between three types of confinement: strict , devmode , and classic . The first, strict , is the default; it locks things down and lets you insist that your snap is restricted in only accessing its own install space. Figure 1 shows how this is controlled.

Figure 1: Controlling filesystem access of default strict running mode (source: snapcraft.io [6]).