diff --git a/extra-manifests/argocd-ingress-deployshed.yaml b/extra-manifests/argocd-ingress-deployshed.yaml new file mode 100644 index 0000000..a1097bd --- /dev/null +++ b/extra-manifests/argocd-ingress-deployshed.yaml @@ -0,0 +1,45 @@ +# ArgoCD's own hostname on the real domain, with TLS. +# +# A standalone Ingress rather than the chart's, because the argo-cd chart +# cannot express this. Its server.ingress.tls is a BOOLEAN covering +# `hostname` plus every entry in `extraHosts`, all from one fixed secret, +# and there is no extraTls to scope it more narrowly. Turning it on while +# the nip.io hostname is still served would request a single certificate +# spanning both names — and Let's Encrypt cannot issue for nip.io, so the +# request fails and NEITHER name ends up with TLS. +# +# So the chart keeps serving argocd.35.238.248.203.nip.io over plain HTTP +# through its own Ingress, and this object serves the real domain over TLS. +# Both route to the same backend. When nip.io is retired, this file should +# go away and the chart's own tls: true should be turned on instead — one +# hostname, one certificate, no second object to remember. +# +# Backed by port 80, not 443: this deployment runs argocd-server with +# server.insecure: true, so it speaks plain HTTP and TLS terminates at +# Envoy. Pointing at 443 would have Envoy attempt TLS to a backend that +# does not serve it. +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: argocd-ingress-deployshed + namespace: argocd + annotations: + # ingress-shim issues and renews the certificate named in tls below. + cert-manager.io/cluster-issuer: letsencrypt-prod +spec: + ingressClassName: contour + tls: + - hosts: + - argocd.infra.deployshed.com + secretName: argocd-deployshed-tls + rules: + - host: argocd.infra.deployshed.com + http: + paths: + - path: / + pathType: Prefix + backend: + service: + name: argocd-admin-prd-server + port: + number: 80