Sudhir
Sudhir

Reputation: 352

DOCKER : MongooseError [MongooseServerSelectionError]: getaddrinfo ENOTFOUND mongo

I am trying to connect mongodb with my app in docker container. I'm using mongoose package, this is the code that i wrote

mongoose.connect("mongodb://mongo:27016/IssueTracker", { useNewUrlParser: true,useUnifiedTopology: true },(err: Error) => {
    err ? console.log(err) : console.log("Mongodb database connected");
}); 

This i my docker-compose.yml file

version: "3"
services:
    app:
        container_name: IssueTracker
        restart: always
        build: .
        ports: 
            - '9000:9000'
        links:
            - mongo
    mongo:
        container_name: mongo
        image: mongo
        ports:
            - '27017:27016'

And here is my Dockerfile

FROM node:13

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 9000

RUN ["npm","run","dev"]

This the error which i get when i try to run docker-compose up in my docker cmdline

server started on port 9000
MongooseError [MongooseServerSelectionError]: getaddrinfo ENOTFOUND mongo
        at new MongooseServerSelectionError (/app/node_modules/mongoose/lib/error/serverSelection.js:22:11)
        at NativeConnection.Connection.openUri (/app/node_modules/mongoose/lib/connection.js:823:32)
        at Mongoose.connect (/app/node_modules/mongoose/lib/index.js:333:15)
        at Object.<anonymous> (/app/src/app.ts:9:10)
        at Module._compile (internal/modules/cjs/loader.js:1123:30)
        at Module.m._compile (/app/node_modules/ts-node/src/index.ts:839:23)
        at Module._extensions..js (internal/modules/cjs/loader.js:1143:10)
        at Object.require.extensions.<computed> [as .ts] (/app/node_modules/ts-node/src/index.ts:842:12)
        at Module.load (internal/modules/cjs/loader.js:972:32)
        at Function.Module._load (internal/modules/cjs/loader.js:872:14)
        at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
        at main (/app/node_modules/ts-node/src/bin.ts:227:14)
        at Object.<anonymous> (/app/node_modules/ts-node/src/bin.ts:513:3)
        at Module._compile (internal/modules/cjs/loader.js:1123:30)
        at Object.Module._extensions..js (internal/modules/cjs/loader.js:1143:10)
        at Module.load (internal/modules/cjs/loader.js:972:32) {
      reason: TopologyDescription {
        type: 'Single',
        setName: null,
        maxSetVersion: null,
        maxElectionId: null,
        servers: Map(1) { 'mongo:27016' => [ServerDescription] },
        stale: false,
        compatible: true,
        compatibilityError: null,
        logicalSessionTimeoutMinutes: null,
        heartbeatFrequencyMS: 10000,
        localThresholdMS: 15,
        commonWireVersion: null
      },
      [Symbol(mongoErrorContextSymbol)]: {}
    }

Tried to check if any of my container in docker are using the mentioned port so that might create this error and none were using the same port. I'm new to docker so don't know so much about it i tried to check some online solutions but it didn't help

Upvotes: 9

Views: 12772

Answers (3)

Hugh Esco
Hugh Esco

Reputation: 67

I was seeing this error and a mongo-db exited with code 14 error today. Resolved the issue by addressing a disk full error which seems to have been the root cause.

Upvotes: 0

Johnny Baptista
Johnny Baptista

Reputation: 151

Try creating and using a network instead of link

version: "3"
services:
    app:
        container_name: IssueTracker
        restart: always
        build: .
        ports: 
            - '9000:9000'
        networks: #here
            - my-network
    mongo:
        container_name: mongo
        image: mongo
        ports:
            - '27017:27016'
        networks: #here
            - my-network 
    
    networks: #here
        my-network:
            driver: bridge

Upvotes: 9

Rob Evans
Rob Evans

Reputation: 2874

Some commands worth using to understand whats going on:

docker ps -a - lists all containers and their status docker ps -aq - lists just the container IDs.

docker container list --all - the same as docker ps -a

docker container inspect [container_id] - this outputs a bunch of information related to the container - at the bottom you'll find network information (IP Address, port mappings). This is my go to when there are issues.

Often I find an old container blocking a port I want to use so...

docker rm -f $(docekr ps -aq) - forcefully removes all containers. This effectively cleans away your docker containers and gives you a clean slate (although may leave orphan volumes which can cause issues if you want an entirely fresh image with a fresh volume mount).

The other place to check would be the logs for the application/db in the container itself... to log into a docker container and get a command terminal:

docker exec -it [container_id] bash - or sh in place of bash, (or your preferred terminal choice if its supported). The last param here a command to execute on the container. You could just write ls -al. Note: the container must be in a running state for this to work.

Also worth noting the exposed port of your mongo container is 27016 rather than the one listed in the connection: mongodb://mongo:27016 - 27016 is the port exposed internally (inside the container). 27017 is the exposed port you should use for connections from other containers/external locations. If the node app was running in the container then you might have some luck but this goes against best practices; One app per container.

My method for remembering the order of port mappings is src(localhost):destination(container) - this is the same for most unix commands: cp, scp, mv, etc. i.e. we write mv/scp/cp src_file dest_dir so its easier to know which port you should be connecting to if you follow this rule of thumb.

You'll also want to check, from the node container (docker exec -it [node_container_id] bash), that you can ping the mongo container. You may even be able to telnet [mongo_ip] 27017 to the mongo container using the port you're expecting to be open. This will prove the two hosts can communicate over the network. Then you know its not a network issue but an application issue.

Upvotes: 3

Related Questions