RHEL8 и docker -создать сетевую ошибку по умолчанию EHOSTUNREACH - PullRequest
1 голос
/ 10 февраля 2020

В течение некоторого времени мы использовали одиночный контейнер Docker изображений без проблем на RHEL8. Нам нужно перейти к интеграции нескольких сервисов с использованием docker -композиции, но не удалось даже при простых попытках.

Мы используем Mon go (mon go: 4.2.3-bioni c) и NodeJS (узел: alpine).

Мы создали простое приложение для узла, которое пытается добавить один документ в коллекцию MongoDB. Код для dbwrite. js:

var MongoClient = require('mongodb').MongoClient;

MongoClient.connect("mongodb://mongo:27017/", function(err, mongodb) {
  if (err) throw err;
  var mongodbo = mongodb.db("test");
  var doc = {"payload":"test doc"};
  mongodbo.collection("test2").insertOne(doc, function(err, res) {
    if (err) throw err;
  });
  mongodb.close();
});

Файл Docker для dbwrite. js:

FROM node:alpine
ADD . /
CMD ["node", "dbwrite.js"]

Контейнер Mon go был извлечен из DockerHub, как и было Узел контейнер.

Файл docker -compose.yaml:

version: '3.1'
services:
  mongo:
    image: mongo:4.2.3-bionic
    container_name: mongo
    restart: always
  ports:
    - 27017:27017
  volumes:
    - ./mongo_db:/data/db

app:
  image: dbwrite:v0.1
  container_name: dbwrite

Если мы выполним "docker -compose up", контейнер dbwrite выдаст ошибку:

dbwrite  | /node_modules/mongodb/lib/topologies/server.js:233
dbwrite  |             throw err;
dbwrite  |             ^
dbwrite  | 
dbwrite  | MongoNetworkError: failed to connect to server [mongo:27017] on first connect [Error:    connect EHOSTUNREACH 172.22.0.2:27017
dbwrite  |     at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1137:16) {
dbwrite  |   name: 'MongoNetworkError',
dbwrite  |   [Symbol(mongoErrorContextSymbol)]: {}
dbwrite  | }]
dbwrite  |     at Pool.<anonymous> (/node_modules/mongodb/lib/core/topologies/server.js:438:11)
dbwrite  |     at Pool.emit (events.js:321:20)
dbwrite  |     at /node_modules/mongodb/lib/core/connection/pool.js:561:14
dbwrite  |     at /node_modules/mongodb/lib/core/connection/pool.js:994:11
dbwrite  |     at /node_modules/mongodb/lib/core/connection/connect.js:31:7
dbwrite  |     at callback (/node_modules/mongodb/lib/core/connection/connect.js:264:5)
dbwrite  |     at Socket.<anonymous> (/node_modules/mongodb/lib/core/connection/connect.js:294:7)
dbwrite  |     at Object.onceWrapper (events.js:428:26)
dbwrite  |     at Socket.emit (events.js:321:20)
dbwrite  |     at emitErrorNT (internal/streams/destroy.js:84:8) {
dbwrite  |   name: 'MongoNetworkError',
dbwrite  |   [Symbol(mongoErrorContextSymbol)]: {}
dbwrite  | }
dbwrite exited with code 1

Перестройка контейнера (я делаю это нелегко - я знаю - но хочу, чтобы все было как можно более одинаково) и замена строки CMD Dockerfile

CMD ["node", "dbwrite.js"]

на

CMD ["ping", "-c", "20", "mongo"]

дает обычные ответы на пинг от "mon go", поэтому я считаю, что сеть по умолчанию была создана правильно, и DNS работает как положено, но мое приложение узла получает EHOSTUNREACH.

dbwrite  | 64 bytes from 172.22.0.2: seq=15 ttl=64 time=0.072 ms
dbwrite  | 64 bytes from 172.22.0.2: seq=16 ttl=64 time=0.080 ms
dbwrite  | 64 bytes from 172.22.0.2: seq=17 ttl=64 time=0.067 ms
dbwrite  | 64 bytes from 172.22.0.2: seq=18 ttl=64 time=0.121 ms
dbwrite  | 64 bytes from 172.22.0.2: seq=19 ttl=64 time=0.097 ms
dbwrite  | 
dbwrite  | --- mongo ping statistics ---
dbwrite  | 20 packets transmitted, 20 packets received, 0% packet loss
dbwrite  | round-trip min/avg/max = 0.065/0.086/0.121 ms
dbwrite exited with code 0

Если мы отредактируем код dbwrite. js и замените «mon go» в методе connect () на «localhost» и выполните «узел dbwrite. js» на локальном хосте (вне контейнера), документ в коллекцию , Журнал контейнера Mon go сообщает, что он прослушивает 0.0.0.0.

mongo    | 2020-02-10T19:35:26.337+0000 I  NETWORK  [listener] Listening on 0.0.0.0
mongo    | 2020-02-10T19:35:26.337+0000 I  NETWORK  [listener] waiting for connections on port 27017

Хотя у меня нет захваченного вывода, предыдущие выполнения "docker проверка сети" показали оба контейнера и назначенные им адреса IPv4 на 172.22.0.x / 16. IPAM показал использование драйвера по умолчанию "bridge" на su bnet 172.22.0.0/16 и шлюза 172.22.0.1.

Будем весьма благодарны за любые предложения о том, что может быть не так. Мы находимся на грани понижения RHEL8, чтобы увидеть, связано ли это с нашей проблемой, учитывая, что Red Hat так громко заявляет NOT в поддержку Docker. Похоже, что это некоторая проблема с безопасностью сети, поскольку пинг ICMP может проходить через мост, а соединение через сокет TCP - нет.

...