Eine Fehlerbehebungserfahrung im CentOS-Docker-Bridge-Modus, bei dem auf den Host-Redis-Dienst nicht zugegriffen werden kann

Hintergrund:

Ich habe bereits ein Projekt durchgeführt, bei dem auf den vom Host im Container bereitgestellten Redis-Dienst zugegriffen werden musste (dies ist ein gängiges Anwendungsszenario). Die herkömmliche Lösung lautet:

① Host-Netzwerk ( docker run --network=host ): Wenden Sie den Host-Netzwerkstapel vollständig an, und localhost im Container bezieht sich auf den Host-Computer

② docker run --network=bridge bridge): Dies ist auch der Standardnetzwerkkommunikationsmodus des Docker-Containers. Der localhost im Container zeigt auf den Container selbst. Sie können localhost nicht verwenden, um auf den Redis-Dienst zuzugreifen, der von localhost:6379 auf dem Host gehostet wird.

Docker wird standardmäßig die Docker0-Brücke einrichten;

Die Bridge verfügt über eine Gateway-IP und ein Subnetzsegment. Die Container in der Bridge ermitteln die Container-IP (IP-Adresse eth0) aus dem Subnetzsegment. Die Container in der Bridge können über den Dienstnamen aufeinander zugreifen.

Der Container in der Brücke kann über das Docker0-Getway auf das externe Netzwerk zugreifen.

Keine ausgefallenen Vorgänge, verwenden Sie einfach den allgemeinen ② Bridge-Modus:

Schritt 1: Passen Sie die Brücke an und wenden Sie sie an

Docker-Netzwerk erstellen --Gateway 172.16.1.1 --Subnetz 172.16.1.0/24 app_bridge

docker run --network=app_bridge --name ......

# Das Folgende stammt aus der Datei docker-compose.yml......
Netzwerke:
 Standard:
 Name: app_bridge
 extern: wahr

Warum nicht die Standard-Docker0-Bridge verwenden?

Wie am Anfang dieses Artikels erwähnt: Docker0 ist die Standardbrücke, und neu erstellte Container werden standardmäßig dieser Brücke beitreten. Daher müssen wir eine Brücke app_bridge erstellen, die diesem Programm gewidmet ist.

Schritt 2: Erstellen Sie einen Alias, der dem Host im Container entspricht

Um im Bridge-Modus innerhalb des Containers auf den Dienst localhost:6379 des Host-Rechners zuzugreifen, müssen Sie die von Docker bereitgestellte Option --add-host verwenden (die entsprechende Konfiguration in docker-compose.yml ist extra_host).

Die Option --add-host von Docker Run fügt der Datei /etc/hosts des Containers eine Zeile hinzu, die es uns erleichtert, mit diesem Namen auf andere Netzwerke zuzugreifen.

docker run -it --add-host dockerhost:172.16.1.1 ubuntu cat /etc/hosts
172.17.0.22 09d03f76bf2c
fe00::0 ip6-lokales Netz
ff00::0 ip6-mcastprefix
ff02::1 ip6-alle Knoten
ff02::2 ip6-allerouter
127.0.0.1 lokaler Host
::1 lokaler Host ip6-lokaler Host ip6-Loopback
172.16.1.1 Dockerhost

Anschließend können Sie dockerhost:6379 in der Programmkonfigurationsdatei verwenden, um auf den Redis-Dienst des Hosts zuzugreifen.

------------------------------------------ Freunde, die mit dem Docker-Netzwerkmodell ein wenig vertraut sind, sollten in der Lage sein, die oben genannten Vorgänge zu verstehen und abzuschließen-----------------------------------------------------

Eine Situation:

Ich habe die oben genannten Vorgänge auf der CentOS7-Maschine des Unternehmens verwendet und der Container konnte keine Verbindung zur Host-Maschine herstellen (Container konnten weiterhin normal aufeinander zugreifen).

Vereinfachen Sie den Problemtest: Erstellen Sie einen neuen Container und versuchen Sie, das Docker0-Gateway im Container anzupingen. Oh mein Gott, alle vier Firmencomputer können das Docker0-Gateway nicht anpingen, aber das externe Netzwerk kann weiterhin normal darauf zugreifen.

Dann besteht das Problem: Bei Verwendung der Standard-Docker0-Bridge kann das Docker0-Gateway nicht aus dem Container heraus angepingt werden, und auf den Hostcomputer kann nicht zugegriffen werden.

Oh je, es handelt sich höchstwahrscheinlich um ein Konfigurationsproblem mit den Maschinen des Unternehmens. . ~

Nachdem ich die Betriebs- und Wartungskollegen des Unternehmens befragt hatte, stellte ich Folgendes fest:

Ketten-INPUT (Richtlinie DROP)

Die Standardrichtlinie der obigen INPUT-Kette lautet „Verwerfen“: Die INPUT-Kettenregel für den Zugriff auf den Host vom Container aus stimmt mit keiner der aufgelisteten überein und wird verworfen. Daher bleiben wir beim Pingen des Docker0-Gateways vom Container aus hängen und erhalten keine Ergebnisse.

Die Standardrichtlinie sieht das Verwerfen vor, sofern die aufgeführten INPUT-Kettenregeln nicht erfüllt sind.

Es gibt auch Weiterleitungs- und Ausgabeketten, die standardmäßig akzeptieren

Die ursprüngliche Absicht dieser Strategie besteht in der Serversicherheit (verdammt, sie führt dazu, dass der Container seine grundlegende Fähigkeit verliert, auf den Hostcomputer zuzugreifen!!!).

Betriebs- und Wartungslösung:

① Verwenden Sie sudo service iptables stop um iptables herunterzufahren

② Fügen Sie das zu verwendende Bridge-Netzwerksegment zur INPUT-Kette hinzu

sudo iptables -I INPUT -s 172.17.0.0/16 -j AKZEPTIEREN

[Docker0-Subnetz 172.17.0.0/16 INPUT akzeptieren] Regeln hinzufügen, Portal

OK, das ist alles. Wenn Sie auf das Problem stoßen, dass Sie das Bridge-Gateway im Standard-Bridge-Container im Unternehmensnetzwerk nicht anpingen können und nicht auf den Hostcomputer zugreifen können, finden Sie in diesem Artikel Hinweise zur Fehlerbehebung.

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. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.