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.
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.
Any site can have any number of user-defined labels. Sites also come with a couple of built-in ones, and they are named
In this example, we have the following labels that are automatically set by the system:
system/type=edgeis a built-in label declaring this is an edge site.
system/name=gothenburg-bergakungendeclares the name of the site.
I have added the following user-defined labels as examples
smalla key only custom label
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
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.
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.
Use site labels to control where an application is placed and host labels to control where an application’s services/containers are placed.