In the growing IOT world, Embedded devices are playing a major role in people day2day life. Earlier in 1980’s to 2000 embedded product will be having a specific feature such as printing/display etc., and it will be updated only for bug fixes. Now a days in 2022 due to technology growth, a product is having multiple features/use cases and it has been upgraded for bug fixes and new features in the interest of customer/end.
So, if we look in to product upgrade history. in 1990 – 2000 OEM’s use to upgrade a device once in a year, but now the same is getting upgraded at least 10 times in a year. Number varies based on the use case and feature competition.
Now a days feature/application is developed with some dependency on 3rd party components such as Openssl, Cloud Library, Databases, Protobuf etc. These 3rd party component owners share an updated version addressing bug fixes or including new features. OEM must adapt the new versions and release an update for existing products. In this process there are certain challenges inevitable such as i) All modules in product need to be updated. ii) Retesting of all features. iii) Mitigate the impact for existing users etc.
All modules in product need to be updated
Since we cannot have multiple versions of 3rd party component in the product. if the component is getting changed, it’s the responsibility of all module/feature owners to adapt the new component along with their new feature roadmap.
This challenge can be addressed in couple of ways by making product as dockerized or snap based approach. In this way, we no need to wait for all module/feature owners to complete adapting the component to release an upgrade
Here we will look in to snap based approach and how that helps in rolling out new product feature rollout to market in less time.
Legacy Product Architecture
If you have one physical machine dedicated to only one thing this is the best option. Has full access to the hardware and best performance with no overhead.
What is SNAP?
Snap is a Linux-based software utility for packaging and deploying applications. It works with major Linux distributions such as Ubuntu, Debian, Arch Linux, Fedora, CentOS, and Manjaro. Snaps are self-contained apps that run in a sandbox and have limited access to the host system. It uses the.snap file format, which is a single compressed file system that uses the SquashFS standard. Applications and libraries, as well as declarative metadata, make up the file system.
Any Linux based product feature can be packaged as a snap, making it easy to deploy across distributions and devices with isolated environments. Snap has a flexible upgradable or down gradable support that does not affect other snaps/features, this enables secure execution and better transactional management. Snaps can also be upgraded remotely.
Easy and clean installation of full software packages. It can deploy complex systems with all support systems, such as database servers, and everything will be already configured to working perfectly
Elements in SNAP
The Snap’s key elements are as follows:
- Snapd: Snapd used snap metadata to create a safe and secure sandbox for a program on the system. Because Snap is nothing more than SnapDaemon, all of the system’s functions, such as maintaining and administering the complete snap environment, continue in the background.
- Snaps: Snaps are a set of Snap packages that are dependency-free and simple to install. It includes the whole module, including the application and its dependencies, in the.snap file.
- Channels: A channel determines which release of a snap is installed and checked for
updates
$ snap install xxx –channel=latest/edge
- Tracks : There is a default track for all snaps. The default track is called newest unless the snap developer specifies otherwise. When no track is supplied, a snap will install from the latest track by default. It’s also possible to specify the track explicitly.
- Risk Levels : Stable, candidate, beta, and edge are the four risk levels. Installing from a risk-level that is less stable will usually result in more frequent updates.
- Stable: suitable for the great majority of users in production scenarios.
- Candidate: for users who need to test changes prior to a stable deployment, or who want to double-check that an issue has been handled.
- Beta: for users who wish to try out new features before they go live, usually outside of a production environment.
- Edge: for those who wish to keep a close eye on their progress.
Use the –channel option to select a different risk-level
$ snap install –channel=beta xxxx
After installation, the risk-level being tracked can be changed with:
$ snap switch –channel=stable xxxx
- Branches: As a developer, you may have a released programme with defects that users
encounter but that you are unable to duplicate. A temporary branch can be used to store a bug-fixing test
build of the application you’re working on. If you’re tracking and fixing many bugs at the same time, each
one can have its own branch in the Snap Store under the same snap name. Because branches are ‘hidden,’ users
are unlikely to come across potentially broken bug-fix builds of your application unless they guess the
name. Branches are only active for 30 days before being destroyed, and any user with the snap will be
transferred to the channel’s most recent track.
- Snap Store: It is like any other package manager, where the packages are published by creators and consumers install them.
- Snap Craft: It’s a tool to build snaps.
SNAP Updates
The snap list command displays all available revisions for all installed snaps. By specifying a snap name in the snap list —all command, only results for that snap will be returned.
$ snap list –all xxxxx
Snaps are automatically updated. To check for updates manually, run the following command:
$ snap refresh xxxx
With the snap reverse command, a snap can be reverted to a previous revision.
$ snap revert xxxx
SNAP Configuration
The following files control the behavior of a snap:
snap.yaml
hooks
icon.{svg,png}
*.desktop
.yaml : Every snap package contains a meta/snap.yaml file that holds the basic metadata for the snap.
snap.yaml lives inside every snap package, read by snapd. snapcraft.yaml contains instructions to create a snap package, read by the snapcraft command used to build snaps
Hooks: A hook is an executable file that runs within a snap’s confined environment when a certain action occurs. Hooks provide a mechanism for snapd to alert snaps that something has happened, or to ask the snap to provide its opinion about an operation that is in progress.
Common examples of actions requiring hooks include:
Notifying a snap that something has happened
Example: If a snap has been upgraded, the snap may need to trigger a scripted migration process to port an old data format to the new one.
Notifying a snap that a specific operation is in progress
Example: A snap may need to know when a specific interface connects or disconnects.
SNAP Overview
Create your own SNAP
Make your working directory first, then enter there.
$ mkdir snap-workspace
$ cd snap-workspace
A tool for creating snaps is called SnapCraft. Running $ snapcraft init will produce a template in the snap/snapcraft.yaml file.
The directory structure looks like this,
mysnaps/
└── snap-workspace
└── snap
└── snapcraft.yaml
The snapcraft.yaml file looks like if you were to open it.
name: snap-demo
base: core18
version: ‘0.1’
summary: Single-line elevator pitch for your amazing snap
description: This is my-snap’s description.
grade: devel # must be ‘stable’ to release into candidate/stable channels
confinement: devmode # use ‘strict’ once you have the right plugs and slots
Where,
Name: The name of the snap.
Base: A foundation snap that gives users a run-time environment and a small selection of libraries used by most apps. Core18, which is equivalent to Ubuntu 18.04 LTS, is the default setting for the template.
Version: The current version of the snap
Summary: A short, one-line summary or tag-line for your snap.
Description: A longer description of the snap.
Grade: The publisher may use this to express their level of satisfaction with the construction quality. The store will stop ‘devel’ grade builds from being published to the ‘stable’ channel.
Confinement: There are three levels of confinement for snaps: strict, classic, and devmode. The level of confinement a snap has from your system determines how isolated it is.
strict snaps run in complete isolation. Devmode snaps run as strict but with open access to the system, while classic snaps have open access to system resources.
SNAP Compilation:
To build hello world app, add the following ‘parts’ to our snapcraft.yaml file (replace anything else that might be there):
parts:
gnu-hello:
source: http://ftp.gnu.org/gnu/hello/hello-2.10.tar.gz
plugin: autotools
Added a ‘part’ called gnu-hello (its name is arbitrary). The ‘source’ represent, a tarball located on the GNU project’s FTP server. As ‘plugin’ we’ve chosen auto tools which uses the traditional. /configure && make && make install build steps.
To build our snap,
$ snapcraft
Snapcraft will produce a lot of output while the build is underway, but a successful build will result in:
[…]
Staging gnu-hello
+ snapcraftctl stage
Priming gnu-hello
+ snapcraftctl prime
Snapping |
Snapped hello_2.10_amd64.snap
To Install the SNAP,
$ sudo snap install –devmode hello_2.10_amd64.snap
Output:
hello 2.10 installed
To execute,
$ hello
Output:
Hello World