GitLab updates Container Registry with metadata database to ease storage woes

GitLab updates Container Registry with metadata database to ease storage woes

GitLab is preparing to roll out a version of its Container Registry on that implements a metadata database, allowing the service to unlock many features users have been requesting. The move follows the release of GitLab 14.4, which added scheduled DAST scans and integrated error tracking to the DevOps platform, and GitLab’s IPO earlier this month.

According to GitLab, its updated Container Registry fixes an inherent limitation with the existing implementation, which simply integrated the Docker Distribution registry into GitLab so that users could have a space to publish and share container images. All metadata associated with a given image/tag was stored in the storage backend, making it impractical to build API features like usage visibility and sorting and filtering.

With the updated version of the Container Registry, GitLab has added a metadata database that stores all of the metadata in Postgres instead of the storage backend. This will allow users to get visibility into how much disk space each repository is taking up — which can apparently run to hundreds of gigabytes. It is also expected to deliver performance improvements for list operations when using the GitLab API and UI.

GitLab is undertaking a phased migration of repository metadata, starting with newly-created repositories from October 26. The plan is to roll this out incrementally, to maintain safety for customers and allow the GitLab team to identify and address any concerns. GitLab internal project users will be migrated first, with more details on the migration process available in a GitLab epic.

The move follows the recent release of GitLab 14.4, which added the usual slew of new features. GitLab’s Dynamic Application Security Testing (DAST) now supports scheduled on-demand scans, for example, whereas these could previously only be triggered manually.

Also new is integrated error tracking inside GitLab thanks to a Sentry-compatible backend built into each GitLab instance. This allows users to instrument apps so that errors show up directly in GitLab without the need for a separate Sentry instance.

Another feature adds Remote Repositories for GitLab in Visual Studio Code. GitLab Workflow version 3.33.0 — GitLab’s Visual Studio Code Extension — provides an option to open a remote repository, allowing users to browse a read-only version of a project from their familiar Visual Studio Code environment.

GitLab 14.4 brings with it general availability of the GitLab Operator, which adds the ability to run production instances of GitLab on Kubernetes platforms such as Red Hat OpenShift. A new graph also shows users how groups are adopting DevOps features over time and can give insights into how quickly groups are adopting additional DevOps processes.

GitLab itself went public earlier this month with an IPO on the on Nasdaq stock exchange.