April 2022: Feature releases & highlights

Time flies and spring is here! Our amazing engineering team has worked hard during April and launched several releases. We also managed to squeeze in a delayed Christmas party 🧑🏽‍🎄 🎅🏻

Integrate your CI/CD pipeline with Avassa
New web UI frontend for Avassa Cloud Platform
How to integrate Avassa Edge with your central cloud application
Kubernetes integration
Documentation additions
Cliff-hanger

Integrate your CI/CD pipeline with Avassa to automatically deploy applications at the edge

Avassa automates the deployment of containerized applications to your edge sites. Therefore it is natural to integrate Avassa as the last D step in your CI/CD pipeline.

We have added a guide on configuring GitLab and GitHub to push edge application changes to your edge sites by using Avassa. The same technique should be applicable in any CI/CD pipeline. The simple principle is to maintain your Avassa Application and Deployment specifications YAML files in your repository, and controlled changes trigger the complete pipeline.

New Web UI frontend for the Avassa Cloud Platform

In the release highlights for March, we informed about the Web UI facelift for the Control Tower. You will now see the same frontend design for the Avassa Cloud Platform. This is where you manage your different environments before launching Control Tower.

How to integrate Avassa Edge with your central cloud application

Many solutions consist of a central application running in a cloud and companion edge applications. Applications running in the central cloud manage data from all the edge nodes, in many cases, do analytics across all the data received from the edge apps.

The Avassa platform is optimal for running the edge applications on your hardware. The central applications usually run in a private or private cloud, in many cases in a K8S cluster.

We have now provided tutorials and example source code on how to write a central application that interacts with Avassa to manage the edges. As illustrated below, your central application interacts with the edge sites over our published APIs directly if they are reachable or indirect proxied by Control Tower if needed. There is another scenario covered in the tutorial where the edge sites push data to your central application.

The interaction is typically around the two following use cases:

Secrets management: from your central application, you may need to both push secrets to your edge
Events and logs: from your central application, you may need to subscribe to specific event topics from the edges or produce events to specific edge sites

In the first case, you would use the Strongbox APIs, and in the latter, you would use our Volga APIs.

Links to new resources

Tutorial on central and edge integration
Programming with Strongbox
Programming with Volga
Example code repository for the above

Kubernetes integration

As pointed out above, it is common to have a central application in K8S and edge applications managed by Avassa. To make it easier to manage Avassa edge secrets from your central application within K8S, we have provided a K8S Avassa Strongbox secrets integration.

The integration is provided as an init container in Kubernetes to access secrets stored in Strongbox. It can be used to mount the secrets as files and to populate Kubernetes secrets with the contents of a Strongbox vault secret.

The container will read k8s annotations; see below:

  apiVersion: v1
  kind: Pod
  metadata:
    name: auth-demo
    annotations:
      avassa.io/api-host: api.telco.avassa.io
      avassa.io/tenant: telco
      avassa.io/service: minikube
      avassa.io/role: default

Suppose we have an Avassa Strongbox vault called credentials with the following secret:

name: admin
	data:
		password: verysecret
		user: [c](<mailto:jb@bevemyr.com>)lark@kent.com

This secret can be mapped to unique individual files for each data key by adding this annotation

avassa.io/vault.<vault-name>.<secret-name>: files

for example

avassa.io/vault.credentials.admin: files

The integration allows for a similar principle to populate K8S secrets. The procedure is to create a K8S secret with a specific field named strongbox-map. The field should contain a mapping specification on the format

<secret-key>: <vault-name>/<secret-name>/<key-id>

The above mapping specifies that the Avassa vault-name and secret-name will be expanded into a K8S secret.

Below is an example:

apiVersion: v1
kind: Secret
metadata:
	name: db-credentials
	type: Opaque
	stringData:
	strongbox-map: |-
		username: credentials/admin/user
		password: credentials/admin/password

Read more in the K8S secrets integration tutorial.

Documentation additions

Many of you might have started by using the Avassa Web UI. For some use cases a command-line interface might give richer flexibility and more options; meet the Avassa command line supctl. It has been there since the first release, but maybe some of you are not yet fluent in using it. Therefore we have added a [supctl tutorial](https://docs.avassa.io/docs/tutorials/supctl) showing different scenarios and usage options.

The Avassa system has intrinsic support for multi-tenancy. When you start building out your edge sites you acted as a site provider tenant: you own and manage the sites and the constituting hosts. If you are one single organization that both own the sites and the applications you might stop here. You also deploy your applications as the site provider.

But either if you just want to delegate the responsibility within your organization or give access to other organizations to deploy applications to the sites, multi-tenancy is your friend. As a site provider you can create application owner tenants. They are isolated from each other, and they can share (policy-restricted) resources on a site. We have now written a multi-tenancy tutorial explaining and illustrating most of these features.

In summary, documentation updates covered in this month’s Avassa highlights include:

Every highlight needs a cliff-hanger

It is crucial to have health insights into the edge applications and edge sites. You need early warnings if the healthy state is jeopardized on any of the sites or applications. And in case of early warnings, you need drill-down capabilities. We have started a major effort to provide all this in the Web UI along with the ideas put forward in our observability white paper. Our engineering team has been working during April with backend and frontend functions to enable this. You will see a lot of things coming out in future releases, stay tuned for coming releases and highlights 🧗🏼

Highlighted resources