Files
Homelabv4/apps/gitlab/manifests/ha-gitlab-internal-api-nodeport.yaml
T
Scooby HuskyandClaude Sonnet 5 bce3861083 GitLab cross-site replication Phase 2b: enable Gitaly + workhorse TLS
Per the approved plan (Istio federation scoped separately, current
NodePort/PeerAuth/cert-manager pattern continues for these 2 remaining
links). Real Let's Encrypt certs (not self-signed) via the same DNS-01
ClusterIssuer used everywhere else - both sites already trust Let's
Encrypt's public CA, no custom CA distribution needed.

- global.gitaly.tls.enabled: adds tls_listen_addr (8076) alongside the
  existing plaintext listener (8075, stays for in-cluster traffic
  that doesn't need it). Requires
  global.praefect.virtualStorages[0].tlsSecretName (chart's own NOTES.txt
  validation rejects the render without it, confirmed live).
- global.workhorse.tls.enabled + global.workhorse.host: Gitaly's [gitlab]
  url (internal-API callback for gitlab-shell hooks) switches from an
  unpublishable *.svc.cluster.local name to a real floating hostname
  (gitlab-internal-api.ha.huskypup.net) that Let's Encrypt CAN certify -
  confirmed live this replaces the plaintext [[listeners]] block with
  [listeners.tls] on the SAME port (8181), not a second port like Gitaly.
- praefect-ha-configmap.yaml (the manually-patched live config) updated
  to tls:// + floating hostnames for all 3 home nodes, so home's own
  Praefect uses the identical addresses it'll hand the VPS as peer
  addresses once Phase 2b's 4th node lands.
- New CoreDNS rewrite for gitlab-internal-api.ha.huskypup.net (same
  local-rewrite pattern as pg-*/gitaly-* already have).

Sequencing note: applying live - Certificates must issue before the
TLS-enabling values land, or Gitaly/webservice pods fail to start
(missing secret for their init container's cert copy).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-22 14:24:13 -05:00

33 lines
1.3 KiB
YAML

# GitLab cross-site replication Phase 2b - exposes home's Rails internal
# API (port 8181, a dedicated internal-only listener, deliberately NOT
# exposed through the public Istio ingress on 8080) to the VPS's Gitaly
# node. Gitaly's gitlab-shell hooks call POST /api/v4/internal/{allowed,
# pre_receive,post_receive} against this whenever the VPS node is
# primary for a repository (per-repository election can cause this even
# in normal operation) or after a real failover.
#
# Reached over the same public UniFi WAN forward already used for
# Postgres/Gitaly, not the Netbird mesh directly (confirmed live that
# path doesn't accept inbound connections to home). Port stays 8181
# (unlike Gitaly's separate 8075/8076 split) - global.workhorse.tls.
# enabled in values.yaml replaces the plaintext listener with TLS on
# this SAME port rather than adding a second one. Carries the
# gitlab_shell_secret in a header, so this needed TLS just as much as
# Gitaly's gRPC did - see gitaly-tls-certificate.yaml's second
# Certificate (gitlab-workhorse-tls) and the
# gitlab-internal-api.ha.huskypup.net CoreDNS rewrite.
apiVersion: v1
kind: Service
metadata:
name: ha-gitlab-internal-api
namespace: gitlab
spec:
type: NodePort
selector:
app: webservice
release: gitlab
ports:
- port: 8181
targetPort: 8181
nodePort: 32449