Files
Homelabv4/infrastructure/vps-standby/gitlab/values.yaml
T
Scooby HuskyandClaude Sonnet 5 a9039e0723 Set Recreate deployment strategy for VPS GitLab webservice/sidekiq
RollingUpdate's default surge kept creating a second pod during every
rollout even with 1 replica - on this CPU-overcommitted single-node
VPS that meant 2 concurrent Ruby boots starving each other, never
converging (load avg hit 39+ on 6 cores). Recreate guarantees only 1
pod exists at a time. No availability cost given minReplicas=maxReplicas=1
already.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-20 23:16:56 -05:00

266 lines
8.3 KiB
YAML

# Real GitLab on the VPS - simplified single-node equivalent of
# apps/gitlab/values.yaml (home). Same chart, same version, same
# Authentik OIDC provider/client (shared, see infrastructure/authentik/
# gitlab-blueprint.yaml). Deliberately lighter than home's: no Praefect
# (pointless with 1 Gitaly node), no PgBouncer (direct CNPG connection,
# low enough traffic not to need pooling), no SAML, no Container
# Registry, no KAS - all addable later if actually needed, matches the
# "keep it lighter" decision already made for the rest of vps-standby.
global:
hosts:
domain: vps.huskypup.net
gitlab:
name: gitlab.vps.huskypup.net
# Ingress disabled - own Ingress + Traefik https-redirect Middleware
# handle routing (infrastructure/vps-standby/gitlab/manifests/ingress.yaml)
ingress:
enabled: false
configureCertmanager: false
edition: ce
time_zone: UTC
email:
from: 'gitlab@vps.huskypup.net'
display_name: GitLab (VPS)
reply_to: 'noreply@vps.huskypup.net'
# External PostgreSQL via CNPG (infrastructure/vps-standby/gitlab/manifests/cnpg-cluster.yaml)
psql:
host: pg-gitlab-rw.gitlab.svc.cluster.local
port: 5432
database: gitlabhq_production
username: app
password:
secret: pg-gitlab-app
key: password
# gitlab.kas.enabled: false alone doesn't stop KAS pods deploying -
# there's a SEPARATE global.kas.enabled toggle (default true) that
# actually controls it, found live 2026-08-21.
kas:
enabled: false
# Single Gitaly node, no Praefect - HA routing is pointless with 1 node
gitaly:
enabled: true
internal:
names:
- default
external: []
praefect:
enabled: false
# Standalone Redis (infrastructure/vps-standby/gitlab/manifests/redis.yaml)
redis:
host: redis-gitlab.gitlab.svc.cluster.local
port: 6379
auth:
enabled: true
secret: redis-gitlab-secret
key: password
appConfig:
# CORRECTED 2026-08-21 (see apps/gitlab/values.yaml (home) for the
# full story) - `providers:` list restored, now pointing at
# gitlab-oidc-secret's `provider` key which holds a real
# YAML-encoded provider block (manifests/oidc-secret.yaml), the
# actual mechanism the CNG webservice image processes.
# GITLAB_OMNIBUS_CONFIG below is an omnibus-image-only convention
# this image never reads - always a no-op here.
omniauth:
enabled: true
allowSingleSignOn: ['openid_connect']
blockAutoCreatedUsers: false
autoLinkUser: ['openid_connect']
syncProfileFromProvider: ['openid_connect']
syncProfileAttributes: ['email', 'name']
providers:
- secret: gitlab-oidc-secret
key: provider
# GitLab's pre-upgrade hook checks the deployed version against a
# previous-release ConfigMap to enforce supported upgrade paths - found
# live 2026-08-21 that it fails with "unsupported upgrade path" on a
# genuinely FRESH install too (confirmed: no prior chart-info ConfigMap,
# no Helm release secret, brand new namespace) - a chart/ArgoCD
# interaction quirk (ArgoCD doesn't do real `helm install`, so the
# optional chart-info ConfigMap's absence apparently isn't handled the
# way the script expects). Not relevant for a fresh install anyway - only
# matters for real version-to-version upgrades, which is a future concern
# once this is actually running something to upgrade FROM.
upgradeCheck:
enabled: false
postgresql:
install: false
redis:
install: false
pgbouncer:
enabled: false
# GitLab's own bundled MinIO for object storage (uploads, artifacts) -
# separate from vps-minio (which backs CNPG WAL archiving for other apps)
minio:
persistence:
storageClass: local-path
size: 20Gi
resources:
requests:
cpu: 25m
memory: 256Mi
limits:
memory: 1Gi
registry:
enabled: false
gitlab:
webservice:
minReplicas: 1
maxReplicas: 1
# 1 worker process, not 2 - single-node VPS, already sharing the box
# with several other unrelated services (barman, k3s itself, node/
# gunicorn apps) that keep it chronically CPU-overcommitted (load
# average ~22-26 sustained on 6 cores, confirmed live 2026-08-21,
# unrelated to GitLab). Less to fork/boot per pod start.
workerProcesses: 1
deployment:
# Recreate, not the chart default RollingUpdate - with only 1
# replica, RollingUpdate still surges an extra pod during every
# rollout, and this box can't handle 2 concurrent GitLab Ruby
# boots (confirmed live 2026-08-21: load average spiked past 39
# on 6 cores, each pod starving the other's boot until both got
# liveness-killed - a feedback loop that never converges). No
# real availability cost since there's only 1 replica anyway.
strategy:
type: Recreate
# Chart defaults (initialDelaySeconds:20, periodSeconds:60,
# failureThreshold:3 => ~200s grace) aren't enough on this
# contended box - confirmed live 2026-08-21 the webservice
# (puma) container was repeatedly SIGTERM'd by the liveness
# probe mid-`require` (still loading gems via bootsnap), never
# finishing boot, restarting from zero every time. Loosened so
# a slow boot survives instead of getting killed and restarted
# forever.
livenessProbe:
initialDelaySeconds: 60
periodSeconds: 30
timeoutSeconds: 30
successThreshold: 1
failureThreshold: 15
extraEnvFrom:
GITLAB_OIDC_CLIENT_ID:
secretKeyRef:
name: gitlab-oidc-secret
key: GITLAB_OIDC_CLIENT_ID
GITLAB_OIDC_CLIENT_SECRET:
secretKeyRef:
name: gitlab-oidc-secret
key: GITLAB_OIDC_CLIENT_SECRET
extraEnv:
GITLAB_OMNIBUS_CONFIG: |
gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_allow_single_sign_on'] = ['openid_connect']
gitlab_rails['omniauth_block_auto_created_users'] = false
gitlab_rails['omniauth_auto_link_user'] = ['openid_connect']
gitlab_rails['omniauth_sync_profile_from_provider'] = ['openid_connect']
gitlab_rails['omniauth_sync_profile_attributes'] = ['email', 'name']
gitlab_rails['omniauth_providers'] = [
{
'name' => 'openid_connect',
'label' => 'Authentik',
'args' => {
'name' => 'openid_connect',
'scope' => ['openid', 'profile', 'email'],
'response_type' => 'code',
'issuer' => 'https://auth.kube.huskypup.net/application/o/gitlab/',
'discovery' => true,
'client_auth_method' => 'query',
'uid_field' => 'sub',
'send_scope_to_token_endpoint' => true,
'pkce' => true,
'client_options' => {
'identifier' => ENV['GITLAB_OIDC_CLIENT_ID'],
'secret' => ENV['GITLAB_OIDC_CLIENT_SECRET'],
'redirect_uri' => 'https://gitlab.vps.huskypup.net/users/auth/openid_connect/callback'
}
}
}
]
resources:
requests:
cpu: 150m
memory: 1536Mi
limits:
memory: 3Gi
kas:
enabled: false
gitaly:
persistence:
storageClass: local-path
size: 30Gi
resources:
requests:
cpu: 50m
memory: 256Mi
limits:
cpu: "1"
memory: 1Gi
gitlab-runner:
install: false
gitlab-exporter:
enabled: true
metrics:
enabled: false # no Prometheus on the VPS cluster
sidekiq:
minReplicas: 1
maxReplicas: 1
# Recreate, not RollingUpdate - see gitlab.webservice.deployment.
# strategy above for why.
strategy:
type: Recreate
# Same probe-loosening as webservice.deployment above, same root
# cause (confirmed live 2026-08-21) - sidekiq's own boot was
# getting SIGTERM'd mid-`require` by the liveness probe on this
# CPU-contended box, every ~90-150s, resetting to zero each time
# and never actually finishing.
livenessProbe:
initialDelaySeconds: 60
periodSeconds: 30
timeoutSeconds: 30
successThreshold: 1
failureThreshold: 15
resources:
requests:
cpu: 25m
memory: 384Mi
limits:
cpu: 250m
memory: 1536Mi
certmanager:
install: false
installCRDs: false
prometheus:
install: false
nginx-ingress:
enabled: false
gitlab-runner:
install: false