 Hello everyone, I hope you're enjoying Academy and I'd like to entertain you for the coming 40 minutes and hopefully you will also learn something new and useful for your professional work. I'd like to talk to you about SNAPS, a packaging mechanism and a hot new thing in the Linux world. Well, reasonably. I hope you appreciate the first slide though. Okay, a bit about myself. I'm a developer advocate at Canonical. I work on the SNAP slash Snapcraft advocacy team. My job is to bridge the relation between developers outside of Canonical and within Canonical to make sure that together we can have a better developer experience on all levels. Your ideas and ideas that we have in Canonical make sure that everyone gets the best experience. I'm a physicist by vocation, but Linux has been my passion for the last 15, 20 years and I made it into a career at some point. I like to write books and in free time and especially when there's no corona, I like to go to race track days around the world. So next slide. Okay, today I want to talk to you about SNAPS and tell you a little bit more about what they are, what they do, what they're good for and how you can apply them in your day-to-day development work. If you're packaging applications, if you're a user of different applications, where SNAPS can fit in that picture. I'll give you an overview of the architecture of the syntax and how you can publish SNAPS in the SNAPS store. This will be a very quick overview. So some things or topics may look a bit weird or not deep enough. If you have any questions, you can reach out to me by email, which will be on the last slide of this presentation and you can follow up with any questions you have. I can't see you and I can hear your feedback at the moment, but I hope you will appreciate the occasional like joke here and there on this and that slide. So let's start with the definition. What are SNAPS? SNAPS are self-contained applications, archives applications packaged with the idea to be secure and portable. If you're familiar with Linux and you've used Linux and deployed software on Linux, you then know that it's not always trivial. There's relatively low portability of applications between different distributions and even distribution releases. To solve that problem, SNAPS come in with a mechanism of self-containment, meaning the application and the relevant dependencies are all bundled in one archive and you can deploy them on any system that supports SNAPS or the SNAPD service if you will. And if it runs, then it should run reliably and consistently on all those different distributions. Today, the list runs more than 40 different distributions. The Ubuntu family, Debian, Fedora, REL, Slez, Manjaro, Arch, and so forth. And then beyond that, apart from the runtime, there's also the packaging of applications. Again here, idea is to provide a useful practical and a relatively simple mechanism for people to publish their SNAPS. And finally, there's security, which is also important, go side by side with functionality. And one of the advantages is of SNAPS is that there are atomic, reliable transactional updates provided with the packaging mechanism side by side so that end users will always have the latest and greatest available to them for use. We'll touch about this a little bit later on. Going back to the traditional Linux software delivery mechanisms, it's not always been an easy story. Going back to the last 20, 25 years, if you want to package and publish your application across multiple distributions, you do need some familiarity of Linux internals and how things work. The simpler reality is that the application space and the system space are not easily decoupled. There's some level of intermixing interdependency, and this has been known by different names, dependency hell, library hell, shared object hell, DLL hell, however you like it. The thing is, you package your application, and then if something changes one of the dependencies underneath, things can become complicated, applications may break, and you also don't necessarily have portability going from one distro to the other. The fragmentation and the non-transactional nation of this packaging can create problems for software developers and publishers. But then the fact that there is a problem with one doesn't mean that automatically a different solution is the right solution. So in this regard, I'm not here to tell you that SNAPs are the solution to all Linux application problems, and that this is the best, the ultimate packaging mechanism for all purposes. That would be incorrect and misleading. SNAPs have quite a few merits and useful functions in a variety of domains, but there will also be use cases where SNAPs are not the best thing. So in the next few slides, I'd like to show you what they can offer you, and then from there you can deduce whether they fit your use case. And frankly, the answer might be that in some situations, SNAPs may not be the best solution for you guys. Okay, so the first thing is the discovery. There's the SNAP store, which hosts thousands of SNAPs, including some really big name publishers, popular open source software, some games, wine-based applications, which means Windows software, and a whole lot more. The SNAP store and SNAPs are available for anyone to release from 14.04 onwards and 40 plus other distributions. All software is welcome in the store, and it's a portal, or if you will, your one-stop shop to all things SNAPs. You can go there, search for SNAPs, browse categories, figure out if there's something you like, explore and discover new software, or just install something that you require. Then the installations are supposed to be simple, basically one click or one liner, one command line, and that's it. And you should have consistent behavior across multiple distributions. That's one of the core premises. So if it runs well on Fedora, it should also run well on Ubuntu, and vice versa. Because everything is bundled and packaged as a single archive, you should have fewer moving parts, which means fewer opportunities for errors, mistakes, and problems in the software lifecycle. There's another element here, which is quite useful for developers and publishers, and that's analytics. The SNAP store page for every SNAP that exists in the store has a metrics tab that allows publishers and their collaborators to see how their SNAPs are behaving and trending over the last X period, which could be as little as one month, all the way up to five years. And then you can see how SNAPs trend across multiple distributions, across multiple release channels, different versions of your application. And you can also correlate to, say, social media campaigns, specific activities related to your code and so forth. This visibility is another layer of functionality that's not traditionally available in Linux, because when you distribute through the distro channels, each distribution does its own thing. So you may not necessarily know how the aggregate numbers are and how the applications is behaving, which can, in some way, maybe hamper your decisions on how to distribute software. Of course, if you don't care about it, it's perfectly fine. But if you do, then you do have this ability available to you. Lifecycle, it's another important thing. It's quite a bit of an overhead. Once you've released your application, your real job actually just begins. The initial release is only the starting point. And from that point on, you have to take care of bugs and issues and security vulnerabilities, new major releases testing and so forth. So on two levels, one SNAP allow publishers to release updates instantly to their users, a client system that runs SNAPD will, by default, contact the store four times a day. And if there's an update available, it will pull that update, install it in a safe transactional manner, roll back if that update is unsuccessful, and provide security to the end user and also the reliability of delivery to the publisher. The updates are cryptographically signed to reduce the chance of tampering, SNAPs should work even if your system stops receiving updates. So because SNAPs are the couple from the underlying operating system, they have their own management mechanism, which means applications are fully up to date. The system might not be, but you don't really care because the applications are the internet facing side of things where you need to put most of the focus. Finally, you can also publish SNAPs in different channels, going from edge all the way to stable or four levels. And that allows you also to differentiate different versions or different revisions of your software and allow for additional testing and provide additional flexibility and functionality to your users. Okay, so this is kind of like a little promotional piece. Now let's go a little bit into the mechanics of how things are. SNAPs have the SNAP ecosystem, if you will, has four major components. There's the store that we mentioned earlier. Then there is the SNAPD service, which runs on a system and provides the interface to the store. There's the user space component of the service called SNAP. And finally, for developers, there's the SNAPcraft command line tool, which allows you to package and publish your SNAPs. And this is where things become quite interesting. Here's just a little graphics for you to enjoy and appreciate. This took a lot of effort creating these four boxes and lines. So yeah, so back to the series, a bit, SNAPcraft. So it's a command line tool and it's actually quite a nifty and powerful utility. It's a command line tool, which means, all right, you do need to work, be familiar with the command line and be comfortable working in that manner. Once you run SNAPcraft, putting aside for how the pieces in the middle work, your final artifact will be a SNAP, which is a SquashFS file system compressed with the dot SNAP suffix. Inside this archive, there will be all of the necessary application code and library dependencies that allow the SNAP to run independently. Plus, of course, some declarative metadata. So that means that let's say that you have a browser and you want to package that browser as a SNAP, then you will also put all the different audio libraries, video libraries, codecs, and all the other necessary interfaces and elements that your browser will need. So even if they don't exist on the host, they will exist inside the SNAP and provide a functionality, cryptographic libraries, and so forth. To get to that final artifact, the SNAP, you need to use SNAPcraft. And how it works is it basically reads a recipe declared in a file called SNAPcraft.yaml in the YAML format. And if you have done any packaging of this nature before, for instance, say, RPM spec files, it is kind of similar. The recipe that declares certain informative pieces and then you have basically declarative code functions which are then executed when SNAPcraft runs and builds the SNAP. What this actually looks like is, here's a rather trivial example of a command lend utility, it's called weather, it's a weather tool. And it allows you to check current weather for different locations. That's what the binary does when you run it. To package that binary and create the application SNAP, you have these 15 odd lines of code in the YAML syntax. So basically, we have some metadata, then we have the application declaration and the bits and pieces components declaration, which is called parts. I will go into this in a bit more detail in just a few moments. In this particular case, this is a Node.js application and it doesn't have that many components and it's not really complicated. So of course, this doesn't necessarily reflect how difficult or complex things will be when you package SNAPs. But it actually shows you that this is not something completely outlandish and completely foreign. Just a bit of set of declarative instructions and you let the tool know what it needs to do to package the application. So in a bit more detail, the first part of that code that we mentioned earlier is metadata. You provide information by which your application can be searched and cataloged. We have things like name, version, summary, and description. And there are some limits on what you can do and what you can use. It's quite useful to take into account specifically that version is a string. It's not a number. So there is no semantic meaning to what you put into your version. Your version could be a number per se, but it could also be something like Igor 1, Igor 5, or whatever you like. Then there's a summary and then description. You can also use markdown, which will be parsed once you upload your SNAP to the store and shown in the store description. So you can have additional visual elements to appeal to your users and provide differentiation to its functionality as part of that description. The next interesting thing that if you remember what we've seen earlier in the snippet of code is confinement. So a concept that may not look or sound quite familiar from the traditional Linux packaging world is SNAPs are designed to run isolated. And this isolation is on two levels. One, code isolation so that functionality is available and consistent. But there's also the security element. SNAPs are designed to be secure and completely separate from the underlying operating system. And a fully confined SNAP can't really do much. It can't talk to other SNAP. It cannot change anything on the system underneath. And in that form, it's kind of useless. But to make SNAPs useful, there is also a concept of something called interfaces. You can basically punch little holes in the security confinement and allow granular control and granular access to specific system resources. For instance, your browser will need access to the network. It will need access to video and audio resources, maybe USB. But it doesn't necessarily need access to Sys or Proc. Or you don't want to give it access to control the network and so forth. Well, so we'll see that in a second. There are three confinement levels. Strict, which is the default level, and the preferred level. And by default, you have very little access, which you can override with the interfaces. Dev mode is pretty much like strict. However, instead of hard errors, you get soft warnings. And it's useful for developers to figure out what kind of interface overrides they need to provide to make their SNAP functional once they publish it for real, so to speak. And finally, classic is a tricky mechanism. It's an interesting mechanism that provides system level privileges to the SNAP. And it's used as an interim stopgap measure for any application that cannot be currently packaged as strict. It may be packaged like that in the future. Or for applications that need arbitrary access to locations and binaries like, say, IDEs. In that way, you can also have a SNAP that pretty much does anything like a classic normal standard Linux application. That's the last confinement. For the weather example, we had a strict confinement. The isolation pretty much works like this. Each SNAP has its own private space. The SNAPs are mounted as read-only file systems with a separate private writable area. So there's persistence across runs. Confinement is provided between SNAPs and the underlying system with multiple levels. There's C groups, there's SecComp, there are up-armor rules. You can read more about this if you're interested in the SNAP documentation. Or you can contact me and I can give you a much longer and interesting overview. Or given that you have my name from this presentation, just go on to the SNAP web blog and have read in the last couple of months a few interesting articles on these different topics. Another interesting and useful concept that you wouldn't have encountered in the classic Linux world is base. Base is a, well, the best way to describe it is SNAPs need a root file system to run. But they don't actually see the real root file system on your host. They're strictly confined and isolated. So to have something to act as a root file system, there's the concept of base. It's a special kind of SNAP which contains a minimal set of runtime libraries to allow the SNAPs to run on top of them. And usually, bases are matched to an Ubuntu LTS release. So for instance, Core18, a base, is an Ubuntu 1804 LTS set of libraries. That allows SNAPs then to run and think that they're running on top of Ubuntu 1804. So even if you run on Fedora, say, or Slez, your SNAPs will still interface and interact with the Core18 or Core20, for that matter, and be able to use the libraries matching that base. However, there's nothing that stops anyone from developing their own base. You can have a Fedora base. There's a fruits of concept available as a GitHub project. And we actually welcome and invite other people, if they want to, to develop their own bases if they feel there's a need for that. Build definition is the last part of the YAML, and it contains two parts. There's the application definition, where we declare the application and the interface overrides. That's done by keyword plugs, which then says, this application needs to plug in to the network interface and or other interfaces. And then it will have relevant access and functionality. And the parts is the component where we declare the sources from which the application will be assembled. These could be GitHub repos. This could be local files, zip files, the Debian packages, PPAs, and so forth. You have a really wide variety of available sources and then available language plugins like Go, Node, Auto Parts, and so forth, which help you and simplify the packaging process. So if you're not 100% sure how to do some things with plugins, you can actually abstractize lots of the common bits and pieces and just override the things that you need. So basically, here's a slide that pretty much repeats what I just said. You need to pay attention to how you declare your application and what name you give it. Usually those match, but if your Snap contains more than one application, then you will have to give different names, of course. The command keyword will point to the path for the executable inside the Snap. Parts, again, in this specific case, like I said, sources needed to assemble the app. You can override specific source tags and the version control. You can point to different URLs where the parts will be found. Those parts can also be local, they don't have to be online. And if you're building a close source application, then logically you will not provide the sources and they will not be available for anyone than yourself. Snapcraft has lots of commands. It's a complicated and very useful tool. So when you want to build, you just run Snapcraft. But then if you have built and something doesn't look right, you can clean specific parts in the lifecycle. You can initialize a work project. You can then push a Snap to the store, register a Snap name, and so forth. There's really a lot that I can't possibly cover in this presentation. So again, please feel free to contact me and I will gladly guide you through some of the more complicated steps. The idea of Snapcraft is also to help you isolate your work from the underlying system. So when you run Snapcraft, it will not run on your host. It will spawn a virtualized or containerized build environment. It has two backends. It has multi-pass, which creates virtual machines. And it has LXD, which creates lightweight containers. So you can run Snapcraft with either of these two. And inside the container, which will match your build declaration, all the packages will be downloaded, assembled, and built. You will not be polluting or changing your underlying host this way. And that's quite useful because if you pull some libraries that would conflict in real life with your underlying host system, that will not happen. You will not cobble or destroy anything. All of this happens in an ephemeral, destroyable build environment. Once you're done, you can delete the container and no harm done. Once a Snap is created, and this can sometimes take a few takes because you may have errors. You may not have necessarily declared all the relevant information. You may miss a library or two needed for the application and so forth. But in the end, if you're successful, there will be a Snap in the work directory. And Snap will have a name dot Snap. It will have a name dot Snap suffix. Now, once you have the Snap, you can actually inspect what's inside it. So what you can do is unsquash the file system. You can unsquash the Snap and then look inside it. And you will see that it will have a structure that is very similar to a Linux system. There will be a whole bunch of different libraries, sorry, directories like bin, lib, user, userlib, and so forth. It will mimic, in a way, the normal Linux structure, except these libraries and the components inside these directories will run on top of the base that we mentioned earlier. This way, you can also see how Snapcraft works and what it does in the end. It can look a bit complicated, but then once you go into the details, it's kind of self-explanatory in some way. To understand the file format and what's happening inside, you can think of, if you've ever run your own application with your own library overrides with LD Library Path. And so the application components will all be relative to what's inside the Snap. And there is a whole bunch of dollar Snap environment variables that reflect these different locations. For instance, dollar Snap is the read-only installation path, then dollar Snap data is the writable path that resides under var, but then you reflect it with the environment variable inside your Snap, rather than an external path that you cannot access directly. Again, it's not trivial. We can talk about this separately if you're interested in more details. Publishing a Snap, that's your next step. You need to register for a developer account in the Snap Store, then you need to register your app name. Ideally, it will not conflict with an existing one or try to mimic too closely a popular, well-known application for whatever reason. And once you do that, you can push the Snap to the Store. And ideally, it will pass all the checks and be published and available to your end users. You can do this on the command line with Snapcraft login and then Snapcraft push. You should push to a non-stable channel by default because you can't really be sure that everything is perfect and you should allow for some testing, ideally a lot of testing, by your end users. You have, again, a lot of flexibility here because Snap Store channels offer you a multi-dimensional flexibility. You can use tracks to trade between stability and new features. You can have something like track number four and then legacy or whatever risk channels that we mentioned earlier. You can have a beta. You can have Edge candidate stable. And you can even create optional branches for temporary releases and bug fixing for your team. So you could have something that goes into Edge, but that will be called fix number 73. Examples for different tracks, which you can use. Long-term support, major and minor releases, however you feel like about it. Risks, as mentioned before, this is the most important aspect in the sense of quality control. You have the stable channel. You can reference it in multiple ways. Similarly, candidate beta and Edge, your end users have the option to switch between different channels. So if they install a Snap by default, it will be from the stable channel. But then you could go, oh, I want to refresh my Snap from candidates or from Edge and use and try a different version. Another advantage that Snap's have is that you can have parallel installs of the same Snap. So for instance, you can have ocular, ocular one, ocular two, ocular three, ocular four. It will all be ocular Snap, but then each one can reference a different channel. You can have Edge, you can have candidate beta stable. Compare different major versions, try different versions, see how things work out. So like I said, when you upload to the store, don't use stable right away. Start with something less stable. There will be an automatic check of your Snap. And if it fails for security reasons, then there will be a manual review by the store team. Your Snap wants to lens finally and is available to end users should be appealing. So you should make sure that your users can, will want to install your Snap. So you should provide screenshots, videos, descriptions and so forth. You have quite a bit of flexibility here as well. The Snap store is, well, it's in the name, it's a store. So you should make sure that when people search for applications and want to install something, yours will draw the eye and provide maximum useful information to people considering your tools. This was quick, I know. And there are probably a lot of questions. So we have about 10 minutes. I'll try to answer as much as I can. I think the organizers will paste the questions in the notes in big blue button where I am. And I'll answer as much as I can. Just to move on to the next slide, here's my email. So any questions you have on this topic, complaints if you didn't like this, anything you would like to know, I'll be more than glad to help point you to the right sources, get you in touch with the right people, even organize a workshop if you want. So go ahead. Yeah, thanks, Igor. Yes, thank you. Yeah, we have a few questions. So Nate is asking, what do you see as Snap's main advantage over FlapTag? Okay, I love the question, but I'm not. I knew you would. No, but I'm not going to answer it because it will not be fair of me. First, because I work for canonical unbiased, right? So my answer is not valid. I'm not going to talk trash about a competition. I'll give you a more political answer. Choose the best software for your needs. Install Snap, install FlapTag, compare them and see what they give you. Because the answer is always in the end use case, in the end functionality. Maybe for 100,000 people, one will provide the best results ever. But for yourself, that's not relevant because you don't care about that, you care about something else. So that's my political answer. I'm sorry. Yeah, thank you. Next question, Thiago asked, can I build Snaps from any distro other than Ubuntu or do I need to be on Ubuntu to build them? You need to have Snapcraft installed on your system. If it, oh, that's actually a good question. I don't think about it. Eh, it's a good question. I'm not sure. I haven't tried it. I think that if Snapcraft runs on your distro, then go for it. You will need the backend, you will need multipass or LXD to create a virtualized environment. From that point on, once that bootstrap should be fine. But it's actually a good point. I haven't tried it. I'll have to come back to Thiago with this reply. Okay, then next question. How can or can Snaps help simplify building with dependencies from NPM, PIP, RubyGems, and other dev package managers? Okay, so Snapcraft actually has plugins for these languages. There is an NPM plugin, there's a Ruby plugin, and they can help you define, bootstrap, and grab the relevant resources, pull them into your Snap and then assembly application. Electron Builder also can build Snaps as an artifact. Now, this is a very generic reply. The question is, what is a specific use case that you have in mind? And maybe then we can go into details and understand exactly what you need to do. But if you say have a Ruby-based application or you have a Go-based or an NPM-based application, you can do it with Snaps, use the plugin, plugins, get the necessary modules, get the necessary packages assembled and packaged. And you can also provide override to the build definition if there are specific instructions that are not available in what the plugins do. If you go to the Snaps store, you will see that there's a lot of different applications created in different development languages, the development frameworks, and lots of them use these different plugins. Okay, thank you, Igor. That's it for the questions already, yeah. So maybe there's some more discussion happening in the talk chat room, I don't know. Okay. Okay, so for now, thank you, Igor, again. Okay, should I hang around for another five minutes or drop early? I guess we can drop now. Okay, well then I'll just, a couple of closing words. Thank you for listening, if you were listening. Hope you found this useful, interesting, and maybe ever so slightly entertaining. Thank you for the organizers, for the opportunity to speak, and see you around, folks. Thank you. Bye.