Three-step import
- Tier: Free, Premium, Ultimate
- Offering: GitLab Self-Managed
Import your existing container registry metadata. The following procedure is recommended for larger registries (200 GiB or more), or if you want to minimize downtime while completing the import.
Pre-import repositories (step one)
Users have reported step one import completed at rates of 2 to 4 TB per hour. At the slower speed, registries with over 100TB of data could take longer than 48 hours.
You may continue to use the registry as normal while step one is being completed.
Ensure the database is disabled in the
databasesection to your/etc/gitlab/gitlab.rbfile:registry['database'] = { 'enabled' => false, # Must be false! }Save the file and reconfigure GitLab.
Run the first step to begin the import:
sudo -u registry gitlab-ctl registry-database import --step-one --log-to-stdout
Prerequisites:
- Create an external database.
Add the
databasesection to your/etc/gitlab/gitlab.rbfile, but start with the metadata database disabled:registry['database'] = { 'enabled' => false, # Must be false! 'host' => '<registry_database_host_placeholder_change_me>', 'port' => 5432, # Default, but set to the port of your database instance if it differs. 'user' => '<registry_database_username_placeholder_change_me>', 'password' => '<registry_database_placeholder_change_me>', 'dbname' => '<registry_database_name_placeholder_change_me>', 'sslmode' => 'require', # See the PostgreSQL documentation for additional information https://www.postgresql.org/docs/16/libpq-ssl.html. 'sslcert' => '</path/to/cert.pem>', 'sslkey' => '</path/to/private.key>', 'sslrootcert' => '</path/to/ca.pem>' }Save the file and reconfigure GitLab.
Apply database migrations if you have not done so.
Run the first step to begin the import:
sudo gitlab-ctl registry-database import --step-one
You should try to schedule the following step as soon as possible to reduce the amount of downtime required. Ideally, less than one week after step one completes. Any new data written to the registry between steps one and two, causes step two to take more time.
Import all repository data (step two)
This step requires the registry to be shut down or set in read-only mode;
however, you can expect this step to complete around 90% faster than step one.
Allow enough time for downtime while step two is being executed.
Ensure the registry is set to
read-onlymode.Edit your
/etc/gitlab/gitlab.rband add themaintenancesection to theregistry['storage']configuration. For example, for agcsbackend registry using ags://my-company-container-registrybucket, the configuration could be:## Object Storage - Container Registry registry['storage'] = { 'gcs' => { 'bucket' => '<my-company-container-registry>', 'chunksize' => 5242880 }, 'maintenance' => { 'readonly' => { 'enabled' => true # Must be set to true. } } }Save the file and reconfigure GitLab.
Run step two of the import:
sudo -u registry gitlab-ctl registry-database import --step-two --log-to-stdoutIf the command completed successfully, all images are now fully imported. You can now enable the database, turn off read-only mode in the configuration, and start the registry service:
registry['database'] = { 'enabled' => true, # Must be set to true! } ## Object Storage - Container Registry registry['storage'] = { 'gcs' => { 'bucket' => '<my-company-container-registry>', 'chunksize' => 5242880 }, 'maintenance' => { # This section can be removed. 'readonly' => { 'enabled' => false } } }Save the file and reconfigure GitLab.
Ensure the registry is set to
read-onlymode.Edit your
/etc/gitlab/gitlab.rband add themaintenancesection to theregistry['storage']configuration. For example, for agcsbacked registry using ags://my-company-container-registrybucket, the configuration could be:## Object Storage - Container Registry registry['storage'] = { 'gcs' => { 'bucket' => '<my-company-container-registry>', 'chunksize' => 5242880 }, 'maintenance' => { 'readonly' => { 'enabled' => true # Must be set to true. } } }Save the file and reconfigure GitLab.
Run step two of the import:
sudo gitlab-ctl registry-database import --step-twoIf the command completed successfully, all images are now fully imported. You can now enable the database, turn off read-only mode in the configuration, and start the registry service:
registry['database'] = { 'enabled' => true, # Must be set to true! 'host' => '<registry_database_host_placeholder_change_me>', 'port' => 5432, # Default, but set to the port of your database instance if it differs. 'user' => '<registry_database_username_placeholder_change_me>', 'password' => '<registry_database_placeholder_change_me>', 'dbname' => '<registry_database_name_placeholder_change_me>', 'sslmode' => 'require', # See the PostgreSQL documentation for additional information https://www.postgresql.org/docs/16/libpq-ssl.html. 'sslcert' => '</path/to/cert.pem>', 'sslkey' => '</path/to/private.key>', 'sslrootcert' => '</path/to/ca.pem>' } ## Object Storage - Container Registry registry['storage'] = { 'gcs' => { 'bucket' => '<my-company-container-registry>', 'chunksize' => 5242880 }, 'maintenance' => { # This section can be removed. 'readonly' => { 'enabled' => false } } }Save the file and reconfigure GitLab.
You can now use the metadata database for all operations!
Import remaining data (step three)
Even though the registry is now fully using the database for its metadata, it does not yet have access to any potentially unused layer blobs, preventing these blobs from being removed by the online garbage collector.
You may continue to use the registry as normal while step three is being completed.
To complete the process, run the final step of the migration:
sudo -u registry gitlab-ctl registry-database import --step-three --log-to-stdoutsudo gitlab-ctl registry-database import --step-threeAfter that command exists successfully, registry metadata is now fully imported to the database.