Ihre erste Route veröffentlichen

Eine Route verbindet einen oder mehrere öffentliche Hostnamen über einen Ingress Node mit einer Anwendung. Im einfachen Fall wählen Sie die Domain, die Anwendung und den Port, aktivieren TLS und speichern; Opfield erstellt die nginx-Konfiguration und wendet sie auf dem Ingress Node an.

Das Erfolgskriterium ist eine HTTPS-Anfrage, die auf den zugewiesenen Ingress Node aufgelöst wird, das vorgesehene Zertifikat vorlegt, die vorgesehene Anwendung erreicht und beobachtbar sowie umkehrbar bleibt. Betrachten Sie ein gespeichertes Formular nicht als erfolgreiche Veröffentlichung.

Die beteiligten Ressourcen verstehen

Opfield hält die Zuständigkeiten getrennt:

• Eine Domain erfasst den Hostnamen und seine Ingress-Platzierung.
• Ein SSL-Zertifikat liefert das TLS-Material und regelt die Zuständigkeit für die Verlängerung.
• Eine Route legt Weiterleitung, Zugriff, Wartung und Health-Verhalten fest.
• Ein Upstream ist die Anwendung, die die Anfrage erhält. Das kann eine manuell eingegebene Adresse sein, eine von Opfield verwaltete Docker-Ressource, die über einen Secure Link erreicht wird, oder ein Pages-Deployment, das über einen Tag ausgewählt wird.

Diese Trennung ermöglicht es, eine Anwendungsrevision zu ändern, ohne DNS oder ein Zertifikat neu zu erstellen. Sie bedeutet auch, dass alle vier Teile übereinstimmen müssen, bevor die Route produktionsreif ist.

Bevor Sie die Route erstellen

Bestätigen Sie, dass:

• ein Ingress Node Online ist, die vorgesehene öffentliche Dienstadresse besitzt und bei Bedarf die Ports 80/443 annehmen kann;
• die Anwendung existiert und auf dem gewählten Schema und Port antwortet;
• der Hostname freigegeben ist und sein DNS-Verantwortlicher erreichbar ist;
• ein passendes Zertifikat aktiv ist oder ein klarer Ausstellungsweg besteht;
• der Operator die Berechtigung hat, die Domain zu erstellen, das Zertifikat auszuwählen und die Route zu erstellen;
• der erwartete Health-Pfad, der Antwortstatus, der Bedarf an WebSockets, die Anfragelimits und die Zugriffsrichtlinie bekannt sind.

Ist der Upstream privat, entscheiden Sie, ob die Route einen von Opfield verwalteten Secure Link verwenden soll. Ein Secure Link leitet Datenverkehr durch die Relay-Datenebene, ohne nur für den Ingress einen normalen Host-Port zu veröffentlichen. Er repariert keine fehlerhafte Anwendung und umgeht nicht die Zuständigkeit für den Workload.

Die Route veröffentlichen

1. Öffnen Sie Routes, dann die Registerkarte Domains, und fügen Sie den Hostnamen hinzu.
2. Weisen Sie ihn dem Ingress Node zu, der den öffentlichen Datenverkehr empfangen wird.
3. Konfigurieren Sie DNS über die Cloudflare-Integration oder legen Sie den benötigten externen DNS-Eintrag an. Warten Sie, bis die autoritative Antwort auf die vorgesehene Dienstadresse zeigt.
4. Öffnen Sie Certificates, dann die Registerkarte SSL, und stellen Sie ein Zertifikat aus, importieren oder wählen Sie eines, das den genauen Hostnamen oder einen passenden Wildcard abdeckt.
5. Öffnen Sie Routes und wählen Sie Add Route.
6. Wählen Sie die Domain und das Weiterleitungsziel. Bei einem verwalteten Docker-Ziel wählen Sie die Ressource und den Anwendungsport; Opfield verwaltet den Lebenszyklus des Secure Links.
7. Wählen Sie HTTP oder HTTPS für den Upstream, je nachdem, was die Anwendung tatsächlich ausliefert. Diese Einstellung ist unabhängig von der öffentlichen TLS-Terminierung.
8. Aktivieren Sie öffentliches TLS und wählen Sie das Zertifikat. Aktivieren Sie Force HTTPS, wenn einfaches HTTP umleiten soll, statt Inhalte auszuliefern.
9. Aktivieren Sie die WebSocket-Unterstützung nur, wenn die Anwendung Upgrade-Verbindungen verwendet. Wenden Sie eine Access List, eine Ratenrichtlinie oder eine benutzerdefinierte Vorlage nur an, wenn der Dienst sie benötigt und die Vorlage bekanntermaßen kompatibel ist.
10. Speichern Sie die Route und warten Sie, bis Opfield die nginx-Konfiguration gerendert, validiert und angewendet hat.

Das Ergebnis prüfen

Prüfungen aus Benutzersicht

• Öffentliches DNS wird aus mehr als einem Netzwerk auf die zugewiesene Ingress-Adresse aufgelöst.
• Die HTTPS-Antwort legt ein vertrauenswürdiges Zertifikat vor, das den Hostnamen abdeckt.
• Die erwartete Anwendungsseite oder API-Antwort wird zurückgegeben.
• HTTP leitet auf HTTPS um, wenn Force HTTPS aktiviert ist.
• Browser-Anmeldung, Callbacks, Streaming-Antworten und WebSockets funktionieren, wenn die Anwendung sie verwendet.

Prüfungen in Opfield

• Die Route ist aktiviert, und ihr Health-Zustand stimmt mit einer direkten Prüfung der Anwendung überein.
• Das angezeigte Ziel ist die Ressource und der Port, die Sie vorgesehen haben, und kein veralteter Container und keine veraltete manuelle Adresse.
• Der Ingress Node meldet eine gültige angewendete nginx-Konfiguration.
• Access- und Error-Logs zeigen die Testanfrage und keine wiederholten Upstream-Fehler.
• Die Secure-Link-Laufzeit ist fehlerfrei, wenn das Ziel sie verwendet.
• Access List und Ratenbegrenzung lassen die erwarteten Clients zu bzw. weisen sie ab.

Eine fehlerfreie Antwort der Anwendung beweist nicht, dass die Richtlinie korrekt ist. Testen Sie einen erlaubten und einen abgewiesenen Pfad, wenn Zugriffskontrollen vorhanden sind, und testen Sie eine WebSocket-Verbindung statt nur des anfänglichen HTTP-Handshakes.

Fehlerbilder und Wiederherstellung

DNS wird falsch aufgelöst: Korrigieren Sie den autoritativen Eintrag und warten Sie den normalen Cache-Ablauf ab. Ändern Sie nicht das Ziel der Route, um einen DNS-Fehler auszugleichen.

Das Zertifikat wird abgelehnt: Prüfen Sie die Abdeckung des Hostnamens, die Kette, den Gültigkeitszeitraum und die Bereitstellung auf dem ausgewählten Ingress Node. Deaktivieren Sie die TLS-Prüfung in Clients nicht als Umgehung.

Opfield kann die nginx-Konfiguration nicht anwenden: Prüfen Sie den Validierungsfehler, bevor Sie es erneut versuchen. Eine benutzerdefinierte Vorlage, eine inkompatible Option, ein doppelter Hostname oder ein nicht verfügbares verwaltetes Ziel kann die gewünschte Konfiguration ungültig machen. Opfield behält die Zuständigkeit für den zuletzt angewendeten Zustand; korrigieren Sie die Eingabe, statt generierte nginx-Dateien direkt zu bearbeiten.

Das Secure-Link-Ziel ist nicht verfügbar: Prüfen Sie, dass der Workload und die beteiligten Nodes online sind und Relay fehlerfrei läuft. Einen Container-Port als Notlösung zu veröffentlichen, ändert das Sicherheitsmodell und sollte eine bewusste, geprüfte Änderung sein.

Ein fehlerhaftes Release ist live: Aktivieren Sie bei Bedarf die Wartung der Route oder setzen Sie den Upstream auf das letzte bekannt fehlerfreie Deployment, den letzten Image-Digest, die letzte Compose-Revision oder den letzten Pages-Tag zurück. Route und Zertifikat müssen für ein Rollback der Anwendung normalerweise nicht gelöscht werden.

Eine ausführlichere Erklärung privater Ziele finden Sie unter Sichere Upstreams. Für einen vollständigen Ablauf vom Workload bis zur öffentlichen URL nutzen Sie Anwendung veröffentlichen.