GitLab

Dieser Block installiert GitLab in Kubernetes.

Vor jedem Upgrade muss der Upgradepfad geprüft werden! Siehe: https://gitlab-com.gitlab.io/support/toolbox/upgrade-path/
Chart-Mapping: https://docs.gitlab.com/charts/installation/version_mappings/

Upgrade auf 1.9.x (GitLab 19 / Chart 10)

Aktuell: Block 1.9.4, App 19.2.5, Chart 10.2.5.
Pflicht-Stop vor 19.x: zuletzt 18.11.x (Block 1.8.8 / Chart 9.11.10).
Offizielle Notes: GitLab 19, Chart 10.0, Bundled-Chart Migration.

Vor dem Upgrade (sonst schlägt install fehl):

1. PostgreSQL 17 extern (z.B. CNPG) – bei Bedarf db-migrate / db-migrate-finish aus 1.8.8
2. Redis/Valkey extern (redis.external.enabled: true, Block redis o.ä.)
3. MinIO aus (services.minio.enabled: false), Object Storage über S3
4. Zusätzliche Buckets anlegen: tmpbackups, externalDiffs (mr-diffs), terraformState, ciSecureFiles, agentPlanContent

Danach: poly run gitlab install

Netzwerk (Ingress vs Gateway API)

Chart 10 defaultet auf Gateway API plus gebündeltes Envoy. Dieser Block defaultet weiter auf externes nginx. Chart-Envoy (services.gatewayApi) und Block-Gateway (gateway.*) sind nicht dasselbe.

ingress.enabled und gateway.enabled gegeneinander ausschließen: Gateway-Install setzt ingress.enabled: false.

HTTP / Workhorse (1.9.2)

gateway.enabled: true rendert (templates/gateway.yml.j2):

• cert-manager Certificate (gateway.tls.secret_name, Default gitlab-gateway-tls)
• Gateway gitlab-https auf gateway.gateway_class_name (Default eg-shared, Envoy mergeGateways: true → dieselbe VIP wie andere HTTPS-Listener)
• ClientTrafficPolicy / BackendTrafficPolicy (Timeouts, Buffer)
• dediziertes Service gitlab-workhorse (nur Port 8181, targetPort: 8181 numerisch)
• HTTPRoute Catch-all / → dieses Service

Backend muss Workhorse sein (gateway.service_port: 8181). Port 8080 ist Rails/Metrics. Trifft User-Traffic 8080, 302en /assets auf /users/sign_in (text/html) — Seite ohne CSS/JS.

Nicht gitlab-webservice-default als HTTPRoute-Backend nutzen: das Helm-Service hat mehrere Ports (8080/8181/8083). Envoy/EndpointSlice kann den falschen Port wählen. Deshalb existiert das eigene Workhorse-Service.

Nach einem Backend-Wechsel: HTTPRoute.status.parents[].conditions[].observedGeneration muss der Spec-generation entsprechen. Bleibt observedGeneration hinterher (Envoy-Controller/API-Timeout), 302en /assets weiter auf /users/sign_in (text/html) — Vue-Login bleibt bei „Lade“. Annotation auf der HTTPRoute oder Restart von envoy-gateway erzwingt die Reconcile. SSH/TCP (gateway.tcp) davon unberührt lassen.

gateway.host leer → gitlab. + ingress.hostname (Chart-Konvention).

SSH / TCP (1.9.2)

Clone-URL: services.gitlab_shell.host + services.gitlab_shell.port (global.shell.port).

SSH/TCP nicht zurückbauen, wenn HTTP-Assets gefixt werden.

Application settings / Isolation (app.*)

Die meisten Admin-Settings (Signup, Visibility, Invites) leben in application_settings (DB), nicht in gitlab.yml. Helm kann sie nach dem ersten Boot nicht mehr setzen.

Block-Defaults entsprechen dem Chart (signup: true, apply_settings: false). Lockdown gehoert in workspace.poly. HTTPRoute/TCPRoute bleiben unberuehrt.

Beispiele

examples.poly bzw. polycrate block examples gitlab:

Wenn ein Datenbank upgrade ansteht, müssen folgende actions ausgeführt werden. Es muss zwingend ein gitlab-backups bucket existieren. Siehe: block.config.s3.buckets.backups.

HINWEIS: Wird unmittelbar vor einem db-backup der Bucketname angepasst, muss dieser im "gitlab-toolbox" deployment manuell angepasst werden. (Im Manifest nach - name: BACKUP_BUCKET_NAME suchen)

1. db-backup
2. install
3. db-restore

Ab Gitlab Version 17.X.X wird der alte Gitlab-Runner registration workflow per Default deaktiviert. Dieser kann über den Admin Bereich wieder aktiviert werden: Admin > Settings > CI/CD > Runners > Allow runner registration token

Changelog

Moved to CHANGELOG.poly

actions

db-backup

• Skaliert services runter
• erstellt ein Backup

db-restore

• löscht vorhandene migration jobs
• Restore der DB vom Backup
• Installiert das Helm Chart erneut, damit der Migration Job ausgeführt wird.

db-migrate (PG16 → CloudNativePG 17)

Migriert die gebündelte Bitnami-PostgreSQL-16-DB nach einem externen CloudNativePG-17-Cluster. Dump, Restore und Verify laufen als Kubernetes Jobs (postgres:17) im Cluster. Passwörter kommen aus bestehenden Secrets, der Dump liegt auf der PVC gitlab-pg-migration.

Erwartetes CNPG-Layout (z.B. Block gitlab-db)

• initdb.database/owner: app – Bootstrap-DB, bleibt unberührt
• databases: [{ name: gitlabhq-production, owner: gitlab }] – Ziel der Migration
• roles: [{ name: gitlab }] – Secret <cluster>-role-gitlab (z.B. gitlab-db-role-gitlab)

Voraussetzungen

• CNPG17-Cluster ready, Role gitlab und Database-CR gitlabhq-production vorhanden
• Secrets: gitlab-postgresql-password, gitlab-db-superuser, gitlab-db-role-gitlab
• Technische Defaults liegen im Block unter postgresql.migration.*
• In der Workspace: migration: true

config:
  migration: true

Einfacher Ablauf (empfohlen)

1. poly run gitlab db-migrate
   stop → backup → restore → verify (GitLab bleibt skaliert auf 0)
2. In der Workspace.poly postgresql.external.enabled: true setzen (Host/Secret wie CNPG)
3. poly run gitlab db-migrate-finish
install (GitLab zeigt auf CNPG) → Clients wieder hochfahren
4. In der Workspace.poly migration: falsesetzen

Detaillierter Ablauf / Einzel-Actions

Die kombinierten Actions rufen intern dieselben Schritte auf. Bei Bedarf einzeln nutzbar:

1. db-migrate-stop – speichert Replica-Werte, skaliert webservice/sidekiq/exporter auf 0 (erneutes stop behält den vorherigen State; Fallback: services.*.minReplicas)
2. db-migrate-backup – pg_dump der PG16-Quelle (gitlabhq_production) auf die Migration-PVC
3. db-migrate-restore – pg_restore in die CNPG-DB gitlabhq-production (Owner gitlab); leert die CNPG-managed DB bei Bedarf (kein DROP DATABASE)
4. db-migrate-verify – vergleicht Row-Counts / Indizes / Extensions
5. postgresql.external aktivieren und install ausführen (bzw. db-migrate-finish)
6. db-migrate-start – stellt gespeicherte Replica-Werte wieder her (bei State=0: Fallback auf minReplicas)
7. In der Workspace.poly migration: falsesetzen

install

Jeder S3-Bucket unter config.s3.buckets.* hat name sowie optional eigene access_key_id / secret_access_key. Fehlen die Bucket-Credentials, greifen die globalen s3.access_key_id / s3.secret_access_key. Pro Bucket wird ein Secret gitlab-s3-<bucket> erzeugt (type-specific object storage).

Volle Beispiele inkl. Gateway/TCP: examples.poly / polycrate block examples gitlab.

Vor der installation müssen folgende Buckets angelegt werden:

• gitlab-artifacts
• gitlab-backups
• gitlab-tmp-backups
• gitlab-lfs
• gitlab-packages
• gitlab-uploads
• gitlab-ci-secure-files
• gitlab-mr-diffs
• gitlab-pages
• gitlab-registry-storage
• gitlab-terraform-state
• gitlab-dependency-proxy
• gitlab-agent-plan-content

blocks:
  - name: gitlab
    from: cargo.ayedo.cloud/ayedo/k8s/gitlab:1.9.4
    kubeconfig:
      from: k8s
    config:
      ingress:
        enabled: true
        # gitlab wird im chart angefügt → gitlab.example.com
        hostname: example.com
        tls:
          enabled: true
      gateway:
        enabled: false
      prometheus:
        install: true
      gitaly:
        persistence:
          enabled: true
          size: 50Gi
      postgresql:
        external:
          enabled: true
          host: "gitlab-db-rw.gitlab.svc.cluster.local"
          database: gitlabhq-production
          password:
            secretname: gitlab-db-role-gitlab
      redis:
        external:
          enabled: true
      services:
        gatewayApi:
          enabled: false
          installEnvoy: false
        gitlab_shell:
          proxy_protocol: 
            enabled: false
        gitlab_pages:
          enabled: true
          accesscontrol:
            enabled: true
        registry:
          enabled: true
      s3:
        enabled: true
        region: example
        host: s3.example.com
        endpoint: https://s3.example.com
        access_key_id: *s3-access-key-id
        secret_access_key: *s3-secret-access-key
        path_style: true
        buckets:
          lfs:
            name: gitlab-lfs
          artifacts:
            name: gitlab-artifacts
            access_key_id: *artifacts-access-key-id
            secret_access_key: *artifacts-secret-access-key
          uploads:
            name: gitlab-uploads
          packages:
            name: gitlab-packages
          gitlab_pages:
            name: gitlab-pages
          backups:
            name: gitlab-backups
          tmpbackups:
            name: gitlab-tmp-backups
          externalDiffs:
            name: gitlab-mr-diffs
          terraformState:
            name: gitlab-terraform-state
          ciSecureFiles:
            name: gitlab-ci-secure-files
          agentPlanContent:
            name: gitlab-agent-plan-content
          registry:
            name: gitlab-registry-storage
      omniauth:
        enabled: true
        auto_signin_provider: ""
      oidc:
        enabled: true
        label: "EXAMPLE ID"
        issuer: "https://id.example.com/realms/example"
        identifier: "gitlab"
        secret: "S3cReT"
        redirect_uri: "https://gitlab.example.com/users/auth/openid_connect/callback"

Installation mit Gateway API (Envoy eg-shared)

Chart-Ingress aus. HTTP über Workhorse :8181 (nicht Rails :8080). SSH optional als Envoy-TCPRoute auf der shared VIP (mergeGateways).

blocks:
  - name: gitlab
    from: cargo.ayedo.cloud/ayedo/k8s/gitlab:1.9.4
    kubeconfig:
      from: k8s
    config:
      ingress:
        enabled: false
        hostname: example.com
        tls:
          enabled: true
          cert_manager:
            issuer: letsencrypt-production
      gateway:
        enabled: true
        create_gateway: true
        gateway_class_name: eg-shared
        host: gitlab.example.com
        service_port: 8181
        tls:
          issuer: letsencrypt-production
          secret_name: gitlab-gateway-tls
        tcp:
          enabled: true
          port: 22
      services:
        gatewayApi:
          enabled: false
          installEnvoy: false
        gitlab_shell:
          port: 22
          service_type: ClusterIP
          host: gitlab.example.com
      prometheus:
        install: false
      gitaly:
        persistence:
          enabled: true
          size: 8Gi
          storageClass: longhorn
      postgresql:
        external:
          enabled: true
          host: "gitlab-db-rw.gitlab.svc.cluster.local"
          database: gitlabhq-production
          username: gitlab
          password:
            secretname: gitlab-db-role-gitlab
            secretkey: password
      redis:
        external:
          enabled: true
          host: "valkey-master.gitlab.svc.cluster.local"
          password:
            secretname: valkey-auth
            secretkey: password
      s3:
        enabled: true

uninstall

poly run gitlab uninstall