Compare commits

..
3 Commits
Author SHA1 Message Date
Scooby HuskyandClaude Sonnet 5 83c06a888d GitLab cross-site replication Phase 1c (stage 1): VPS clusters as real replicas
Replaces VPS's independent standalone pg-gitlab (own initdb, own
root/Scooby test data - never meant to survive this, per the approved
plan) with a bootstrap.recovery replica of home's, matching the
pg-authentik precedent. New pg-praefect cluster on the VPS too (never
existed before - VPS ran Gitaly without Praefect).

Stage 1 of 2: recovery-only, no streaming replication config yet - that
needs this cluster's own CNPG-generated certs to exist first, which
only happens once CNPG actually creates the cluster. Stage 2 (next
commit) copies certs cross-cluster and adds externalClusters
connectionParameters + replica.self/primary/source to all four Cluster
CRs (home pg-gitlab/pg-praefect, VPS pg-gitlab/pg-praefect).

postgresql.parameters copied verbatim from home's manifests (must
match-or-exceed, confirmed live for pg-authentik). vps-minio-secret
created manually on the VPS (kubectl, not git - same as every other
cross-cluster secret in this plan) pointing at the VPS's own local
MinIO, which now holds home's pg-gitlab/pg-praefect base backups
(triggered manually via Backup CRs since neither had run yet).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-22 13:19:43 -05:00
Scooby HuskyandClaude Sonnet 5 ca94282552 GitLab cross-site replication Phase 1b: secret material sync
PushSecret (home) + ExternalSecret (VPS) pairs for the four
chart-generated secrets whose values must match before Phase 1c's
Postgres replication goes live: gitlab-rails-secret (secret_key_base/
db_key_base/otp_key_base/openid_connect_signing_key, all in one
secrets.yml key - confirmed live, not four separate keys as first
assumed), gitlab-gitlab-shell-secret, gitlab-gitaly-secret,
gitlab-praefect-secret (the latter two also needed for Phase 2's
cross-site gRPC auth). Same pattern as
infrastructure/authentik/manifests/ha-postgres-app-pushsecret.yaml.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-22 13:08:22 -05:00
Scooby HuskyandClaude Sonnet 5 04fa80ece3 GitLab cross-site replication Phase 1a: Postgres network plumbing
Per the approved plan (jiggly-snacking-iverson.md, 'GitLab True
Cross-Site Replication' section) - replacing the git-mirror CronJob
with real CNPG streaming replication for pg-gitlab and pg-praefect,
reusing the exact pattern already proven for pg-authentik.

This commit is network plumbing only, no DB replication yet:
- Repoint both CNPG clusters' barmanObjectStore backup target from
  in-cluster gitlab-minio-svc to VPS MinIO (also becomes the initial
  seed source for the VPS's replicas in Phase 1c).
- New ha-gitlab-postgres/ha-praefect-postgres NodePort Services
  (bypass CNPG's own -rw Services) on both home and VPS.
- New PeerAuthentication with portLevelMtls PERMISSIVE on the replication
  ports - ambient mesh STRICT default would otherwise reset the
  VPS/witness's connection before the Postgres TLS handshake starts.
- Extended allow-gitlab-access AuthorizationPolicy with a port-scoped
  rule for the same traffic (no source.namespaces rule can match
  external, non-mesh peers).
- CoreDNS rewrites for pg-gitlab.ha.huskypup.net / pg-praefect.ha.huskypup.net
  so home's own pods reach the floating hostname locally instead of
  round-tripping through the WAN forward (no NAT hairpin support).

Still needed before Phase 1b/1c: UniFi WAN port-forwards for external
ports 61442/61443 -> talos-cp-01:32442/32443, source-restricted to the
VPS + witness public IPs (manual, same as the existing 61432 rule).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-22 12:47:03 -05:00
11 changed files with 548 additions and 26 deletions
+13 -5
View File
@@ -53,17 +53,25 @@ spec:
max_parallel_workers_per_gather: "2" max_parallel_workers_per_gather: "2"
max_parallel_workers: "4" max_parallel_workers: "4"
# Backup configuration to MinIO # Backup configuration - repointed to VPS MinIO 2026-08-22 (GitLab
# cross-site replication plan, see
# /home/scooby/.claude/plans/jiggly-snacking-iverson.md's "GitLab True
# Cross-Site Replication" section). Was gitlab-minio-svc (in-cluster,
# same Ceph the backup is meant to protect against). Also doubles as
# the initial-seed source for the VPS's own pg-gitlab replica
# (bootstrap.recovery, Phase 1c) - same barmanObjectStore block serves
# both purposes, matching the Authentik precedent
# (infrastructure/authentik/manifests/cnpg-cluster.yaml).
backup: backup:
barmanObjectStore: barmanObjectStore:
destinationPath: s3://gitlab-backups/pg-gitlab destinationPath: s3://cnpg-backups/pg-gitlab
endpointURL: http://gitlab-minio-svc.gitlab.svc.cluster.local:9000 endpointURL: http://100.108.113.41:9000
s3Credentials: s3Credentials:
accessKeyId: accessKeyId:
name: gitlab-minio-secret name: vps-minio-secret
key: accesskey key: accesskey
secretAccessKey: secretAccessKey:
name: gitlab-minio-secret name: vps-minio-secret
key: secretkey key: secretkey
wal: wal:
compression: gzip compression: gzip
@@ -0,0 +1,99 @@
# GitLab cross-site replication Phase 1b (see
# /home/scooby/.claude/plans/jiggly-snacking-iverson.md) - pushes home's
# chart-generated secrets into Vault so the VPS's ESO can pull them back
# down BEFORE the VPS's Postgres becomes a real replica of home's.
#
# Why this matters: the GitLab chart generates these per-release, at
# random, on first install. Home's and the VPS's values are currently
# different. Once the VPS's Postgres is byte-for-byte replicating home's
# rows, the VPS Rails app will be reading home's encrypted-at-rest data
# (2FA secrets, CI/CD variables, integration tokens, PAT digests,
# application_settings encrypted columns) with the WRONG key unless these
# match - Rails raises OpenSSL::Cipher::CipherError on boot otherwise.
#
# gitlab-gitaly-secret/gitlab-praefect-secret are also needed for
# Phase 2's cross-site gRPC auth (the VPS's Gitaly/Praefect need the same
# tokens home's do, to be trusted as nodes of the same virtual storage).
#
# Same pattern as infrastructure/authentik/manifests/ha-postgres-app-pushsecret.yaml.
# Each of these secrets happens to have exactly one key (confirmed live),
# so one PushSecret + one ExternalSecret per secret, no enumeration needed.
apiVersion: external-secrets.io/v1alpha1
kind: PushSecret
metadata:
name: gitlab-rails-secret-to-vps
namespace: gitlab
spec:
refreshInterval: 5m
secretStoreRefs:
- name: vault-backend
kind: ClusterSecretStore
selector:
secret:
name: gitlab-rails-secret
data:
- match:
secretKey: secrets.yml
remoteRef:
remoteKey: vps/gitlab-rails-secret
property: secrets.yml
---
apiVersion: external-secrets.io/v1alpha1
kind: PushSecret
metadata:
name: gitlab-shell-secret-to-vps
namespace: gitlab
spec:
refreshInterval: 5m
secretStoreRefs:
- name: vault-backend
kind: ClusterSecretStore
selector:
secret:
name: gitlab-gitlab-shell-secret
data:
- match:
secretKey: secret
remoteRef:
remoteKey: vps/gitlab-gitlab-shell-secret
property: secret
---
apiVersion: external-secrets.io/v1alpha1
kind: PushSecret
metadata:
name: gitlab-gitaly-secret-to-vps
namespace: gitlab
spec:
refreshInterval: 5m
secretStoreRefs:
- name: vault-backend
kind: ClusterSecretStore
selector:
secret:
name: gitlab-gitaly-secret
data:
- match:
secretKey: token
remoteRef:
remoteKey: vps/gitlab-gitaly-secret
property: token
---
apiVersion: external-secrets.io/v1alpha1
kind: PushSecret
metadata:
name: gitlab-praefect-secret-to-vps
namespace: gitlab
spec:
refreshInterval: 5m
secretStoreRefs:
- name: vault-backend
kind: ClusterSecretStore
selector:
secret:
name: gitlab-praefect-secret
data:
- match:
secretKey: token
remoteRef:
remoteKey: vps/gitlab-praefect-secret
property: token
+51
View File
@@ -0,0 +1,51 @@
# GitLab cross-site replication (see
# /home/scooby/.claude/plans/jiggly-snacking-iverson.md) - direct copy of
# infrastructure/authentik/manifests/ha-postgres-peerauth.yaml's proven
# fix. The gitlab namespace carries the same ambient-mesh STRICT default
# as authentik; without this, ztunnel resets the VPS/witness's connection
# (no mesh identity - they're not in this cluster) before the Postgres
# TLS handshake can even start, surfacing as "server closed the
# connection unexpectedly" on the replica side despite the NodePort/
# firewall path being entirely correct.
#
# Scoped to just each CNPG primary pod's ports via portLevelMtls, not the
# whole namespace - GitLab's own in-mesh east-west traffic (webservice
# <-> gitaly <-> redis <-> sidekiq <-> praefect) stays STRICT.
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: allow-ha-gitlab-postgres-replication
namespace: gitlab
spec:
selector:
matchLabels:
cnpg.io/cluster: pg-gitlab
mtls:
mode: STRICT
portLevelMtls:
"5432":
mode: PERMISSIVE
# Floating-hostname port (see ha-postgres-nodeport.yaml) - needs its
# own entry, ambient's port-level mTLS enforcement is keyed on the
# port actually dialed (61442), not just the pod's real containerPort
# (5432) it eventually reaches (confirmed live for the authentik
# precedent, same mechanism here).
"61442":
mode: PERMISSIVE
---
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: allow-ha-praefect-postgres-replication
namespace: gitlab
spec:
selector:
matchLabels:
cnpg.io/cluster: pg-praefect
mtls:
mode: STRICT
portLevelMtls:
"5432":
mode: PERMISSIVE
"61443":
mode: PERMISSIVE
@@ -0,0 +1,56 @@
---
# GitLab cross-site replication (see
# /home/scooby/.claude/plans/jiggly-snacking-iverson.md's "GitLab True
# Cross-Site Replication" section) - direct copy of the proven pattern
# from infrastructure/authentik/manifests/ha-postgres-nodeport.yaml.
# Exposes pg-gitlab's and pg-praefect's current primaries to the
# VPS/witness over the Netbird mesh for streaming replication - same
# selectors CNPG's own -rw ClusterIP Services use, just NodePort instead,
# since CNPG doesn't manage these objects and won't fight with them.
# Needs infrastructure/kyverno/policies/ha-failover-nodeport-exception.yaml
# (name pattern ha-* already matches, no change needed there).
#
# Second port on each (61442/61443, ClusterIP only) for the CoreDNS
# rewrite in infrastructure/coredns/manifests/: home's own pods resolving
# pg-gitlab.ha.huskypup.net / pg-praefect.ha.huskypup.net rewrite to
# THESE services specifically so they can reach them on the SAME port
# number the app tier will eventually be configured with (Phase 3) -
# rewrite only changes the resolved NAME, not the port a client then
# connects to (confirmed live for the authentik precedent).
apiVersion: v1
kind: Service
metadata:
name: ha-gitlab-postgres
namespace: gitlab
spec:
type: NodePort
selector:
cnpg.io/cluster: pg-gitlab
cnpg.io/instanceRole: primary
ports:
- name: nodeport-5432
port: 5432
targetPort: 5432
nodePort: 32442
- name: floating-port-61442
port: 61442
targetPort: 5432
---
apiVersion: v1
kind: Service
metadata:
name: ha-praefect-postgres
namespace: gitlab
spec:
type: NodePort
selector:
cnpg.io/cluster: pg-praefect
cnpg.io/instanceRole: primary
ports:
- name: nodeport-5432
port: 5432
targetPort: 5432
nodePort: 32443
- name: floating-port-61443
port: 61443
targetPort: 5432
@@ -26,10 +26,53 @@ spec:
primaryUpdateStrategy: unsupervised primaryUpdateStrategy: unsupervised
# Explicit params added 2026-08-22 (GitLab cross-site replication plan)
# - this cluster ran on bare Postgres defaults before. A VPS replica
# can't replay WAL past a checkpoint recorded with higher settings than
# its own ("recovery aborted because of insufficient parameter
# settings", confirmed live for pg-authentik) - giving both sides an
# identical explicit block up front means nobody can tune one side
# later and silently break replication.
postgresql:
parameters:
max_connections: "200"
shared_buffers: "512MB"
effective_cache_size: "1536MB"
maintenance_work_mem: "128MB"
checkpoint_completion_target: "0.9"
wal_buffers: "16MB"
default_statistics_target: "100"
random_page_cost: "1.1"
effective_io_concurrency: "200"
work_mem: "4MB"
min_wal_size: "1GB"
max_wal_size: "4GB"
max_worker_processes: "4"
bootstrap: bootstrap:
initdb: initdb:
database: praefect_production database: praefect_production
owner: app owner: app
# Backup to VPS MinIO, also the initial-seed source for the VPS's own
# pg-praefect replica (bootstrap.recovery, Phase 1c) - this cluster had
# no backup block at all before. See the matching comment on
# cnpg-cluster.yaml (pg-gitlab) in this same directory.
backup:
barmanObjectStore:
destinationPath: s3://cnpg-backups/pg-praefect
endpointURL: http://100.108.113.41:9000
s3Credentials:
accessKeyId:
name: vps-minio-secret
key: accesskey
secretAccessKey:
name: vps-minio-secret
key: secretkey
wal:
compression: gzip
maxParallel: 2
retentionPolicy: "30d"
monitoring: monitoring:
enablePodMonitor: true enablePodMonitor: true
@@ -58,6 +58,15 @@ data:
# specifically so this rewrite target actually has that port. # specifically so this rewrite target actually has that port.
rewrite name pg-authentik.ha.huskypup.net ha-authentik-postgres.authentik.svc.cluster.local rewrite name pg-authentik.ha.huskypup.net ha-authentik-postgres.authentik.svc.cluster.local
# GitLab cross-site replication (see
# /home/scooby/.claude/plans/jiggly-snacking-iverson.md) - same
# reasoning as pg-authentik.ha.huskypup.net above: home's own pods
# go straight to the local NodePort Service instead of round-
# tripping out through the UniFi WAN forward and back in (no NAT
# hairpin support, confirmed live for the authentik precedent).
rewrite name pg-gitlab.ha.huskypup.net ha-gitlab-postgres.gitlab.svc.cluster.local
rewrite name pg-praefect.ha.huskypup.net ha-praefect-postgres.gitlab.svc.cluster.local
kubernetes cluster.local in-addr.arpa ip6.arpa { kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure pods insecure
fallthrough in-addr.arpa ip6.arpa fallthrough in-addr.arpa ip6.arpa
@@ -83,6 +83,23 @@ spec:
- source: - source:
ipBlocks: ipBlocks:
- "10.244.0.0/16" - "10.244.0.0/16"
# GitLab cross-site replication (see
# /home/scooby/.claude/plans/jiggly-snacking-iverson.md): CNPG
# streaming replication from the VPS/witness, arriving via the
# ha-gitlab-postgres/ha-praefect-postgres NodePorts - no mesh
# identity at all, so no source.namespaces rule above can match them.
# Scoped by destination port instead, matching the port-scoped
# PERMISSIVE PeerAuthentication in ha-peerauth.yaml (same root cause,
# same fix, one layer up - mTLS being allowed through isn't enough by
# itself, this ALLOW policy independently denies anything not
# matching one of the rules above). Same pattern already proven for
# Authentik in infrastructure/istio/manifests/mesh/authorization-policies.yaml.
- to:
- operation:
ports:
- "5432"
- "61442" # pg-gitlab floating-hostname port, see ha-postgres-nodeport.yaml
- "61443" # pg-praefect floating-hostname port, see ha-postgres-nodeport.yaml
--- ---
# --- n8n: Allow ingress + Prometheus + intra-namespace --- # --- n8n: Allow ingress + Prometheus + intra-namespace ---
@@ -1,8 +1,24 @@
--- ---
# Real GitLab on the VPS - simplified single-node equivalent of # GitLab cross-site replication Phase 1c (see
# apps/gitlab/manifests/cnpg-cluster.yaml (home's is 3-instance HA with # /home/scooby/.claude/plans/jiggly-snacking-iverson.md) - was a fully
# Rook-Ceph; this is 1 instance on local-path, matching the "keep it # independent standalone cluster (own initdb, own root/Scooby test data,
# lighter" pattern already used for the rest of vps-standby). # never meant to survive this). Now a real replica of home's pg-gitlab
# (apps/gitlab/manifests/cnpg-cluster.yaml), matching the pattern already
# proven for pg-authentik.
#
# Deployed in two stages, same as the original authentik/n8n/nextcloud
# VPS replicas were: first as a plain bootstrap.recovery replica (this
# commit - no externalClusters/replica streaming config yet, since that
# needs THIS cluster's own CNPG-generated certs to exist first, which
# only happens once the cluster itself exists), then a second commit adds
# the streaming replication config once those certs have been copied
# cross-cluster.
#
# postgresql.parameters MUST match-or-exceed home's - copied verbatim
# from apps/gitlab/manifests/cnpg-cluster.yaml. A replica can't replay
# WAL past a checkpoint recorded with higher settings than its own
# ("recovery aborted because of insufficient parameter settings",
# confirmed live for pg-authentik).
apiVersion: postgresql.cnpg.io/v1 apiVersion: postgresql.cnpg.io/v1
kind: Cluster kind: Cluster
metadata: metadata:
@@ -12,43 +28,62 @@ spec:
imageName: ghcr.io/cloudnative-pg/postgresql:16 imageName: ghcr.io/cloudnative-pg/postgresql:16
instances: 1 instances: 1
# shared_buffers 1GB below needs headroom - matches home's requests/limits.
resources: resources:
requests: requests:
memory: "512Mi" memory: "1Gi"
cpu: "50m" cpu: "50m"
limits: limits:
memory: "2Gi" memory: "4Gi"
cpu: "500m" cpu: "500m"
storage: storage:
size: 20Gi size: 50Gi # matches home's size
storageClass: local-path storageClass: local-path
primaryUpdateStrategy: unsupervised primaryUpdateStrategy: unsupervised
bootstrap:
initdb:
database: gitlabhq_production
owner: app
postInitSQL:
- CREATE EXTENSION IF NOT EXISTS pg_trgm;
- CREATE EXTENSION IF NOT EXISTS btree_gist;
# Same tuning as home's, GitLab needs these regardless of scale
postgresql: postgresql:
parameters: parameters:
max_connections: "200" max_connections: "400"
shared_buffers: "512MB" shared_buffers: "1GB"
effective_cache_size: "1536MB" effective_cache_size: "3GB"
maintenance_work_mem: "128MB" maintenance_work_mem: "256MB"
checkpoint_completion_target: "0.9" checkpoint_completion_target: "0.9"
wal_buffers: "16MB" wal_buffers: "16MB"
default_statistics_target: "100" default_statistics_target: "100"
random_page_cost: "1.1" random_page_cost: "1.1"
effective_io_concurrency: "200" effective_io_concurrency: "200"
work_mem: "8MB" work_mem: "16MB"
min_wal_size: "1GB" min_wal_size: "1GB"
max_wal_size: "4GB" max_wal_size: "4GB"
max_worker_processes: "4"
max_parallel_workers_per_gather: "2"
max_parallel_workers: "4"
bootstrap:
recovery:
source: home
externalClusters:
- name: home
barmanObjectStore:
# serverName defaults to the externalClusters[].name, NOT the
# source Postgres cluster's actual metadata.name - home's own
# backup: block defaults serverName to "pg-gitlab" (its own
# name). Without this override, recovery looks under the wrong
# server-name prefix and finds nothing (confirmed live for the
# pg-authentik precedent).
serverName: pg-gitlab
destinationPath: s3://cnpg-backups/pg-gitlab
endpointURL: http://vps-minio.minio.svc.cluster.local:9000
s3Credentials:
accessKeyId:
name: vps-minio-secret
key: accesskey
secretAccessKey:
name: vps-minio-secret
key: secretkey
monitoring: monitoring:
enablePodMonitor: false # no Prometheus on the VPS cluster enablePodMonitor: false # no Prometheus on the VPS cluster
@@ -0,0 +1,87 @@
# GitLab cross-site replication Phase 1b - VPS's half of the Vault
# pipeline (apps/gitlab/manifests/ha-gitlab-secrets-pushsecret.yaml has
# home's half, which pushes the authoritative values into Vault at
# secret/vps/gitlab-{rails,gitlab-shell,gitaly,praefect}-secret). Pulls
# them back down here, BEFORE Phase 1c's Postgres replication goes live.
#
# creationPolicy: Owner (not Merge) - each of these secrets has exactly
# one key with nothing else to preserve, unlike pg-authentik-app which
# has CNPG-local host/dbname/username fields alongside the shared
# password. The chart's shared-secrets job skips creating a key that
# already exists, so having ESO own these outright is sufficient to stop
# the VPS from ever generating its own divergent values.
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
name: gitlab-rails-secret
namespace: gitlab
spec:
refreshInterval: 5m
secretStoreRef:
name: vault-backend
kind: ClusterSecretStore
target:
name: gitlab-rails-secret
creationPolicy: Owner
data:
- secretKey: secrets.yml
remoteRef:
key: vps/gitlab-rails-secret
property: secrets.yml
---
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
name: gitlab-gitlab-shell-secret
namespace: gitlab
spec:
refreshInterval: 5m
secretStoreRef:
name: vault-backend
kind: ClusterSecretStore
target:
name: gitlab-gitlab-shell-secret
creationPolicy: Owner
data:
- secretKey: secret
remoteRef:
key: vps/gitlab-gitlab-shell-secret
property: secret
---
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
name: gitlab-gitaly-secret
namespace: gitlab
spec:
refreshInterval: 5m
secretStoreRef:
name: vault-backend
kind: ClusterSecretStore
target:
name: gitlab-gitaly-secret
creationPolicy: Owner
data:
- secretKey: token
remoteRef:
key: vps/gitlab-gitaly-secret
property: token
---
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
name: gitlab-praefect-secret
namespace: gitlab
spec:
refreshInterval: 5m
secretStoreRef:
name: vault-backend
kind: ClusterSecretStore
target:
name: gitlab-praefect-secret
creationPolicy: Owner
data:
- secretKey: token
remoteRef:
key: vps/gitlab-praefect-secret
property: token
@@ -0,0 +1,47 @@
---
# Exposes the VPS's pg-gitlab/pg-praefect primaries (replicas today) back
# to home over the Netbird mesh, for GitLab cross-site replication (see
# /home/scooby/.claude/plans/jiggly-snacking-iverson.md) - needed for
# failback (home rejoining as a replica once it's back). Same pattern as
# infrastructure/vps-standby/authentik/manifests/ha-postgres-nodeport.yaml.
#
# No UniFi port-forward or Kyverno PolicyException needed here - the
# VPS's k3s has no NodePort restriction, and home reaching OUT to the VPS
# already works today via the netbird-egress DaemonSet's route (confirmed
# live all session for MinIO/CrowdSec/pg-authentik) - it's only the
# reverse direction (external peers reaching INTO home) that needs the
# UniFi workaround (see apps/gitlab/manifests/ha-postgres-nodeport.yaml).
#
# Different nodePort numbers than home's side (32442/32443) - not
# required since these are different machines, but matches the
# authentik precedent's convention of keeping each site's numbers
# distinct to avoid confusion.
apiVersion: v1
kind: Service
metadata:
name: ha-gitlab-postgres
namespace: gitlab
spec:
type: NodePort
selector:
cnpg.io/cluster: pg-gitlab
cnpg.io/instanceRole: primary
ports:
- port: 5432
targetPort: 5432
nodePort: 32444
---
apiVersion: v1
kind: Service
metadata:
name: ha-praefect-postgres
namespace: gitlab
spec:
type: NodePort
selector:
cnpg.io/cluster: pg-praefect
cnpg.io/instanceRole: primary
ports:
- port: 5432
targetPort: 5432
nodePort: 32445
@@ -0,0 +1,70 @@
---
# GitLab cross-site replication Phase 1c (see
# /home/scooby/.claude/plans/jiggly-snacking-iverson.md) - the VPS never
# had a pg-praefect cluster before (VPS ran Gitaly without Praefect,
# global.praefect.enabled: false). This is new, matching home's
# apps/gitlab/manifests/praefect-cnpg-cluster.yaml as a real replica.
#
# Same two-stage deployment as cnpg-cluster.yaml in this directory: this
# commit is bootstrap.recovery only, streaming config added once this
# cluster's own certs exist to copy cross-cluster.
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: pg-praefect
namespace: gitlab
spec:
imageName: ghcr.io/cloudnative-pg/postgresql:16
instances: 1
resources:
requests:
memory: "512Mi"
cpu: "50m"
limits:
memory: "2Gi"
storage:
size: 10Gi # matches home's size
storageClass: local-path
primaryUpdateStrategy: unsupervised
# Must match-or-exceed home's - copied verbatim from
# apps/gitlab/manifests/praefect-cnpg-cluster.yaml.
postgresql:
parameters:
max_connections: "200"
shared_buffers: "512MB"
effective_cache_size: "1536MB"
maintenance_work_mem: "128MB"
checkpoint_completion_target: "0.9"
wal_buffers: "16MB"
default_statistics_target: "100"
random_page_cost: "1.1"
effective_io_concurrency: "200"
work_mem: "4MB"
min_wal_size: "1GB"
max_wal_size: "4GB"
max_worker_processes: "4"
bootstrap:
recovery:
source: home
externalClusters:
- name: home
barmanObjectStore:
serverName: pg-praefect
destinationPath: s3://cnpg-backups/pg-praefect
endpointURL: http://vps-minio.minio.svc.cluster.local:9000
s3Credentials:
accessKeyId:
name: vps-minio-secret
key: accesskey
secretAccessKey:
name: vps-minio-secret
key: secretkey
monitoring:
enablePodMonitor: false # no Prometheus on the VPS cluster