Use the built-in MinIO service for object storage
- Tier: Free, Premium, Ultimate
- Offering: GitLab Self-Managed
This migration guide is for when you migrate from a package-based installation to the Helm chart and you want to use the built-in MinIO service for object storage. This is better suited for testing purposes. For production use, you are advised to set up an external object storage
The easiest way to figure out the access details to built-in MinIO cluster is to
look at the gitlab.yml file that is generated in Sidekiq, Webservice and
Toolbox pods.
To grab it from the Sidekiq pod:
Find out the name of the Sidekiq pod:
kubectl get pods -lapp=sidekiqGrab the
gitlab.ymlfile from Sidekiq pod:kubectl exec <sidekiq pod name> -- cat /srv/gitlab/config/gitlab.ymlIn the
gitlab.ymlfile, there is a section for uploads with details of object storage connection. Something similar to the following:uploads: enabled: true object_store: enabled: true remote_directory: gitlab-uploads proxy_download: true connection: provider: AWS region: <S3 region> aws_access_key_id: "<access key>" aws_secret_access_key: "<secret access key>" host: <Minio host> endpoint: <Minio endpoint> path_style: trueUse this information to configure the object storage in the
/etc/gitlab/gitlab.rbfile of the package-based deployment.For connecting to the MinIO service from outside the cluster, the MinIO host URL alone is enough. Helm charts based installations are configured to redirect requests coming to that URL automatically to the corresponding endpoint. So, you don’t need to set the
endpointvalue in the connection settings in/etc/gitlab/gitlab.rb.