mirror of
https://gitlab.kube.huskypup.net/Scooby/Homelabv4.git
synced 2026-08-21 05:26:49 +00:00
Scooby HuskyandClaude Sonnet 5
d99b560cec
3 consecutive attempts with the first loosening (~8min grace) all made genuine progress (booted, started listening on queues) but never got to open the health-check port before being killed - box's sustained background load (gitea, restic, barman, k3s - unrelated to GitLab) is apparently enough to starve that specific thread. More patience, not a different fix. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
276 lines
9.0 KiB
YAML
276 lines
9.0 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.
|
|
# Loosened further 2026-08-21: even with the first pass above, 3
|
|
# consecutive attempts all reached "Booting Sidekiq" (the real
|
|
# engine actually starts, confirmed via "Listening on queues" in
|
|
# logs) but never opened the health-check port (3808) within the
|
|
# ~8min grace window - the box's ambient background load (gitea,
|
|
# restic backup, barman, k3s itself - all unrelated to GitLab, load
|
|
# average sustained 35-55 on 6 cores) is apparently severe enough to
|
|
# starve that specific thread's CPU scheduling even after the main
|
|
# process is otherwise up. Genuine forward progress each time, not
|
|
# a hard hang, so more patience rather than a code fix.
|
|
livenessProbe:
|
|
initialDelaySeconds: 120
|
|
periodSeconds: 30
|
|
timeoutSeconds: 30
|
|
successThreshold: 1
|
|
failureThreshold: 30
|
|
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
|