In Linux, testing software is both easy and difficult at the same time. While the repository channels offer great availability to software, you can typically only install a single instance of an application. If you want to test multiple instances, you will most likely need to configure the remainder yourself. With snaps, this is a fairly simple task.

From version 2.36 onwards, snapd supports parallel install – a capability that lets you have multiple instances of the same snap available on your system, each isolated from the others, with its own configurations, interfaces, services, and more. Let’s see how this is done.

Experimental features & unique identifier

The first step is to turn on a special flag that lets snapd manage parallel installs:

snap set system experimental.parallel-instances=true

Once this step is done, you can proceed to installing software. Now, the actual setup may appear slightly counter-intuitive, because you need to append a unique identifier to each snap instance name to distinguish them from the other(s). The identifier is an alphanumeric string, up to 10 characters in length, and it is added as a suffix to the snap name. This is a manual step, and you can choose anything you like for the identifier. For example, if you want to install GIMP with your own identifier, you can do something like:

snap install gimp_first

Technically, gimp_first does not exist as a snap, but snapd will be able to interpret the format of “snap name” “underscore” “unique identifier” and install the right software as a separate instance.

You have quite a bit of freedom choosing how you use this feature. You can install them each individually or indeed in parallel, e.g. snap install gimp_1 gimp_2 gimp_3. You can install a production version (e.g. snap install vlc) and then use unique identifiers for your test installs only. In fact, this may be the preferred way, as you will be able to clearly tell your different instances apart.

Testing 1 2 3

You can try parallel installs with any snap in the store. For example, let’s setup two instances of odio. Snapd will only download the snap package once, and then configure the two requested instances separately.

snap install odio_first odio_second
odio_second 1 from Canonical✓ installed
odio_first 1 from Canonical✓ installed

From here on, you can manage each instance in its own right. You can remove each one using its full name (including the identifier), connect and disconnect interfaces, start and stop services, create aliases, and more. For instance:

snap remove odio_second
odio_second removed

Different instances, different versions

It gets better. Not only can you have multiple instances, you can manage the release channel of each instance separately. So if you want to test different versions – which can really be helpful if you want to learn (and prepare for) what new editions of an application bring, you can do this in parallel to your production setup, without requiring additional hardware, operating system instances, users – or having to worry about potentially harming your environment.

snap info vlc
name:      vlc
summary:   The ultimate media player
…
channels:
stable:    3.0.7                      2019-06-07 (1049) 212MB -
candidate: 3.0.7                      2019-06-07 (1049) 212MB -
beta:      3.0.7.1-1-6-gdedb3bd       2019-06-18 (1071) 212MB -
edge:      4.0.0-dev-8388-gb425adb06c 2019-06-18 (1070) 329MB -

VLC is a good example, with stable version 3.0.7 available, and preview version 4.0.0 in the edge channel. If you already have multiple instances installed, you can just refresh one of them, e.g.: the aptly named vlc_edge instance:

snap refresh --edge vlc_edge

Or you can even directly install a different version as a separate instance:

snap install --candidate vlc_second
vlc_second (candidate) 3.0.7 from VideoLAN✓ installed

You can check your installed instances, and you will see the whole gamut of versions:

snap list| grep vlc
vlc         3.0.7          1049   stable     videolan*      -
vlc_edge    4.0.0-dev-...  1070   edge       videolan*      -
vlc_second  3.0.7          1049   candidate  videolan*      -

When parallel lines touch

For all practical purposes, these will be individual applications with their own home directory and data. In a way, this is quite convenient, but it can be problematic if your snaps require exclusive access to system resources, like sockets or ports. If you have a snap that runs a service, only one instance will be able to bind to a predefined port, while others will fail.On the other hand, this is quite useful for testing the server-client model, or how different applications inside the snap work with one another. The namespace collisions as well as methods to share data using common directories are described in detail in the documentation. Parallel installs do offer a great deal of flexibility, but it is important to remember that most applications are designed to run individually on a system.

Summary

The value proposition of self-contained applications like snaps has been debated in online circles for years now, revolving around various pros and cons compared to installations from traditional repository channels. In many cases, there’s no clear-cut answer, however parallel installs do offer snaps a distinct, unparalleled [sic] advantage. You have the ability to run multiple instances, multiple versions of your applications in a safe, isolated manner.

At the moment, parallel installs are experimental, best suited for users comfortable with software testing. But the functionality does open a range of interesting possibilities, as it allows early access to new tools and features, while at the same time, you can continue using your production setup without any risk. If you have any comments or suggestions, please join our forum for a discussion.

Photo by Kholodnitskiy Maksim on Unsplash.