Announcing an exciting update to the GitLab.com Container Registry

In the coming weeks, we are planning to roll out a new version of the Container Registry on GitLab.com. Prior to deploying this major update, we wanted to clearly communicate the planned changes, what to expect, and why we are excited about this update.

If you have any questions or concerns, please don’t hesitate to comment in the epic.

Context

In milestone 8.8, GitLab launched the MVC of the Container Registry. This feature integrated the Docker Distribution registry into GitLab so that any GitLab user could have a space to publish and share container images.

But there was an inherent limitation with Docker Distribution as all metadata associated with a given image/tag was stored in the storage backend. This made using that metadata to build API features like storage usage visibility and sorting and filtering unfeasible. With the most recent update to the Container Registry, we’ve added a new metadata database that will store all of the metadata in Postgres instead of the storage backend. This will allow us to unblock many of the features that you’ve been asking for.

Why we are excited

• Storage visibility for the container registry
• Performance improvements for list operations when using the GitLab API and UI
• Redesign of the UI, including
  • Build and commit metadata for tags built via CI
  • Search by tag name

The plan

We're planning a phased migration, starting with newly-created repositories. We'll roll this out incrementally to maintain safety for those customers and provide our team with an opportunity to identify and address any concerns.

Timing

We're starting the percentage-based rollout on October 26th, 2021, with GitLab internal projects' customers with less usage, which we expect to take 4 to 6 weeks. For more information about the planned, percentage-based rollout, please refer to this epic.

Once we complete that work, we’ll switch to customers who heavily use the Container Registry for new repositories.

FAQ

• You mentioned new image repositories, but what about existing image repositories?
  • The migration of newly-created repositories is phase 1 of this project. Once complete, we have some planned development work and then will begin to schedule the migration of existing repositories. Please stay tuned or follow along in this epic for more information.
• Do I need to do anything?
  • No, the process is fully automated.
• Is there anything I can do to help?
  • Yes! Although no action is necessary, we recommend activating the Container Registry cleanup policies for any relevant projects. This will make phase 2 of the migration much faster.
• Is the update required?
  • Yes. This change will allow us to deliver a more modern and scalable product and you don’t want to miss out on those features.
• Will there be any downtime?
  • For phase 1 of the migration, which will focus on new image repositories, there is no expected downtime.
• How can we learn more about phase 2?
  • Right now we are focused on phase 1, but please feel free to ask any questions you may have in this epic.