GitLab Object Storage für Skalierung und Performance optimieren

Die Verwaltung von GitLab im Enterprise-Umfeld erfordert eine strategische Konfiguration des Object Storage. Diese Anleitung zeigt, wie Object Storage für maximale Performance, Sicherheit und Zuverlässigkeit über alle GitLab-Komponenten hinweg konfigurieren.

Für deutsche Unternehmen besonders relevant: Diese Konfigurationsoptimierungen reduzieren Infrastructure-Kosten durch geringere Egress-Gebühren und Serverlast. Die systematische Trennung von Komponenten ermöglicht zudem granulare Zugriffskontrolle und vereinfachtes Cost Tracking – beispielsweise für Enterprise-Umgebungen mit Compliance-Anforderungen.

Consolidated Form für GitLab-Komponenten verwenden

Für Artifacts, LFS, Uploads, Packages und weitere GitLab-Daten eliminiert die Consolidated Form die Credential-Duplizierung:

gitlab_rails['object_store']['enabled'] = true

gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'region' => 'us-east-1',
  'use_iam_profile' => true
}

gitlab_rails['object_store']['objects']['artifacts']['bucket'] = 'gitlab-artifacts'

gitlab_rails['object_store']['objects']['lfs']['bucket'] = 'gitlab-lfs'

# ... additional buckets for each object type

Diese Konfiguration reduziert die Komplexität und ermöglicht gleichzeitig verschlüsselte S3-Buckets sowie korrekte Content-MD5-Header.

Container Registry separat konfigurieren

Die Container Registry benötigt eine eigene Konfiguration, da sie die Consolidated Form nicht unterstützt:

registry['storage'] = {
  's3_v2' => {  # Den neuen v2-Treiber verwenden
    'bucket' => 'gitlab-registry',
    'region' => 'us-east-1',
    # Access Keys weglassen für IAM-Rolle
  }
}

Hinweis: Der s3_v1-Treiber ist deprecated und wird in GitLab 19.0 entfernt. Eine Migration zu s3_v2 verbessert Performance und Zuverlässigkeit.

Proxy Download für Performance deaktivieren

proxy_download auf false (Standard) setzen für direkte Downloads:

# Für GitLab-Objekte - global konfigurierbar

gitlab_rails['object_store']['proxy_download'] = false

# Oder granular pro Bucket

gitlab_rails['object_store']['objects']['artifacts']['proxy_download'] = false

gitlab_rails['object_store']['objects']['lfs']['proxy_download'] = false

gitlab_rails['object_store']['objects']['uploads']['proxy_download'] = true  # Beispiel: Proxy für Uploads beibehalten

# Container Registry nutzt standardmäßig Redirect Mode (direkte Downloads)

# Nur bei Bedarf deaktivieren:

registry['storage']['redirect']['disable'] = false  # Auf false belassen

Wichtig: Die proxy_download-Option kann global auf Object-Store-Ebene oder individuell pro Bucket konfiguriert werden. Das ermöglicht Optimierung nach spezifischem Use Case – beispielsweise direkte Downloads für große Artifacts und LFS-Files, aber Proxy für kleinere Uploads mit zusätzlichen Security-Kontrollen.

Diese Konfiguration reduziert die Serverlast und Egress-Kosten erheblich, indem Clients direkt vom Object Storage herunterladen.

Identity-basierte Authentifizierung nutzen

AWS: IAM-Rollen statt Access Keys verwenden:

# GitLab-Objekte

gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'use_iam_profile' => true
}

# Container Registry

registry['storage'] = {
  's3_v2' => {
    'bucket' => 'gitlab-registry',
    'region' => 'us-east-1'
    # Keine Access Keys = IAM-Role-Authentifizierung
  }
}

Google Cloud Platform: Application Default Credentials aktivieren:

gitlab_rails['object_store']['connection'] = {
  'provider' => 'Google',
  'google_application_default' => true
}

Azure: Workload Identities durch Weglassen der Storage Access Keys nutzen.

Verschlüsselungsebenen hinzufügen

Server-side Encryption für zusätzliche Sicherheit aktivieren:

# GitLab-Objekte

gitlab_rails['object_store']['storage_options'] = {
  'server_side_encryption' => 'AES256'
}

# Container Registry

registry['storage'] = {
  's3_v2' => {
    'bucket' => 'gitlab-registry',
    'encrypt' => true
  }
}

Für AWS KMS Encryption den Key-ARN in server_side_encryption_kms_key_id angeben.

Separate Buckets für Organisation verwenden

Dedizierte Buckets für jede Komponente erstellen:

• gitlab-artifacts - CI/CD Job Artifacts

• gitlab-lfs - Git LFS Objects

• gitlab-uploads - User Uploads

• gitlab-packages - Package Registry

• gitlab-registry - Container Images

Diese Isolation verbessert die Sicherheit, ermöglicht granulare Zugriffskontrolle und vereinfacht Cost Tracking.

Zentrale Konfigurations-Unterschiede

Komponente	Consolidated Form	Identity Auth	Verschlüsselung	Direkte Downloads
Artifacts, LFS, Packages	✅ Unterstützt	✅ use_iam_profile	✅ storage_options	✅ proxy_download: false
Container Registry	❌ Separate Config	✅ Access Keys weglassen	✅ encrypt: true	✅ Redirect standardmäßig aktiviert

Migrationspfad

1. Mit GitLab-Objekten beginnen: Consolidated Form für sofortige Komplexitätsreduktion nutzen.

2. Registry separat konfigurieren: s3_v2-Treiber mit IAM-Authentifizierung verwenden.

3. Verschlüsselung aktivieren: Server-side Encryption für beide Komponenten hinzufügen.

4. Performance optimieren: Direkte Downloads mit entsprechenden proxy_download-Einstellungen sicherstellen.

5. Lifecycle Policies einrichten: S3 Lifecycle Rules für unvollständige Multipart-Uploads konfigurieren.

Weitere Ressourcen

Ein vollständiges AWS S3 Konfigurationsbeispiel finden Sie in der GitLab-Dokumentation zum AWS S3 Object Storage Setup.

Details zur Konfiguration von proxy_download-Parametern pro Bucket enthält die GitLab Object Storage Configuration Documentation.

Diese Konfigurationen skalieren mit Ihrem Wachstum und wahren gleichzeitig Sicherheit und Performance. Die Trennung zwischen GitLab Object Storage und Container Registry Configuration spiegelt unterschiedliche zugrunde liegende Architekturen wider – beide profitieren jedoch von denselben Optimierungsprinzipien.