Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting our team. We will be in touch shortly.Close

  1. Blog
  2. Article

Igor Ljubuncic
on 27 March 2020

Learn snapcraft by example – multi-app client-server snap


Over the past few months, we published a number of articles showing how to snap desktop applications written in different languages – Rust, Java, C/C++, and others. In each one of these zero-to-hero guides, we went through a representative snapcraft.yaml file and highlighted the specific bits and pieces developers need to successfully build a snap.

Today, we want to diverge from this journey and focus on the server side of things. We will give you an overview of a snapcraft.yaml with two interesting components: a) it will have more than one application; typically, snaps come with one application inside b) it will have a simple background service, to which other applications can connect. Let’s have a look.

The basics

Here’s the relevant part of the snapcraft.yaml file:

apps:
  borg:
    command: bin/borg
    daemon: simple
    restart-condition: on-abnormal
    plugs:
      - home
      - network
      - network-bind
  locutus:
    command: bin/locutus
    plugs:
      - home
      - network

What do we have here?

First, we declare the server part of the bundle – an application named borg. It is a simple daemon, and the restart condition will be “on-abnormal” – the service states are based on values returned from systemd.

Second, for the service to work, it needs to be able to bind to network ports, which is why we’re defining the network-bind interface. Please note that if your application needs to bind to a privileged port, you will need sudo to be able to make it run correctly. The use of snaps does not change the underlying security requirements.

We also define access to home (so that the service can read a configuration file, for instance), and network, so it can communicate over the network. This is necessary in addition to the bind declaration, unless your service is designed to only run and listen on localhost.

In the second part, we declare the client part of the bundle – an application that only needs access to the home directory (configuration files, certificates, etc.), and network. This way, you can run the component applications of this snap on various systems, in a classic client-server model.

How to invoke a multi-app snap?

The one question you may have is – with multiple apps inside a snap, how does the user run them? When the app name matches the snap name, e.g.: igor, you only need to run “igor” or “/snap/bin/igor”. Here, the invocation is slightly different. Let’s say the snap is called “picard”. In this case, for the server application, you would run:

picard.borg

Similarly, for the client application:

picard.locutus

Users can manually create aliases to work around this. Similarly, developers can request automatic aliases for their software from the Snap Store team, in cases where there is no obvious namespace clash. This can lead to a smoother, more streamlined user experience. In this example, borg will be mapped to picard.borg, and locutus will be mapped to picard.locutus.

Summary

We hope today’s guide sheds clarity on how to make somewhat more elaborate use cases with snaps, including multi-apps and client-server scenarios. Of course, creating the snapcraft.yaml is only part of the work, you also need to make sure that your software parts can communicate with one another, and do their job correctly. However, at least you have the snapcraft side of things covered.

If you have any comments, or perhaps requests on future articles that would help you snap your application (or a complex service), please join our forum for a discussion.

No Star Trek TNG references were aliased in the creation of this article.

Photo by Marlon Corona on Unsplash.

Related posts


Igor Ljubuncic
16 June 2023

Snapcraft 8.0 and the respectable end of core18

Ubuntu Article

‘E’s not pinin’! ‘E’s passed on! This base is no more! He has ceased to be! ‘E’s expired and gone to meet ‘is maker! ‘E’s a stiff! Bereft of life, ‘e rests in peace! If you hadn’t nailed ‘im to the perch ‘e’d be pushing up the daisies! ‘Is software processes are now ‘istory! ‘E’s ...


Igor Ljubuncic
21 March 2023

Craft team welcomes you to another episode of its adventures

Ubuntu Article

Welcome to the second article in the Craft team saga. Previously, on Craft Team, we gave you a brief introduction into the team’s function, we announced our desire to share the ins and outs of our day-to-day work with the community, and gave you an overview of roughly two weeks of coding and fun. Today, ...


Igor Ljubuncic
16 December 2022

Snapcrafters: 2022 wrap-up

Community Article

This article was written by Merlijn Sebrechts and Dani Llewellyn from the Snapcrafters community. ===== Last year, we officially re-launched the “Snapcrafters” initiative. We’re a community of volunteers who build and maintain unofficial snap packages. Although snaps make it easy for developers to publish their software directly to users, ...