Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitlab-foss.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat (limited to 'doc/administration/packages/container_registry.md')
-rw-r--r--doc/administration/packages/container_registry.md52
1 files changed, 49 insertions, 3 deletions
diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index 384df9a6e6a..dcc6b768eed 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -343,7 +343,7 @@ the Container Registry by themselves, follow the steps below.
In GitLab, tokens for the Container Registry expire every five minutes.
To increase the token duration:
-1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. On the left sidebar, select **Search or go to**.
1. Select **Admin Area**.
1. On the left sidebar, select **Settings > CI/CD**.
1. Expand **Container Registry**.
@@ -500,7 +500,7 @@ To configure the `s3` storage driver for a Linux package installation:
`bucket_name.host/object`. [Set to false for AWS S3](https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-plan-the-rest-of-the-story/).
You can set a rate limit on connections to S3 to avoid 503 errors from the S3 API. To do this,
- set `maxrequestspersecond` to a number within the [S3 request rate threshold](https://repost.aws/knowledge-center/s3-503-within-request-rate-prefix):
+ set `maxrequestspersecond` to a number within the [S3 request rate threshold](https://repost.aws/knowledge-center/http-5xx-errors-s3):
```ruby
registry['storage'] = {
@@ -823,7 +823,7 @@ In the examples below we set the Registry's port to `5010`.
## Disable Container Registry per project
If Registry is enabled in your GitLab instance, but you don't need it for your
-project, you can [disable it from your project's settings](../../user/project/settings/index.md#configure-project-visibility-features-and-permissions).
+project, you can [disable it from your project's settings](../../user/project/settings/index.md#configure-project-features-and-permissions).
## Use an external container registry with GitLab as an auth endpoint
@@ -1252,6 +1252,16 @@ itself on the system so that the `gitlab-ctl` command can bring the registry ser
Also, there's no way to save progress or results during the mark phase of the process. Only once
blobs start being deleted is anything permanent done.
+### Continuous Zero Downtime Garbage Collection **(BETA)**
+
+You can run garbage collection in the background without the need to schedule it or require read-only mode,
+if you migrate to the [metadata database (beta)](#use-a-postgresql-database-for-metadata).
+
+NOTE:
+If you would like to try this [beta feature](../../policy/experiment-beta-support.md#beta),
+you should review the [known limitations](#known-limitations). If you have any feedback,
+you can let us know in the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/423459).
+
## Configure GitLab and Registry to run on separate nodes (Linux package installations)
By default, package assumes that both services are running on the same node.
@@ -1353,6 +1363,42 @@ including all the supported storage backends. To migrate to the GitLab Container
you can follow the instructions on this page, and use the same storage backend as the Distribution Registry.
The GitLab Container Registry should accept the same configuration that you are using for the Distribution Registry.
+## Use a PostgreSQL database for metadata **(FREE SELF BETA)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/423459) in GitLab 16.4 as a [Beta feature](../../policy/experiment-beta-support.md) for self-managed GitLab instances.
+
+WARNING:
+While the metadata database is already in use on GitLab.com, it is in early beta for self-managed GitLab instances.
+
+By default, the container registry uses object storage to persist metadata
+related to container images. This method to store metadata limits how efficiently
+the data can be accessed, especially data spanning multiple images, such as when listing tags.
+By using a database to store this data, many new features are possible, including
+[online garbage collection](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs-gitlab/db/online-garbage-collection.md)
+which removes old data automatically with zero downtime.
+
+This database works in conjunction with the object storage already used by the registry, but does not replace object storage.
+You must continue to maintain an object storage solution even after migrating to a metadata database.
+
+### Known Limitations
+
+- No support for online migrations.
+- Geo Support is not confirmed.
+- Registry database migrations must be ran manually when upgrading versions.
+
+### Migration Instructions and Feedback
+
+Instructions on how to migrate to the database may be found in the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/423459) for the beta period.
+This issue also serves as a place to report issues and to get an overview of the beta status.
+
+### Metadata database feature support
+
+You can migrate existing registries to the metadata database, and use online garbage collection.
+
+Some database-enabled features are only enabled for GitLab.com and automatic database provisioning for
+the registry database is not available. Review the feature support table in the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/423459#supported-feature-status)
+for the status of features related to the container registry database.
+
## Troubleshooting
Before diving in to the following sections, here's some basic troubleshooting: