Mukul SharmaandClaude Opus 5
f703f0b55a
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
157 lines
6.2 KiB
YAML
157 lines
6.2 KiB
YAML
argo-cd:
|
|
# GKE counterpart of helm-overrides/k8s-admin-prd-ase1/argocd-admin-prd.
|
|
#
|
|
# Installed once by hand with `helm install argocd-admin-prd` (namespace
|
|
# "argocd"), then manages itself through the argocd Application in
|
|
# devops-infra-argo-config-gcp, whose nameOverride matches that release.
|
|
# Deliberately no image tag pin, unlike the homelab: the chart's own
|
|
# appVersion (v3.5.2) governs, so the image cannot drift from the chart.
|
|
# A pin that outlives its chart is close to the failure this upgrade
|
|
# fixes — software older than the cluster it manages.
|
|
#
|
|
# Upgraded from chart 7.7.23 / Argo CD v2.13.8. Three v3 behaviour changes
|
|
# apply to this deployment, none of which needs a values change today:
|
|
# - logs RBAC is now enforced, so an account that reads pod logs needs
|
|
# an explicit `logs, get` policy. jenkins-ci below only syncs.
|
|
# - update/delete no longer inherit to an application's sub-resources.
|
|
# - resource tracking moves from labels to annotations, so the first
|
|
# sync after the upgrade re-stamps every managed resource.
|
|
|
|
# SSO still deferred, same as the homelab.
|
|
dex:
|
|
enabled: false
|
|
|
|
controller:
|
|
replicas: 1
|
|
resources:
|
|
requests:
|
|
cpu: 200m
|
|
memory: 400Mi
|
|
limits:
|
|
cpu: 500m
|
|
memory: 768Mi
|
|
|
|
redis-ha:
|
|
enabled: false
|
|
redis:
|
|
resources:
|
|
requests:
|
|
cpu: 50m
|
|
memory: 64Mi
|
|
limits:
|
|
memory: 128Mi
|
|
|
|
# repo-server does the manifest rendering (helm template per Application),
|
|
# so it is the component that actually saturates when many apps sync at
|
|
# once. Stateless, safe to run several behind its Service. With
|
|
# autoscaling on, the chart omits `replicas` from the Deployment, so the
|
|
# HPA and ArgoCD's own self-management do not fight over the count.
|
|
#
|
|
# CPU only. The chart's default also scales on memory, but a Go process
|
|
# does not hand memory back promptly after a spike, so a memory target
|
|
# scales up and then never scales down. Setting it to null removes it.
|
|
repoServer:
|
|
autoscaling:
|
|
enabled: true
|
|
minReplicas: 1
|
|
maxReplicas: 3
|
|
targetCPUUtilizationPercentage: 70
|
|
targetMemoryUtilizationPercentage: null
|
|
resources:
|
|
requests:
|
|
cpu: 100m
|
|
memory: 256Mi
|
|
limits:
|
|
cpu: 300m
|
|
memory: 512Mi
|
|
|
|
# API/UI. Stateless, sessions live in Redis, so replicas are
|
|
# interchangeable. Same CPU-only reasoning as repoServer above.
|
|
server:
|
|
autoscaling:
|
|
enabled: true
|
|
minReplicas: 1
|
|
maxReplicas: 3
|
|
targetCPUUtilizationPercentage: 70
|
|
targetMemoryUtilizationPercentage: null
|
|
# --insecure is NOT set here as an extra arg: configs.params below
|
|
# carries server.insecure, which is the supported way to express it and
|
|
# is what the chart renders into argocd-cmd-params-cm. Setting both
|
|
# works but leaves two places to disagree.
|
|
ingress:
|
|
enabled: true
|
|
ingressClassName: contour
|
|
hostname: "argocd.35.238.248.203.nip.io"
|
|
# The chart supports additional hostnames natively, so the new domain
|
|
# is served here rather than from a second Ingress object.
|
|
extraHosts:
|
|
- name: "argocd.infra.deployshed.com"
|
|
path: /
|
|
# No TLS yet, deliberately. This chart's ingress.tls is a boolean, not
|
|
# a host list: turning it on requests ONE certificate covering
|
|
# `hostname` plus every extraHost, and Let's Encrypt cannot issue for
|
|
# nip.io — so the request would fail and neither name would be served
|
|
# over TLS. There is no extraTls to scope it more narrowly.
|
|
#
|
|
# This one gets its certificate when nip.io is retired and `hostname`
|
|
# itself becomes the deployshed.com name. Until then ArgoCD is HTTP
|
|
# only, as it already was.
|
|
resources:
|
|
requests:
|
|
cpu: 50m
|
|
memory: 128Mi
|
|
limits:
|
|
cpu: 200m
|
|
memory: 256Mi
|
|
|
|
# applicationSet.enabled no longer exists in this chart, and there is no
|
|
# replacement: unlike dex and notifications below, the ApplicationSet
|
|
# controller's Deployment has no conditional at all. replicas: 0 is the
|
|
# only lever — the Deployment exists but runs nothing. Carrying the old
|
|
# `enabled: false` forward would have quietly started the controller,
|
|
# since Helm ignores unknown keys.
|
|
#
|
|
# Nothing here uses the ApplicationSet CRD; Applications are rendered by
|
|
# generic-argo-apps-chart instead.
|
|
applicationSet:
|
|
replicas: 0
|
|
notifications:
|
|
enabled: false
|
|
|
|
configs:
|
|
# Contour terminates TLS in front of Argo CD; leaving Argo CD's own TLS
|
|
# on as well produces a redirect loop. This renders into
|
|
# argocd-cmd-params-cm, which the server actually reads.
|
|
#
|
|
# This file previously expressed it as server.extraArgs: [--insecure],
|
|
# inherited from the homelab. Both work, but only one should exist, and
|
|
# the rendered ConfigMap is the thing to check when it looks wrong.
|
|
params:
|
|
server.insecure: true
|
|
cm:
|
|
url: "http://argocd.35.238.248.203.nip.io"
|
|
timeout.reconciliation: 3m
|
|
timeout.reconciliation.jitter: 60s
|
|
# No Ingress health override, unlike the homelab: there Contour sat
|
|
# behind hostPort, so nothing ever wrote an Ingress's load balancer
|
|
# status. On GKE Envoy gets a real LoadBalancer Service and Contour
|
|
# writes that status, so ArgoCD's built-in check works as intended.
|
|
#
|
|
# Scoped account for Jenkins' syncArgoApp step — same as the homelab.
|
|
accounts.jenkins-ci: apiKey
|
|
accounts.jenkins-ci.enabled: "true"
|
|
rbac:
|
|
policy.csv: |
|
|
p, jenkins-ci, applications, sync, webapp/*, allow
|
|
p, jenkins-ci, applications, get, webapp/*, allow
|
|
# Reached over cluster DNS, never through Contour — which is what lets
|
|
# Contour itself be ArgoCD-managed. The repos are private on this
|
|
# public-facing Gitea, so ArgoCD reads them with a repo-creds Secret
|
|
# (created at bootstrap, covering everything under gitadmin/), not
|
|
# anonymously as in the homelab.
|
|
repositories:
|
|
devops-infra-helm-charts-gcp:
|
|
url: http://gitea-http.gitea.svc.cluster.local:3000/gitadmin/devops-infra-helm-charts-gcp.git
|
|
devops-infra-argo-config-gcp:
|
|
url: http://gitea-http.gitea.svc.cluster.local:3000/gitadmin/devops-infra-argo-config-gcp.git
|