How to use label matching for application placement

When you have built an application for the edge, it’s time to deploy it to specific sites and hosts with certain characteristics. This would be tedious if you would have to know the exact name of physical sites and hosts. Avassa provides a label-matching deployment scheduler to abstract these details away. Labels exist on sites and hosts within a site and unlock targeted deployments to a selected subset of your locations.

The operations team, responsible for deploying the applications, does not have to specify or know individual site names, but can match against labels for placement. E.g. run this application in stores in Germany or Denmark, or on sites with certain characteristics such as store size, stores with certain security measures, etc.

Tech deep dive: How to place applications based on edge hardware devices

Application developers can specify host (hardware) requirements by using labels, this provides an abstraction layer that shields the developers from having to know intrinsics about the target hardware.

Furthermore, the label matching algorithm can also be evaluated after the first deployment, meaning that applications might “move” to/from sites and containers will match new hardware characteristics within a site.

There are three types of labels, site labels, host labels, and device labels; after reading this article, you will have a solid understanding of how site and host labels work and how to use them. Device labels are automatically set by the system by discovering what devices are attached, more on device labels in this article.

Site Labels

Any site can have any number of user-defined labels. Sites also come with a couple of built-in ones, and they are named system/xxx.

In this example, we have the following labels that are automatically set by the system:

• system/type=edge is a built-in label declaring this is an edge site.
• system/name=gothenburg-bergakungen declares the name of the site.

I have added the following user-defined labels as examples

• small a key only custom label
• country=Sweden
• city=Gothenburg

With labels in place for my four sites, we can start utilizing the labels when deploying applications, e.g.:

The Matched sites in the UI screenshot above show the scheduler’s label evaluation. As shown, this expression would match a single site.

Another example using the small label.

Multiple labels can be combined by using boolean expressions, e.g.

Or, as in this example

After adding the small label to Filmstaden Sergel the deployment will indicate that the application should run at that site as well.

The operator can now choose to redeploy the application and the scheduler will instruct the Filmstaden Sergel site to start the application.

Site Label Summary

Each site can have any number of labels, which are used for scheduling applications to a subset of the available sites.

Host Labels

A site can contain one or more hosts. To allow for granular scheduling of containers to subsets of hosts, labels can be added to individual hosts.

In this example, a single host was labeled fire-protected. In the application specification, we can now instruct the system to run a service on this particular host

name: myapp
version: 2.4.2
services:
  - name: secure-database
    containers:
      - name: mydb
        image: popcorn-systems/mydb:3.2
    mode: replicated
    replicas: 1
    placement:
      match-host-labels: fire-protected

In the example above, the secure-database service, and its constituent containers, will run on matching hosts.

If another host, e.g. with label secure-database, becomes available, the operator can choose to redeploy the application on that site. The scheduler may then decide to move containers to the new host.

Host Label Summary

Host labels are used to control how individual components (services and containers) of an application are scheduled within a site.

Summary

Use site labels to control where an application is placed and host labels to control where an application’s services and containers are placed and value-creating. This is more time-efficient, robust and scalable than an alternative, more manual and infrastructure-centric way-of-working.