bmr_bluecap
171c8c96aa
There was no way to view the rebuild in a browser: the ingress answered only on websecure for the production hostnames, which have no cert and still belong to the live WordPress site. Review meant a port-forward. Add bcs.int.7tl-homelab.com as a staging route. The *.int zone resolves to the internal traefik LB (10.66.15.30) and is not reachable from the internet, so this exposes nothing publicly and leaves the real domain untouched. It follows the same pattern as the existing argocd/lidarr/tautulli ingresses. Enable cert-manager on the ingress, but scope the tls block to the staging host only. The production hostnames stay out of it deliberately: requesting a cert for names the live site still serves is a cutover step, not a prerequisite. Fix the issuer name while here. The commented-out placeholder said "letsencrypt-production"; the ClusterIssuer is actually "letsencrypt-prod", so the old hint would have silently failed to issue. Note for cutover: letsencrypt-prod solves via DNS-01 against Cloudflare, so the production cert can be issued before DNS moves, avoiding the HTTP-01 ordering problem. Conditional on bluecapstrategies.com being reachable by the cert-manager Cloudflare token, which is not yet verified.
63 lines
2.3 KiB
YAML
63 lines
2.3 KiB
YAML
# Two audiences, deliberately separated:
|
|
#
|
|
# 1. bcs.int.7tl-homelab.com — STAGING. LAN-only (*.int resolves to the internal traefik LB at
|
|
# 10.66.15.30) with a real Let's Encrypt cert. This is how the rebuild is reviewed before
|
|
# launch. Safe: it is not reachable from the internet and does not touch the real domain.
|
|
#
|
|
# 2. www.bluecapstrategies.com / bluecapstrategies.com — PRODUCTION. Listed as routes so the
|
|
# cluster is ready, but deliberately NOT in the tls block yet: the live WordPress site still
|
|
# serves these names and must keep doing so until cutover. Requesting a cert for them is a
|
|
# launch step, not a prerequisite.
|
|
#
|
|
# TLS: ClusterIssuer is `letsencrypt-prod` (NOTE: not "letsencrypt-production" — an earlier comment
|
|
# here had the name wrong). It solves via DNS-01 against Cloudflare, which means a cert can be
|
|
# issued BEFORE any DNS points at this cluster. At cutover, add the two production hosts to the
|
|
# tls block and let the cert issue first, then move DNS — no insecure window, no HTTP-01
|
|
# chicken-and-egg. That requires bluecapstrategies.com to be in the Cloudflare account the
|
|
# cert-manager API token can reach; verify that before relying on it.
|
|
apiVersion: networking.k8s.io/v1
|
|
kind: Ingress
|
|
metadata:
|
|
name: bluecap-website
|
|
namespace: bluecap-strategies
|
|
annotations:
|
|
traefik.ingress.kubernetes.io/router.entrypoints: websecure
|
|
cert-manager.io/cluster-issuer: letsencrypt-prod
|
|
spec:
|
|
tls:
|
|
# Staging only, for now. Production hosts join this list at cutover (see header).
|
|
- hosts:
|
|
- bcs.int.7tl-homelab.com
|
|
secretName: bcs-int-tls
|
|
rules:
|
|
- host: bcs.int.7tl-homelab.com
|
|
http:
|
|
paths:
|
|
- path: /
|
|
pathType: Prefix
|
|
backend:
|
|
service:
|
|
name: bluecap-website
|
|
port:
|
|
name: http
|
|
- host: www.bluecapstrategies.com
|
|
http:
|
|
paths:
|
|
- path: /
|
|
pathType: Prefix
|
|
backend:
|
|
service:
|
|
name: bluecap-website
|
|
port:
|
|
name: http
|
|
- host: bluecapstrategies.com
|
|
http:
|
|
paths:
|
|
- path: /
|
|
pathType: Prefix
|
|
backend:
|
|
service:
|
|
name: bluecap-website
|
|
port:
|
|
name: http
|