0

This is the overview of what I caught in attention.

docker compose

  redis1:
    image: redis
    ports:
      - '6379:6379'
    container_name: redis1
  
  nodejs:
    build: src
    entrypoint: nodemon tchat/chatServer.js
    volumes:
      - ./src:/src
    ports:
      - 3000:3000
    depends_on:
      - db_pg
      - redis1

nodejs src code

The code is from this file, with a slight changes of configuration.

var conf = {
    port: 3000,
    debug: true,
    dbPort: 6379,
    dbHost: 'redis1',
    dbOptions: {},
    mainroom: 'MainRoom'
};

console.log(conf)

var io = require('socket.io')(server);
var redis = require('socket.io-redis');
io.adapter(redis({ host: conf.dbHost, port: conf.dbPort }));

// var db = require('redis').createClient(conf.dbPort,conf.dbHost);
var db = require('redis').createClient({
    port: conf.dbPort,
    host: conf.dbHost
});

logs

After checked at the node instance, it tells that there is conn refused to 127.0.0.1:6379, even though the host I specified is redis1.

root@locald:/media/data1/project1/si/halo-dock# docker logs halo-dock_nodejs_1
[nodemon] 2.0.20
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): *.*
[nodemon] watching extensions: js,mjs,json
[nodemon] starting `node tchat/chatServer.js`
{
  port: 3000,
  debug: true,
  dbPort: 6379,
  dbHost: 'redis1',
  dbOptions: {},
  mainroom: 'MainRoom'
}
node:internal/process/promises:288
            triggerUncaughtException(err, true /* fromPromise */);
            ^

Error: connect ECONNREFUSED 127.0.0.1:6379
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16)
Emitted 'error' event on Commander instance at:
    at RedisSocket.<anonymous> (/src/tchat/node_modules/@redis/client/dist/lib/client/index.js:390:14)
    at RedisSocket.emit (node:events:513:28)
    at RedisSocket._RedisSocket_connect (/src/tchat/node_modules/@redis/client/dist/lib/client/socket.js:167:18)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  errno: -111,
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '127.0.0.1',
  port: 6379
}

Node.js v18.14.2
[nodemon] app crashed - waiting for file changes before starting...

redis instance

The netcat result is just fine if I try to exec that from the nodejs instance.

# instances
CONTAINER ID   IMAGE                       COMMAND                  CREATED         STATUS                      PORTS                                                 NAMES
06ed514c7c37   halo-dock_app-hj-waf        "/docker-entrypoint.…"   5 minutes ago   Up 5 minutes                80/tcp, 0.0.0.0:88->88/tcp, :::88->88/tcp             app-hj-waf
5ae1f25f34cf   halo-dock_nodejs            "nodemon tchat/chatS…"   5 minutes ago   Up 5 minutes                0.0.0.0:3000->3000/tcp, :::3000->3000/tcp, 8889/tcp   halo-dock_nodejs_1
4bc63e62cdfa   postgres:13.1               "docker-entrypoint.s…"   5 minutes ago   Up 5 minutes                0.0.0.0:5432->5432/tcp, :::5432->5432/tcp             db_pg
71fb9d382c12   redis                       "docker-entrypoint.s…"   5 minutes ago   Up 5 minutes                0.0.0.0:6379->6379/tcp, :::6379->6379/tcp             redis1

root@5ae1f25f34cf:/src# nc -vv redis1 6379
Connection to redis1 (172.22.0.2) 6379 port [tcp/redis] succeeded!

What is going wrong here? How to solve this connection refused issue?

update

I try to change with static ip of redis docker's host. But it keep up with the 127 address?? js issue or else?

[nodemon] app crashed - waiting for file changes before starting...
[nodemon] restarting due to changes...
[nodemon] starting `node tchat/chatServer.js`
{
  port: 3000,
  debug: true,
  dbPort: 6379,
  dbHost: '172.22.0.2',
  dbOptions: {},
  mainroom: 'MainRoom'
}
node:internal/process/promises:288
            triggerUncaughtException(err, true /* fromPromise */);
            ^

Error: connect ECONNREFUSED 127.0.0.1:6379
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16)
Emitted 'error' event on Commander instance at:
    at RedisSocket.<anonymous> (/src/tchat/node_modules/@redis/client/dist/lib/client/index.js:390:14)
    at RedisSocket.emit (node:events:513:28)
    at RedisSocket._RedisSocket_connect (/src/tchat/node_modules/@redis/client/dist/lib/client/socket.js:167:18)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  errno: -111,
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '127.0.0.1',
  port: 6379
}

Node.js v18.14.2
[nodemon] app crashed - waiting for file changes before starting...
adib-enc
  • 433
  • 1
  • 5
  • 6
  • Somehow redis1 resolves to 127.0.0.1 in your nodejs container, but to the correct IP in your NC. I dont know why the service name lookup works the second time, but this seems to be a DNS resolving issue, I would inject the redis1 hostname into the /etc/hosts to fix it or look at the timing of the startup of the containers. Maybe your redis1 doesn't exist yet when you start the nodejs? – sleepyhead May 16 '23 at 05:09
  • @sleepyhead about redis1 doesn't exist: it is already declared there that nodejs depends_on: redis1, is that already correct? I will try to check the dns resolving issue then. – adib-enc May 16 '23 at 06:12
  • Do you need to put a `socket:` object inside the `redis.createClient()` parameter, as in [this answer](/a/74867148)? More generally the answers to [Getting Error: connect ECONNREFUSED 127.0.0.1:6379 in docker-compose while connecting redis](https://stackoverflow.com/questions/71717395/getting-error-connect-econnrefused-127-0-0-16379-in-docker-compose-while-conne) seem to focus on that argument list in an otherwise-correct Docker environment. – David Maze May 16 '23 at 10:36
  • From your update it looks like you updated the config, but it looks to me that the docker image. Either check with docker exec inside your running container if the tchat/chatServer.js is indeed what you expect it to be, or check with docker images what the creation timestamp is of the image. With NC you prove that TCP sockets to redis works, redis1 resolves to the right container and if the chat program still wants to go to 127.0.0.1 it looks like the client did not get updated. – sleepyhead May 19 '23 at 06:40

0 Answers0