Bridge

Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed
Status: Experiment

Bridge is a web UI and an HTTP API for the GitLab Operator. Use Bridge to create, configure, and upgrade GitLab instances and their add-ons without writing YAML.

Bridge stores what you configure in custom resources. The Operator reads those resources and deploys GitLab to match. You can also write the resources yourself with kubectl or a GitOps tool.

Bridge is an experiment in an early development phase. Its features and its custom resources can change without notice. Do not use it to manage production instances.

Bridge components

Bridge has two parts:

The Bridge UI and API, which the kubectl bridge plugin serves on your own machine. The plugin acts as your kubeconfig identity, so Bridge can do only what you can do with kubectl.
The custom resources of the apps.gitlab.com/v2alpha1 API group, which the Operator in the cluster reconciles.

Kind	Description
`GitLabCore`	A GitLab instance. It replaces the `GitLab` resource of the `apps.gitlab.com/v1beta1` API group.
`GitLabSecrets`	The Secrets that the GitLab chart generates. A `GitLabCore` creates and owns it, so you do not write it yourself.
`Siphon`	A stream of change data capture from the PostgreSQL database of an instance into ClickHouse, through NATS JetStream.
`Orbit`	The GitLab Knowledge Graph, which indexes the data a `Siphon` streams.

For every field of these resources, see the Bridge custom resource reference.

Configure GitLab and its add-ons in one form

The Bridge UI configures a GitLab instance in a form with one section each for the basics, the external dependencies, networking, the GitLab components, and the add-ons. Free-form chart values cover every setting the form does not.

The same form adds the add-ons that the GitLab chart does not bundle, such as Siphon and the GitLab Knowledge Graph (Orbit). Each add-on is a custom resource of its own, deployed from a chart of its own. Bridge creates the resources and connects them to the instance, so you do not write the references between them.

Upgrade across minor versions without downtime

When you raise the version of an instance by more than one minor version, the Operator upgrades it one minor version at a time, without downtime.

GitLab runs batched background migrations asynchronously, after the migrations of an upgrade complete. Before the Operator moves on to the next minor version, it waits until the batched background migrations of the current one are done. You do not check them between the steps yourself. The UI shows an upgrade that waits on them.

Upgrade unattended through upgrade channels

Instead of a fixed chart version, an instance can follow an upgrade channel. The Operator upgrades the instance when GitLab releases a matching version, with no change to the resource:

Channel	Description
`Static`	Runs the chart version you set, and upgrades only when you change it.
`Patch`	Follows the latest patch release of a minor version you choose.
`Latest`	Follows the latest minor version of a major version you choose.
`Previous`	Follows the minor version before the latest one, in a major version you choose.
`OldestSupported`	Follows the oldest minor version that GitLab still supports, in a major version you choose.

An instance never moves to a new major version unattended. To upgrade to the next major version, raise the major version of the channel. If a new version fails its checks before the upgrade starts, the instance keeps running on its current version. If an upgrade fails after it starts, the instance moves on only to a newer patch release of the same minor version.

Run GitLab versions released after the Operator

An instance is not limited to the GitLab chart versions the Operator image bundles. When an instance needs a chart version the Operator does not bundle, the Operator downloads it from the GitLab chart repository, https://charts.gitlab.io/ by default. Unattended upgrades use the same mechanism to follow GitLab releases without an upgrade of the Operator.

Before the Operator renders a downloaded chart, it verifies the chart against the GitLab chart signing key. A chart that fails verification is never deployed, and the instance reports the failure.

Only GitLab charts are downloaded. Siphon and Orbit run only the chart versions the Operator bundles.

Try Bridge in a development environment

Try Bridge only in a development environment, such as a local or disposable cluster. Do not install it in a cluster that runs production or other instances you need to keep. A -bridge image is built from an unreleased branch, and the v2alpha1 custom resource definitions can change without notice.

To try Bridge:

Deploy an Operator with a -bridge image and bridge.enabled set to true, and install the v2alpha1 custom resource definitions. For the steps, see the Bridge developer documentation.
Install the kubectl bridge plugin.
Start the Bridge UI.

To test the migration of an instance that a GitLab resource manages, use an instance in the development environment. For more information, see Migrate a GitLab resource to a GitLabCore.

Was this page helpful?