Commit Graph
3 Commits
Author SHA1 Message Date
Mukul SharmaandClaude Opus 5 61bc4af1a0 Serve every tool on deployshed.com instead of nip.io
Harbor, Gitea, Argo CD, Jenkins, Vault, Grafana and vmui now answer on
their deployshed.com names alone. Each was already serving both while the
move was proved out; this removes the nip.io half.

The dual-hostname workarounds go with it. Jenkins' secondaryingress existed
only because its chart's primary ingress takes one hostName and a
certificate could not span both names — the real domain moves onto the
primary with jenkins-tls, which it already holds. Argo CD gets extraTls
rather than ingress.tls, because the boolean hardcodes secretName
argocd-server-tls and would request a second certificate for a name that
already has a valid one in argocd-deployshed-tls.

Harbor also changes in two ways beyond the hostname:

  - externalURL moves to https://harbor.infra.deployshed.com. Harbor hands
    this to docker clients in its own API responses and builds the push
    commands shown in its UI from it, so a stale value is what makes a
    correctly-configured registry still advertise the old address.

  - updateStrategy is now Recreate. Its jobservice and registry volumes are
    standard-rwo (ReadWriteOnce), and a RollingUpdate starts the new pod
    before the old one releases the disk, so the replacement hangs forever
    on Multi-Attach. The cluster was sitting in exactly that state, old pods
    serving while new ones stayed in ContainerCreating. The chart's own
    comment on this value recommends Recreate when RWM is unavailable. The
    cost is a brief outage during upgrades, which beats a rollout that
    cannot complete.

The private registry CA is not removed yet. Apps deployed before this move
recorded nip.io image references that only change when each is rebuilt, so
the old hostname stays served by a standalone Ingress until then.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LEsTefWWifp4ikvhHF5s6N
2026-09-17 09:31:26 +05:30
Mukul SharmaandClaude Opus 5 f703f0b55a Serve the infra tools on the real domain as well as nip.io
Each of these now answers on <name>.infra.deployshed.com alongside the
nip.io name it already had. Both are kept on purpose: nothing that
currently references the old name breaks, and the new one can be proved
before anything depends on it. Removing nip.io is a separate step, and a
larger one, because Harbor's name is embedded in every running app's image
reference.

TLS covers the real domain only. Let's Encrypt cannot issue for nip.io —
it is not on the public suffix list and every *.nip.io certificate shares
one rate limit — so a tls block naming both would request one certificate
spanning them and receive nothing for either. Each tls block therefore
lists exactly the one new hostname, which is why they are written out
rather than derived from the host list beside them.

The charts disagree about how to express a second host, so each is done
the way its own chart supports:

  gitea, grafana, vault, victoria-metrics-single take host lists, so the
  new name joins the existing one on a single Ingress.

  jenkins' primary ingress accepts exactly one hostName, so the new name
  goes on secondaryingress — a whole second Ingress object at the same
  backend. paths must be set explicitly there; left at the chart's default
  of [] it renders zero routes and the hostname answers nothing.

  argo-cd takes extraHosts natively, but its ingress.tls is a boolean bound
  to one fixed secret covering every host at once. Turning it on would
  request a certificate including nip.io and fail, and there is no extraTls
  to scope it. So ArgoCD gains the hostname now and its certificate when
  nip.io goes.

Harbor is untouched here. It has no multi-host mechanism at all, so its
second hostname needs a standalone Ingress, and its externalURL is what
docker clients are handed — both deserve their own change rather than
riding along with a hostname tidy-up.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LEsTefWWifp4ikvhHF5s6N
2026-09-17 02:14:30 +05:30
Mukul SharmaandClaude Opus 5 f83cedca65 GKE: values for the remaining homelab tools
Ports the rest of the homelab's stack: external-secrets, harbor, jenkins,
postgresql, redis, victoria-metrics-single, vmagent, node-exporter and
grafana. All nine verified with helm template.

Most are the homelab's values with storage moved from local-path to
standard-rwo and hostnames rebuilt on the reserved ingress IP. vmagent and
node-exporter are unchanged outright — everything in them is addressed by
cluster DNS, namespace or container port, none of which differs here.

Harbor is the substantial one. The homelab serves it over plain HTTP and
makes containerd accept that by hand-editing hosts.toml on the node; GKE
nodes are managed and replaced, so that edit cannot survive. Instead the
node pool was told at creation to trust a private CA for exactly this
hostname, and cert-manager now signs Harbor's certificate from that same
CA via an ingress-shim annotation. certSource is "secret" rather than the
chart's "auto", which would self-sign a certificate nothing trusts.
externalURL moves to https to match, since Harbor hands that URL to docker
clients and a mismatch surfaces as registry errors.

Jenkins drops secondaryingress, which exists in the homelab only to serve
its Tailscale hostname. Its plugin pins are carried over deliberately: each
fixes a failure whose symptom points somewhere else, above all the
kubernetes/kubernetes-client-api pairing, without which agents never come
online and builds hang at "Still waiting to schedule task".

Postgres and Redis keep the homelab's deliberately small memory settings.
Those were chosen for an 8GB node under pressure, and while this cluster
has room, a bigger cache buys nothing for a handful of small tools.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LEsTefWWifp4ikvhHF5s6N
2026-09-12 15:01:49 +05:30