November 2024: Feature releases & highlights

Registry UI, Token Usability, and Recommended Readings.

The November releases introduces the following key enhancements:

• UI Support for the Avassa Built-in Registry: You can now view and manage both the Control Tower and Edge Site registries directly from the Control Tower UI, providing easier access to registry insights and housekeeping.
• Enhanced Usability for Tokens: Tokens offer controlled access to Avassa features. We’ve improved their usability with new token generation options in the UI and comprehensive, dedicated documentation.
• “Essentials,” Collection of Recommended Readings: We’ve curated recommended reading collections tailored to different user roles, guiding you through relevant documentation based on your role. Additionally, new documentation covers application variables and a mapping from Docker run and Docker compose to Avassa applications.

UI support for the Avassa built-in Registry

The Avassa Edge Platform offers a fully OCI-compliant image registry within both the Control Tower and edge sites, simplifying and automating your edge application deployments in several ways.

Your applications typically reference a public or private registry where you manage container images. When you save an application specification in Avassa, the Control Tower automatically pulls the image and stores it in its registry. Then, when you deploy the application to edge sites, those sites pull the image directly from the Control Tower registry instead of the external one, making sure that the exact same image is deployed on all your edge sites.

Additionally, each Edge Enforcer includes a built-in registry to store images locally on edge sites. This design ensures applications can restart or migrate on edge sites without needing to connect to the Control Tower registry—or even the original external registry—promoting high availability and autonomy.

The Avassa Edge Platform also maintains a version history of images for quick rollbacks. The registry is automatically replicated across hosts at each site, supporting rapid migration and failover. Automated housekeeping tasks, like removing unused images, help optimize the distributed registry.

These processes occur seamlessly and automatically, reducing manual workload, minimizing error risk, and enhancing edge autonomy. Even though most is automated in the background, inspecting what’s in the control tower registry can be helpful, e.g., in troubleshooting.

🆕 We have added Control Tower UI support so operators can inspect the registries in the Control Tower and at the sites.

In the list of registries to the left, you see the name of the Control Tower registry and any remote registries you have created. The latter is needed if your images are pulled from a registry that requires authentication. If that is not the case, there is no need to define external registries; you can just use the image URL in your application specification.

If you select the Control Tower registry, you can see all images and the referencing applications as shown above to the right.

You can get more information on each item:

⚠️ The Avassa Edge Platform handles container image routine housekeeping automatically, so no manual actions are typically required. However, if you push images to the Control Tower registry directly, those images are currently not automatically garbage collected. This is relevant, for example, in the following use cases:

• You don’t have a dedicated registry for your container and push images directly to the Avassa Edge Platform.
• In an offline scenario, you may need to push a new image version to a site to address an urgent issue.

In these cases, you can use a client like Docker or Podman to push to the Control Tower or Site registry and perform other registry operations as needed.

The example above shows that hello-world is manually pushed; there is no associated application. There is a housekeeping action to delete unused images; this would delete the hello-world image:

To push images to the Control Tower, a helper menu is available, showing a recommended list of commands.

You can also inspect the registry on a site:

This will show the automatically distributed images to the site as a result of a deployment. In the case of site-local offline modifications, where you push an image directly to the site’s registry, you can also validate your image in the UI.

The above illustrations introduced new UI functions for the Control Tower registry. You have been able to inspect the registries using supctl all along. Below are some useful commands.

List repositories in Control Tower:

$ supctl show image-registry repositories 
- name: avassa-public/edge-ai/torchapi
  tags:
    - tag: latest
      digest: sha256:e40f403ffd5a91ffbdb0638c76e872815fe921d3a132ba407273eeeb3bbfdf8b
- name: avassa-public/edge-ai/torchserve
  tags:
    - tag: v1.0
      digest: sha256:c47d7d5db330525207d2644ee6292555c3cfee370a2cd7b229550c15b50c9488

Show details on a specific repository

$ supctl show image-registry repositories avassa-public/movie-theaters-demo/kettle-popper-manager 
name: avassa-public/movie-theaters-demo/kettle-popper-manager
tags:
  - tag: latest
    digest: sha256:27ca0299125baf78014065152a1bd786573e309f15ae3dea9727239966ee0f4e
  - tag: v1.0
    digest: sha256:1ed018b224cd89b1410e364bb0a1d037c14d2534ce42630ff52f8d251f93524a

List repositories on a site

$ supctl show --site electric-cinema  image-registry repositories 
- name: avassa-public/movie-theaters-demo/kettle-popper-manager
  tags: []

There are also actions on the registry and constituent repositories:

$ supctl do image-registry <TAB>
$ supctl do image-registry <REPOSITORY> <TAB>

Another useful command is to list images in a remote registry

$ supctl do image-registry list-remote-images registry.gitlab.com/avassa-public/movie-theaters-demo/kettle-popper-manager:v1.0
images:
  - name: avassa-public/movie-theaters-demo/kettle-popper-manager:v1.0
    digest: sha256:dadd899f7fe436b604183cbe0cc69d2144eea14a3050aff59c6a596d09a2cca7
    type: image-index
    images:
      - digest: sha256:66d89ad90c22706d7a7d9bb94f094239ce91157793bb0ec7d606ca732118a902
        platform: linux/amd64
        image-id: sha256:4b15b5d874cc6defb179e8c6d2fcbbef98a5adab54e59aad7610dd7d436092d3
...

For more information, refer to Avassa registry fundamentals and our how-to guide.

This brings us to the next topic in our monthly highlights: using tokens for fine-grained authentication and access control.

Usability for using tokens

When, for example, pushing an image to the Avassa registry, you could authenticate using a Control Tower username and password. However, this approach has the drawback that the Docker or Podman client will store the password.

Token-based authentication is a more secure alternative for cases where you need to grant temporary or restricted access to a specific feature—whether for a user or a script.

Tokens can be generated to provide time-limited access with permissions defined by a specific access policy, offering a more controlled and secure way to manage access.

Assume the following policy:

$ supctl show policy policies registry-push                                                      
name: registry-push
capabilities:
  registry-push: allow

You can then do:

$ supctl do strongbox token create-token --policies registry-push --ttl 4h
accessor: 0130ceb8-a8c9-4ce2-bb88-a0dedf2f2043
token: e5c45347-c45e-4167-9a4f-e4b06e34b053
creation-time: 2024-11-19T13:52:44.856751Z

With this token, you will be allowed to log in and push to the registry for 4 hours:

$ docker login <ENVIRONMENT>.<TENANT>.avassa.net --username any --password e5c45347-c45e-4167-9a4f-e4b06e34b053
$ docker push ...

Tokens can be used in supctl and APIs, read how.

🆕 To simplify the above, we have added UI support for selecting a policy and then generating a token:

Collection of recommended readings, “essentials”

The Avassa Edge Platform continuously expands with new features, allowing for more comprehensive site configuration and adaptable edge application behavior across various environments. This enhanced functionality means customers can define desired behaviors directly within Avassa without needing to build or manage key concepts externally. Naturally, this has led to a growth in the platform’s documentation.

🆕 To offer more straightforward guidance tailored to different roles, we’ve introduced a new section called “Essentials.” This section provides curated reading lists to help you learn the system effectively based on your specific role.

It provides the following reading lists, each linking to documents across the existing documentation set:

• Creating sites and adding hosts: This section explains how to add sites and hosts to Avassa. It is useful primarily for site providers.
• Defining applications: How to define a container application with associated configuration. Useful primarily for application owners.
• Volumes: How to define volumes at the site and use them in applications. It is helpful for both roles since volumes need to exist on the site for applications to use them.
• Application networks: How do we define and use application networks, such as ingress networks, at the site? This is useful for both roles since network configuration needs to be prepared on the site for applications to use ingress networks, for example.

The Application section now includes a new document explaining various ways to 🆕 use variables within your application. Additionally, we’ve added a helpful 🆕 mapping table that translates Docker Run and Docker Compose configurations into Avassa application specifications. This resource is especially valuable for those with existing container applications, making it easier to get started running them in Avassa.

A quiz: The terminology surrounding container registries is not always well understood. Can you provide rock-solid descriptions of the following?

• Registry
• Repository
• Container Image
• Layer
• Blob
• Digest
• Tag
• Manifest