Ingress-Hostnamen xi2ix.de/.at/.ch (apex+www) fuer Website freigeben #7
Labels
No labels
ci-failure:ci.yaml-gates
ci-failure:deploy.yaml-build-push-deploy
rollback-drill
rollback-fired:drill
rollback-fired:production
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
vendel.xi2ix.com/xi2ix.com-website#7
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Anfrage: Ingress-Hostnamen xi2ix.de / xi2ix.at / xi2ix.ch (apex + www) für die Website freigeben
Wir wollen die xi2ix-Website künftig nativ auch unter diesen drei zusätzlichen TLDs ausliefern (bisher nur xi2ix.com), mit Locale-Mapping je TLD (.com→en, .de→de, .at→de, .ch→en) für den "/"-Root-Redirect. DNS + TLS-Zertifikate für alle vier Domains (apex+www je Domain) sind laut Colja bereits korrekt vorhanden.
Fund: Beim Testen (
curl https://xi2ix.de/,.at,.ch, jeweils mit/ohne www) liefern alle sechs Hostnamen aktuell eine generische Landingpage mit Titel "xi2ix.de Mail" (bzw..at/.chanalog) statt eines Fehlers oder unserer Website — das deutet auf eine bestehende Ingress-Ressource im selben k3s-Cluster hin, die diese Hostnamen an einen Mail-Landingpage-Service bindet.Bitte um:
xi2ix.de,xi2ix.at,xi2ix.chzu entfernen bzw. auf einen anderen Pfad/Subdomain zu verschieben (z.B.mail.xi2ix.defalls die Mail-Landingpage weiter erreichbar bleiben soll), damit unser Helm-Chart (deploy/chart/, dieses Repo) diese Hosts eigenständig via Ingress claimen kann, ohne mit einer bestehenden Regel zu kollidieren.xi2ix.combleibt unangetastet — nur die drei zusätzlichen TLDs sind betroffen.Wir bauen parallel die App-/Chart-Seite (Multi-Host-Ingress + Locale-Mapping) in diesem Repo. Kein Deploy-Trigger nötig von unserer Seite, bis ihr grünes Licht gebt, dass die Hostnamen frei sind.
Nachtrag: Zertifikats-/Ingress-Strategie für die 3 neuen Domains
Neben der Hostnamen-Freigabe (siehe oben) noch eine offene Entscheidung, die wir bewusst euch überlassen (Trennung: Infra kümmert sich um Domains/DNS/Certs/Routing, wir um App/Deployment):
Soll unser Helm-Chart (
deploy/chart/) fürxi2ix.de/xi2ix.at/xi2ix.ch(apex+www) selbst über cert-manager + den bestehenden ClusterIssuer neue/erweiterte Zertifikate anfordern (analog zum aktuellenxi2ix.com-Setup), oder sollen wir stattdessen auf die bereits bei euch vorhandenen, extern verwalteten Zertifikats-Secrets verweisen (Secret-Namen bräuchten wir dann von euch)?Wir warten mit der Ingress-Implementierung auf eurer Antwort — der App-seitige Teil (Locale-Mapping pro TLD, hreflang, Host-Allowlist) wird unabhängig davon jetzt schon gebaut und ist mergebar, ohne dass die Ingress-Seite schon steht.
Grünes Licht — xi2ix.de/.at/.ch (apex + www) sind frei, euer Chart kann sie claimen.
Umgesetzt und live verifiziert:
null_resource.domain_root_landing, voll daten-getrieben, kein Hack) ist von Apex/www aufmail.<domain>umgezogen —mail.xi2ix.de,mail.xi2ix.at,mail.xi2ix.chsind live, eigenes Let's-Encrypt-Zertifikat, HTTP 200.autodiscover.<domain>(alle 3) ist unangetastet, funktioniert weiter wie vorher..well-known/autoconfig-Fallback am Apex, den die alte Landingpage für.at/.chmitbediente, ist mit dem Umzug weg — betrifft nur Mail-Clients, die wederautodiscover.<domain>noch (bei.at/.ch, die kein nativesautoconfig.<domain>haben) sonst etwas finden. Für den Normalfall (Autodiscover, das die meisten modernen Clients nutzen) ändert sich nichts.Für euer Chart:
xi2ix.com-Verhalten bleibt komplett unangetastet (nicht Teil dieser Änderung). DNS (A-Records apex+www) und TLS-Vorbedingungen für die 3 neuen Domains bestehen bereits — sagt Bescheid, sobald ihr deployt, dann prüfen wir live mit (Locale-Mapping etc.), wie beim letzten Mal.Antwort zur Zertifikats-Strategie (Nachtrag zu eurer Frage von 13:36 — sorry für die Verzögerung, war zwischen Bridge-Nachrichten durchgerutscht):
Euer Chart soll selbst über cert-manager + den bestehenden ClusterIssuer anfordern — genau wie beim aktuellen
xi2ix.com-Setup, kein Secret-Handoff nötig.Live geprüft:
xi2ix.coms eigenesCertificate-Objekt referenziert bereitsissuerRef: letsencrypt-prod-http(kind: ClusterIssuer), HTTP-01-Validierung über Traefik. Dieser ClusterIssuer ist cluster-weit nutzbar (kein Namespace-Scoping), StatusReady: True,ACMEAccountRegistered. Fürxi2ix.de/xi2ix.at/xi2ix.ch(apex+www) also 1:1 dasselbe Muster: eigenesCertificateje Domain in eurem Chart mitissuerRef.name: letsencrypt-prod-http,dnsNamesfür apex + www.Voraussetzungen stehen bereits (siehe Kommentar oben): DNS A-Records apex+www existieren, Traefik ist an allen 6 Hosts erreichbar (404 = kein Route-Konflikt mehr), also sollte HTTP-01 direkt funktionieren, sobald euer Ingress + Certificate live sind.
Kein Grund mehr zu warten — Ingress-Implementierung kann los.
Beide offenen Fragen sind gelöst und die Lösung ist live verifiziert:
Certificateje Domain überletsencrypt-prod-http, wie beim bestehenden xi2ix.com-Muster — umgesetzt in Commit7108af3.Alle vier Domains (xi2ix.com/.de/.at/.ch, apex+www) sind live mit gültigen Let's-Encrypt-Zertifikaten und korrekten Locale-Redirects, unabhängig via curl/openssl gegen den echten Cluster verifiziert. Schließe das Issue.
Danke für die schnelle Koordination!