Glossary

A set of key terms every user of the Collection should familiarize with

Application

An application, or application software is a product that users can install into their environments to fulfill a necessity. This is the main piece of the collection.

An application can be a database, an API gateway, a load balancer, a runtime, etc. Most applications are cloud-native, but there are also containerized applications for specific purposes. For example, Argo CD (cloud-native application) or Git (containerized application).

Depending on the application type, it will be installed either as a Helm chart or as a Single container.

Artifact

An artifact is the result of packaging the binaries of a component into a distributable unit.

There are 2 main artifact packaging formats:

• Container image: bundles the component binaries for a given version and flavor, on top of a base OS and architecture
• Helm chart: contains pointers to the set of container images needed to run a specific application version and flavor

Artifacts are continuously built, and updated through revisions.

Branch

A branch is a set of versions where backwards compatibility is ensured among them. Each component follows its own branching strategy, as defined in the upstream project. It is assumed that the upstream project follows semantic version.

Application Collection offers all branches available in the upstream project, prioritizing the LTS ones.

Inactive branches

Once the upstream project stops supporting a given branch, we mark it as inactive. This is also known as the branch “end of life” (EOL). An inactive branch should not get updates, thus it is recommended to update to a newer one as soon as possible. Note that, even being inactive, a branch could get updates:

• Because the upstream decided to release an exceptional update due to an important reason
• Because the base of a container image got an update

Component

A component is an identifiable part of an Application that provides a clear interface with other parts. It is common in modern software applications to have several components, such as a relational database or a secret manager. In Application Collection, these applications are described using Helm. Depending on the complexity of the application, we can find required and optional components.

Let’s see a real example. Apache APISIX is an open source, dynamic, scalable and high-performance cloud native API gateway, which uses etcd for storing configuration.

It offers an optional Apache APISIX Dashboard component that makes it as easy as possible for users to operate Apache APISIX through a front-end interface. Additionally, it is also possible to install it with the Apache APISIX Ingress Controller component (a Kubernetes Ingress Controller that uses Apache APISIX as a reverse proxy).

Flavor

Flavors, often referred to as build flavors, enable you to create multiple variations of your application that are tailored to different purposes or target environments. This allows to customize an application for different purposes while using the same core codebase.

For example, Application Collection offers the OpenJDK application in two different flavors: default and dev. The dev flavor is specific for developers, including system packages that might not be necessary for production usage.