Fehlerbehebungsprozess für Docker-Container, bei dem nach der Portzuordnung plötzlich keine Verbindung mehr hergestellt werden kann

1. Hintergrund

Im Allgemeinen verwenden wir für Docker-Container, die externe Dienste bereitstellen müssen, den Befehl -p, um den externen Zugriffsport beim Start der Außenwelt zugänglich zu machen. Wenn wir beispielsweise Docker Registry starten, ordnen wir Port 5000 für den externen Zugriff zu:

Docker ausführen -d -p 5000:5000 Registrierung

Doch vor Kurzem stieß ich auf eine sehr merkwürdige Situation: In einer CentOS 7-Testumgebung im Forschungs- und Entwicklungsteam wurde ein Docker-Register eingesetzt und der Port war der Außenwelt ausgesetzt. Nach dem Starten des Containers kann dieser eine Zeit lang normal funktionieren. Nach einer unbestimmten Zeitspanne kann der externe Host das Image jedoch nicht mehr aus dem Warehouse abrufen und es tritt ein TimeOut auf:

Der Zugriff auf das Repository auf dem Docker-Host kann jedoch wie gewohnt erfolgen:

Bei diesem Problem kann der externe Zugriff erst nach einem manuellen Neustart des problematischen Docker-Daemon-Dienstes wiederhergestellt werden. Das Problem tritt jedoch nach einer gewissen Zeit erneut auf.

2. Fehlerbehebung

Als ich auf dieses Problem stieß, bestand meine erste Reaktion darin, die Leute in der Gruppe zu fragen, ob jemand die Firewall von CentOS 7 neu gestartet hatte.

Da dieser Server von mir konfiguriert wurde, habe ich, obwohl die Firewall eingeschaltet ist, den Portzugriff bereits geöffnet. Es liegt also definitiv nicht daran, dass die Firewall die Verbindung blockiert. Da es sich bei diesem Artikel aber um ein Dokument zur Untersuchung von Fallstricken handelt, habe ich diese Situation trotzdem herausgeschrieben.

Fall 1: Die Firewall ist eingeschaltet, aber es sind keine Ports geöffnet

CentOS 7 verfügt über die Firewall FirewallD und aktiviert diese. Wir können den Status von FirewallD mit dem folgenden Befehl überprüfen:

Firewall-Befehl --state 

Wenn die Ausgabe "nicht läuft" lautet, dann läuft FirewallD nicht und alle Schutzrichtlinien sind nicht gestartet. In diesem Fall kann ausgeschlossen werden, dass die Firewall die Verbindung blockiert.

Wenn die Ausgabe „running“ lautet, bedeutet dies, dass FirewallD derzeit ausgeführt wird. Um anzuzeigen, welche Ports und Dienste derzeit geöffnet sind, müssen Sie den folgenden Befehl eingeben:

Firewall-Befehl --list-ports
Firewall-Befehl --list-services 

Es ist ersichtlich, dass die aktuelle Firewall nur Port 80/TCP, SSH-Dienst (22/TCP) und DHCPv6-Client-Dienst öffnet, nicht aber den vom Docker-Container zugeordneten Port 5000/TCP.

Es gibt zwei Lösungen:

1. Schalten Sie den FirewallD-Dienst aus:

Wenn Sie keine Firewall benötigen, schalten Sie einfach den Dienst FirewallD aus.

systemctl stoppe firewalld.service

2. Fügen Sie eine Richtlinie hinzu, um den angegebenen Port für die Außenwelt zu öffnen:

Wenn wir beispielsweise den externen Port 5000/tcp öffnen möchten, können wir den folgenden Befehl verwenden:

Firewall-Befehl --add-port=5000/tcp --permanent
Firewall-Befehl --reload

Wenn Sie den Port nur temporär öffnen möchten, entfernen Sie den Parameter „--permanent“ in der ersten Zeile des Befehls. Wenn Sie den FirewallD-Dienst dann erneut starten, wird diese Richtlinie ungültig.

Fall 2: Starten Sie den FirewallD-Dienst von CentOS 7 manuell neu

FirewallD ist eine neue Komponente, die in Version 7 des CentOS-Systems eingeführt wurde. Einfach ausgedrückt handelt es sich um einen Wrapper von iptables, der zur Vereinfachung von Firewall-bezogenen Einstellungen verwendet wird.

FirewallD und Docker kommen jedoch nicht besonders gut miteinander aus. Wenn FirewallD startet (oder neu gestartet wird), entfernt es die DOCKER-Kette aus iptables, was dazu führt, dass Docker nicht richtig funktioniert:

FirewallD

CentOS-7 hat Firewalld eingeführt, einen Wrapper um iptables, der mit Docker in Konflikt geraten kann.

Wenn Firewalld gestartet oder neu gestartet wird, entfernt es die DOCKER-Kette aus iptables, wodurch Docker nicht mehr ordnungsgemäß funktioniert.

Bei Verwendung von Systemd wird Firewalld vor Docker gestartet. Wenn Sie Firewalld jedoch nach Docker starten oder neu starten, müssen Sie den Docker-Daemon neu starten.

Auszug aus Dockers offiziellem Dokument „CentOS – Docker-Dokumentation“

Unter CentOS 7 gibt es kein Problem, wenn Sie systemd so einrichten, dass der Docker-Dienst beim Booten automatisch gestartet wird, da Docker in der systemd-Konfigurationsdatei eindeutig „After= firewalld.service“ angibt, um sicherzustellen, dass der Docker-Daemon nach dem Start von FirewallD gestartet wird.

(Docker: Wenn Sie es sich nicht leisten können, mich zu beleidigen, können Sie es sich dann leisten, sich vor mir zu verstecken?)

Allerdings löscht der FirewallD-Dienst jedes Mal, wenn der Benutzer den Dienst manuell neu startet, die vom Docker-Daemon in iptables geschriebene DOCKER-Kette. Daher ist es notwendig, den Docker-Daemon-Dienst einmal manuell neu zu starten, damit der Docker-Daemon-Dienst die DOCKER-Kette neu erstellen kann.

Als ich jedoch die beiden anderen F&E-Mitarbeiter der Gruppe fragte, sagten beide, sie hätten es nicht berührt. Ich habe den Shell-Verlauf geprüft, konnte jedoch keine entsprechenden Datensätze finden.

Das ist seltsam. Aber nach einiger Zeit der Untersuchung fand ich schließlich einen neuen Grund:

Fall 3: IP_FORWARD ist nicht aktiviert

Da wir das Problem nicht lokalisieren konnten, meldet sich unser Forschungs- und Entwicklungsteam manuell beim Hostcomputer an und startet den Docker-Daemon-Dienst neu, als wir feststellen, dass wir nicht normal auf das Warehouse zugreifen können.

Bevor ich mich beim Hostserver anmeldete und den Docker-Daemon-Dienst neu startete, fiel mir plötzlich ein anderes Problem ein, das bei der vorherigen Verwendung von Docker aufgetreten war: Wenn auf dem Hostcomputer die Funktion IP_FORWARD nicht aktiviert ist, gibt der Docker-Container beim Start eine Warnmeldung aus:

ACHTUNG: IPv4-Weiterleitung ist deaktiviert. Netzwerkbetrieb funktioniert nicht.

Und Sie können im gestarteten Container nicht auf das externe Netzwerk zugreifen, und die vom Container freigegebenen Ports sind von außen nicht normal zugänglich:

Könnte dieser Fehler dadurch verursacht werden, dass die IP_FORWARD-Funktion des Hostcomputers nicht aktiviert ist?

sysctl net.ipv4.ip_forward 

Tatsächlich zeigt die Ausgabe, dass die IP_FORWARD-Funktion des aktuellen Systems deaktiviert ist!

Das Problem ist jedoch, dass beim Starten des Containers alles in Ordnung war und es keine Ausgabe gab. Wie kommt es, dass die IP_FORWARD-Funktion deaktiviert wurde, während ich sie verwendete?

Moment, der Docker-Daemon-Dienst legt die iptables-Einstellungen beim Start automatisch fest. Überprüft er auch die IP_FORWARD-Einstellung und aktiviert sie vorübergehend für mich?

Mit dieser Annahme habe ich den Docker-Daemon-Dienst manuell neu gestartet:

Natürlich überprüft der Docker-Daemon-Dienst beim Start das IP_FORWARD-Konfigurationselement des Systems. Wenn die IP_FORWARD-Funktion des aktuellen Systems deaktiviert ist, können wir die IP_FORWARD-Funktion vorübergehend aktivieren. Die vorübergehend aktivierte IP_FORWARD-Funktion schlägt jedoch aus verschiedenen anderen Gründen fehl ...

Obwohl es noch keine schlüssigen Beweise für die genaue Ursache dieses Fehlers gibt, vermute ich nun ernsthaft, dass er durch einen Neustart des Netzwerkdienstes verursacht wurde. Da auf dem problematischen Serverhost ein Webprojekt ausgeführt wird, das unser Forschungs- und Entwicklungsteam entwickelt, besteht eine der Funktionen darin, die IP-Adresse der Netzwerkkarte zu ändern. Nach der Änderung der Netzwerkkarten-IP ruft diese Funktion automatisch den folgenden Befehl auf, um den Netzwerkdienst neu zu starten:

systemctl restart network.service

Durch einen Neustart des Netzwerkdienstes wird die temporäre IP_FORWARD-Konfiguration ungültig, die automatisch vom Docker-Daemon-Dienst festgelegt wird:

Da das Programm den Befehl direkt aufruft, bleibt außerdem keine Spur im Verlaufsbefehl zurück.

Die Reparaturlösung ist ganz einfach und erfordert nur eine Befehlszeile:

echo 'net.ipv4.ip_forward = 1' >> /usr/lib/sysctl.d/50-default.conf

Nachdem die Ausführung abgeschlossen ist, starten Sie den Server neu oder verwenden Sie den folgenden Befehl, um die Konfiguration aus der Datei zu laden:

sysctl -p /usr/lib/sysctl.d/50-default.conf 

Das ist es.

3. Zusammenfassung

Der Docker-Daemon-Dienst hilft uns beim Start, viele Konfigurationselemente anzupassen, wie beispielsweise die IP_FORWARD-Konfiguration, die dieses Mal das Problem verursacht hat.

Der Docker-Daemon aktiviert die IP_FORWARD-Funktion, da der Standardnetzwerkmodus des Docker-Containers (Bridge-Modus) jedem Container eine private IP zuweist. Wenn der Container mit der Außenwelt kommunizieren muss, ist NAT erforderlich. Für NAT muss die Funktion IP_FORWARD unterstützt werden, andernfalls kann sie nicht verwendet werden. Dies erklärt auch, warum bei deaktivierter IP_FORWARD-Funktion auf den Container im Bridge-Modus weder von innen noch von außen zugegriffen werden kann.

Unter Linux ist die Funktion IP_FORWARD jedoch aus Sicherheitsgründen standardmäßig deaktiviert. Der Docker-Daemon-Dienst prüft beim Start, ob die Funktion IP_FORWARD aktiviert ist. Wenn sie nicht aktiviert ist, aktiviert der Docker-Daemon diese Funktion vorübergehend stillschweigend. Die vorübergehend aktivierte Funktion IP_FORWARD kann jedoch nicht dauerhaft sein und wird aufgrund von Störungen durch andere Befehle ungültig.

Dieser Vorfall hat mich jedoch eine kleine Wahrheit gelehrt: Wenn Probleme auftauchen, geraten Sie nicht in Panik, sondern treffen Sie auf Erfahrung beruhende Annahmen und überprüfen Sie diese, um sowohl die Symptome als auch die Grundursache zu beheben.

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Wenn Sie Fragen haben, können Sie eine Nachricht hinterlassen. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.