Ingress-Übersicht

Opfield verwendet verwaltete nginx-Nodes als öffentlichen Ingress. Ein vollständiger öffentlicher Dienst kombiniert Domain, Zertifikat, Route, Upstream, Health-Richtlinie und Node-Platzierung.

Routen können als Proxy weiterleiten, umleiten oder 404 zurückgeben. Proxy-Upstreams können manuelle Adressen, eigenständige Container, Deployments, Compose-Dienste oder bereite Pages-Tags sein. Additional Routes hängen literale Pfadpräfixe wie /api an separate Upstreams.

Verwenden Sie den nginx-Modus managed, wenn Opfield für eine bewährte Basiskonfiguration zuständig sein soll. Verwenden Sie den Modus integrate, wenn eine bestehende nginx-Installation ihre Basiskonfiguration behalten und von Opfield verwaltete Includes laden muss.

Prüfen Sie im Betrieb nach jeder Änderung von Platzierung oder TLS das DNS, die Zertifikatsverteilung, die Validierung der generierten Konfiguration, den Health-Zustand der Route und das öffentliche Verhalten. Eine Konfiguration ist nicht schon deshalb vollständig, weil sie erfolgreich gespeichert wurde.

Zuständigkeit für Ressourcen

Ingress-Ressourcen haben getrennte Lebenszyklen, auch wenn sie als eine öffentliche Anwendung erscheinen:

• eine Domain ist für den Hostnamen und die nginx-Platzierung zuständig;
• ein SSL-Zertifikat ist für Zertifikatsmaterial und Verlängerungszustand zuständig;
• eine Route ist für Anfrageverhalten, Health-Richtlinie und ihren primären Upstream zuständig;
• eine Additional Route ist für eine literale Überschreibung eines Pfadpräfixes zuständig;
• eine Access List ist eine wiederverwendbare Richtlinie, die an mehr als eine Route angehängt werden kann;
• ein Secure Link einer Route folgt der Route und kann nicht eigenständig entfernt werden.

Das Löschen einer Ressource darf nicht stillschweigend eine andere wiederverwendbare Ressource löschen. Prüfen Sie vor dem Löschen verknüpfte Ressourcen und entscheiden Sie, ob die beabsichtigte Aktion Deaktivieren, Wartung, Lösen, Migrieren oder dauerhaftes Entfernen ist.

Empfohlene Reihenfolge beim Erstellen

1. Registrieren und validieren Sie den Ziel-Ingress-Node.
2. Registrieren Sie die Domain und bestätigen Sie ihre vorgesehene Platzierung.
3. Stellen Sie das TLS-Zertifikat aus oder laden Sie es hoch.
4. Erstellen Sie die Route und wählen Sie ihren Upstream.
5. Fügen Sie Zugriffsrichtlinie, Header, WebSockets, Rewrites oder Timeout-Überschreibungen nur bei Bedarf hinzu.
6. Aktivieren Sie die Route und warten Sie auf die Validierung der nginx-Konfiguration.
7. Testen Sie HTTP und HTTPS von einem externen Client aus.
8. Bestätigen Sie Health-Verlauf, Access-Logs und Zertifikatsverteilung.

Sichere Betriebsregeln

• Halten Sie für jeden Hostnamen einen kanonischen Eigentümer; erstellen Sie keine konkurrierenden Routen für denselben Host außerhalb von Opfield.
• Behandeln Sie rohe nginx-Konfiguration als Notausgang für Experten. Sie deaktiviert einige verwaltete Validierungs- und Lebenszyklusfunktionen.
• Veröffentlichen Sie keinen privaten Workload-Port, nur weil ein Secure Link vorübergehend fehlerhaft ist.
• Verwenden Sie den Wartungsmodus für bewusste, für Kunden sichtbare Arbeiten, und deaktivieren Sie eine Route nur, wenn der Datenverkehr vollständig gestoppt werden soll.
• Migrieren Sie die Platzierung über den ausdrücklichen Ablauf, damit Domains, Routen, Zertifikate, Health-Zustand und DNS-Änderungen abgestimmt bleiben.

Zuständigkeiten von Opfield und Betreiber

Opfield validiert und verteilt die nginx-Konfiguration, verfolgt die Sollplatzierung, verwaltet unterstützte Zertifikatsabläufe und erfasst die Operationen, die öffentlichen Datenverkehr ändern. Es steuert keinen externen DNS-Anbieter, sofern nicht eine konfigurierte Integration diese Zone verwaltet, öffnet keine Upstream-Firewall und macht keine fehlerhafte Anwendung bereit. Diese Abhängigkeiten bleiben in der Verantwortung des Betreibers.

Diese Unterscheidung ist bei Vorfällen wichtig. Ein fehlerfreier Ingress Node beweist, dass Daemon und nginx verfügbar sind; er beweist nicht, dass öffentliches DNS auf diesen Node zeigt, dass jede Route einen erreichbaren Upstream hat oder dass ein externes Netzwerk den Datenverkehr erlaubt. Umgekehrt erfordert ein fehlgeschlagener Health Check der Anwendung keinen Neuaufbau des nginx-Hosts. Diagnostizieren Sie die Ressourcenkette vom öffentlichen Hostnamen in Richtung Anwendung und ändern Sie nur die ausgefallene Ebene.

Halten Sie für die Produktionszuständigkeit fest, wer DNS, Zertifikate, Routen, Access Lists und Anwendungsreleases ändern darf. Halten Sie den Notfallzugriff auf Opfield unabhängig von dem Anwendungs-Hostnamen, der betrieben wird. Prüfen Sie gemeinsam genutzte Zertifikate und Access Lists, bevor Sie sie ändern, da eine einzelne Bearbeitung mehrere Routen betreffen kann.

Produktionsabnahme

Prüfen Sie einen Hostnamen aus einem Netzwerk außerhalb der verwalteten Hosts, bevor Sie ihn für bereit erklären. Bestätigen Sie DNS-Antworten, das Umleitungsverhalten von HTTP, die HTTPS-Zertifikatskette und den Hostnamen, die erwartete Anwendungsantwort und, falls verwendet, das WebSocket-Verhalten. Vergleichen Sie diese Anfrage dann mit dem Health-Verlauf in Opfield und den nginx-Access-Logs.

Halten Sie während einer Umschaltung nach Möglichkeit die vorherige DNS-Platzierung oder Anwendungsrevision verfügbar. Schlägt die Abnahme fehl, stellen Sie den bekannt fehlerfreien Upstream oder die bekannt fehlerfreie Platzierung wieder her, statt die neuen Ressourcen zu löschen. Löschen entfernt nützlichen Sollzustand und Operationsverlauf und ist selten das sicherste Rollback.

Fahren Sie mit Domains, Routen und TLS für die Konfiguration, Sichere Upstreams für private Docker-Ziele und Fehlerbehebung beim Ingress für die Fehlerdiagnose fort.