Getting Started with Docker Using Node – Part II - connection refused

General
, ,
1

I’m trying to work through “Getting Started with Docker Using Node – Part II”
When I run the NodeJS container, either manually or with Composer, the node server fails with the error:

connect ECONNREFUSED 127.0.0.1:27017

The database.connect is getting this address:

mongodb://localhost:27017/ronin

The CONNECTIONSTRING is:
CONNECTIONSTRING=mongodb://mongo:27017/notes

Here is the entire compose file:

version: '3.8'
services:
 notes:
   build:
     context: .
   ports:
     - 8000:8000
     - 9229:9229
   environment:
     - CONNECTIONSTRING=mongodb://mongo:27017/notes
   volumes:
     - ./:/code
   command: npm run debug
 mongo:
   image: mongo:4.2.8
   ports:
     - 27017:27017
   volumes:
     - mongodb:/data/db
     - mongodb_config:/data/configdb
volumes:
   mongodb:
   mongodb_config:

I don’t think this address:
mongodb://localhost:27017/ronin
should contain localhost. These are 2 containers trying to talk to each other. How or where does:
CONNECTIONSTRING=mongodb://mongo:27017/notes
get turned into:
mongodb://localhost:27017/ronin ?

BTW, The node server is running for about 30 seconds and does accept curl requests and does seem to be passing data to mongo.

Here are the error messages from debug window:

internal/process/warning.js:32 (node:33) UnhandledPromiseRejectionWarning: Error: Error connecting to mongo. URL: mongodb://localhost:27017/ronin  connect ECONNREFUSED 127.0.0.1:27017
    at connect (/app/node_modules/ronin-database/lib/index.js:18:9)
writeOut @ internal/process/warning.js:32
onWarning @ internal/process/warning.js:84
emit @ events.js:315
(anonymous) @ internal/process/warning.js:57
processTicksAndRejections @ internal/process/task_queues.js:79
TickObject
init @ internal/inspector_async_hook.js:25
emitInitNative @ internal/async_hooks.js:144
emitInitScript @ internal/async_hooks.js:350
nextTick @ internal/process/task_queues.js:135
emitWarning @ internal/process/warning.js:135
emitUnhandledRejectionWarning @ internal/process/promises.js:151
processPromiseRejections @ internal/process/promises.js:211
processTicksAndRejections @ internal/process/task_queues.js:98
internal/process/warning.js:32 (node:33) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
writeOut @ internal/process/warning.js:32
onWarning @ internal/process/warning.js:84
emit @ events.js:315
(anonymous) @ internal/process/warning.js:57
processTicksAndRejections @ internal/process/task_queues.js:79
TickObject
init @ internal/inspector_async_hook.js:25
emitInitNative @ internal/async_hooks.js:144
emitInitScript @ internal/async_hooks.js:350
nextTick @ internal/process/task_queues.js:135
emitWarning @ internal/process/warning.js:135
emitUnhandledRejectionWarning @ internal/process/promises.js:156
processPromiseRejections @ internal/process/promises.js:211
processTicksAndRejections @ internal/process/task_queues.js:98
internal/process/warning.js:32 (node:33) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
2

I commented out a line in the tutorial code and it’s working.

3

Would you like to share which line so other users can find your solution? :slight_smile:

4

Yes, sorry. I’ll find the line. It’s in the ronin-database/index.js.

5

Here’s the part I commented out:

async function getConnection( name = 'default' ) {
	let connection = connections[ name ]
	if( !connection ) {
		// connection = await connect( 'mongodb://localhost:27017/ronin' )
        // getConnection() was getting called multiple times, even though a connection was established.
        // So I commented out the default case.
	}

	return connection
}
6

Well that indeed is the source of the problem, change it to your environment variable

7

That part would run only if there was no default connection defined. So I don’t know why it would run if connection was already established. I’m not a NodeJS developer though and I couldn’t find where this source code came from (I didn’t try really hard, just scrolled in Part 1 and Part 2), but if it was downloaded from a Git repo for example, then maybe it was changed since the blog post was written. It is for years old.

But thank you for sharing what helped you.