search

typegoose / mongodb-memory-server

Manage & spin up mongodb server binaries with zero(or slight) configuration for tests.
https://typegoose.github.io/mongodb-memory-server/
MIT License
2.59k stars 187 forks source link

Can't connect to dockerized mongodb-memory-server replica set running as a service in GitLab #815

Open diegosasw opened 1 year ago

diegosasw commented 1 year ago

NodeJS: 18 mongodb-memory-server-*: 9.0.1 mongodb(the binary version): ? mongodb(the js package): 6.1.0 system: Linux / Docker package: mongo-memory-server

What is your question?

I wonder if there is any mongodb-memory-server configuration that might be involved in the fact that I can't connect to the server when running within a docker container as a GitLab CI/CD service in a pipeline's job.

I created this question in StackOverflow with full details https://stackoverflow.com/q/77315673/2948212 but basically I have dockerized the application here https://gitlab.com/sunnyatticsoftware/mongodb-rs binding IPs to all and using a replica set, and it's all good when I test it locally

docker run --name mongodbrs -p 27017:27017 registry.gitlab.com/sunnyatticsoftware/mongodb-rs

and I can properly connect to mongodb://127.0.0.1:27017/?replicaSet=rs0

And it's also good when I run the docker container and I connect to the application through a hostname alias like mongors where there is an entry on my /etc/hosts pointing mongors to 127.0.0.1 so that I can use connection string

mongodb://mongors:27017/?replicaSet=rs0

But in GitLab CI/CD the connectivity fails. See https://gitlab.com/sunnyatticsoftware/mongodb-rs-tester/-/jobs/5319052214

Is this something related to mongodb-memory-server configuration?

hasezoey commented 1 year ago

But in GitLab CI/CD the connectivity fails. See https://gitlab.com/sunnyatticsoftware/mongodb-rs-tester/-/jobs/5319052214

The current user is not authorized to access the job log.

mongodb-memory-server is not meant to run as a service and is meant to directly run as setup in a testing engine (or some playground like node repl), and so the default are adjusted to that, which means by default ports a generated if they are blocked, and unless MongoMemoryServer.start(forceSamePort) is set, it will always try to test the port (that option is currently unavailable for MongoMemoryServer.create or replsets, see #816)

as i am not allowed to view the log, i cannot say for sure what is happening, but it is likely that a different port than 27017 was used.

if you should post the log (or i somehow gain access) make sure Debug logs are enabled

diegosasw commented 1 year ago

Thanks a lot for your reply

If I want the job logs to be public I have to disable the debug. Here is the job logs available for unauthenticated users https://gitlab.com/sunnyatticsoftware/mongodb-rs-tester/-/jobs/5321722538

If I enable debug, the full log is attached here. raw_log_pipeline.txt

As per GitLab services documentation I made a few changes in the Dockerfile to expose the port and to include a healthcheck, but no luck, still unable to connect to Mongo in CI/CD job

If the problem is, like you suggest, the force port not being set, I guess there is no workaround yet for replica set?

hasezoey commented 1 year ago

If I want the job logs to be public I have to disable the debug. Here is the job logs available for unauthenticated users If I enable debug, the full log is attached here.

it seems like there is some kind of misunderstanding, i am asking about mongodb-memory-server debug logs, which can be enabled either via the package.json or as a environment variable (recommended), not via gitlab ci debug mode

once debug logging is enabled, you should see something along the lines of:

  MongoMS:MongoMemoryServer create: Called .create() method +0ms
  MongoMS:MongoMemoryServer Mongo[unknown]: start: Called .start() method +2ms
  MongoMS:MongoMemoryServer Mongo[unknown]: _startUpInstance: Called MongoMemoryServer._startUpInstance() method +2ms
  MongoMS:MongoMemoryServer Mongo[unknown]: getStartOptions: forceSamePort: false +1ms
diegosasw commented 1 year ago

Ah, yes, sorry.

I've made the DEBUG mode configurable so that I can decide at runtime whether to enable or disable debug traces


docker run --name mongodbrs -p 27017:27017 -e MONGOMS_DEBUG=1 registry.gitlab.com/sunnyatticsoftware/mongodb-rs

Complete log of the container running as a GitLab service attached here. raw_log_pipeline.txt

I can see some relevant traces such as

getStartOptions: forceSamePort: false
...
ip: '::,0.0.0.0'
...
port: 27017
prepareCommandArgs: final argument array:["--port","27017","--dbpath","/tmp/mongo-mem-DpiHvh","--replSet","rs0","--storageEngine","wiredTiger","--bind_ip","::,0.0.0.0","--noauth"]
...
MongoMS:MongoInstance Mongo[27017]: stdoutHandler: ""{"t":{"$date":"2023-10-18T18:23:26.792+00:00"},"s":"W",  "c":"NETWORK",  "id":23021,   "ctx":"initandlisten","msg":"Found no addresses for peer","attr":{"peer":{"code":7,"codeName":"HostNotFound","errmsg":"Could not find address for [::]:27017: SocketException: Host not found (authoritative)"}}}""
...
did not find local replica set configuration document at startup","attr":{"error":{"code":47,"codeName":"NoMatchingDocument","errmsg":"Did not find replica set configuration document in local.system.replset"
...
MongoMS:MongoMemoryServer Mongo[27017]: start: Instance fully Started
...
 MongoMS:MongoMemoryServer Mongo[27017]: getUri: running undefined undefined
...
"msg":"Options set by command line","attr":{"options":{"net":{"bindIp":"::,0.0.0.0","port":27017},"replication":{"replSet":"rs0"},"security":{"authorization":"disabled"},"storage":{"dbPath":"/tmp/mongo-mem-DpiHvh","engine":"wiredTiger"}}}}""
...
etc.

Hopefully it helps.

Thanks again

hasezoey commented 1 year ago

2023-10-18T18:23:26.749Z MongoMS:MongoInstance Mongo[27017]: prepareCommandArgs: final argument array:["--port","27017","--dbpath","/tmp/mongo-mem-DpiHvh","--replSet","rs0","--storageEngine","wiredTiger","--bind_ip","::,0.0.0.0","--noauth"] 2023-10-18T18:23:27.234Z MongoMS:MongoInstance Mongo[27017]: start: Processes Started 2023-10-18T18:23:27.235Z MongoMS:MongoMemoryServer Mongo[27017]: start: Instance fully Started

with those it is clear that the port specified is actually used, so no port is generated

I made a few changes in the Dockerfile to expose the port and to include a healthcheck, but no luck, still unable to connect to Mongo in CI/CD job

what should a healthcheck change aside from showing what status the service is in? is it actually showing as connected (if the status is visible)

as can be seen in the following log, your driver actually connects, but somehow closes the connection again:

2023-10-18T18:23:56.993Z MongoMS:MongoInstance Mongo[27017]: stdoutHandler: ""{"t":{"$date":"2023-10-18T18:23:56.993+00:00"},"s":"I",  "c":"NETWORK",  "id":22943,   "ctx":"listener","msg":"Connection accepted","attr":{"remote":"172.17.0.4:54396","uuid":"c58674ac-2641-4466-905a-3118f5df3604","connectionId":9,"connectionCount":1}}""
2023-10-18T18:23:56.994Z MongoMS:MongoInstance Mongo[27017]: stdoutHandler: ""{"t":{"$date":"2023-10-18T18:23:56.993+00:00"},"s":"I",  "c":"NETWORK",  "id":22943,   "ctx":"listener","msg":"Connection accepted","attr":{"remote":"172.17.0.4:54398","uuid":"a1587c15-8fdc-4d6c-97bf-0dc6881aff59","connectionId":10,"connectionCount":2}}""
2023-10-18T18:23:57.032Z MongoMS:MongoInstance Mongo[27017]: stdoutHandler: ""{"t":{"$date":"2023-10-18T18:23:57.032+00:00"},"s":"I",  "c":"NETWORK",  "id":51800,   "ctx":"conn9","msg":"client metadata","attr":{"remote":"172.17.0.4:54396","client":"conn9","doc":{"driver":{"name":"mongo-csharp-driver","version":"2.22.0.0"},"os":{"type":"Linux","name":"Linux 5.4.109+ #1 SMP Wed Jun 16 20:00:10 PDT 2021","architecture":"x86_64","version":"5.4.109+"},"platform":".NET 7.0.12"}}}""
2023-10-18T18:23:57.032Z MongoMS:MongoInstance Mongo[27017]: stdoutHandler: ""{"t":{"$date":"2023-10-18T18:23:57.032+00:00"},"s":"I",  "c":"NETWORK",  "id":51800,   "ctx":"conn10","msg":"client metadata","attr":{"remote":"172.17.0.4:54398","client":"conn10","doc":{"driver":{"name":"mongo-csharp-driver","version":"2.22.0.0"},"os":{"type":"Linux","name":"Linux 5.4.109+ #1 SMP Wed Jun 16 20:00:10 PDT 2021","architecture":"x86_64","version":"5.4.109+"},"platform":".NET 7.0.12"}}}""
2023-10-18T18:23:57.100Z MongoMS:MongoInstance Mongo[27017]: stdoutHandler: ""{"t":{"$date":"2023-10-18T18:23:57.099+00:00"},"s":"I",  "c":"NETWORK",  "id":22944,   "ctx":"conn10","msg":"Connection ended","attr":{"remote":"172.17.0.4:54398","uuid":"a1587c15-8fdc-4d6c-97bf-0dc6881aff59","connectionId":10,"connectionCount":1}}""
2023-10-18T18:23:57.106Z MongoMS:MongoInstance Mongo[27017]: stdoutHandler: ""{"t":{"$date":"2023-10-18T18:23:57.106+00:00"},"s":"I",  "c":"NETWORK",  "id":22944,   "ctx":"conn9","msg":"Connection ended","attr":{"remote":"172.17.0.4:54396","uuid":"c58674ac-2641-4466-905a-3118f5df3604","connectionId":9,"connectionCount":0}}""

maybe you have some kind of driver misconfiguration? i dont know about how the csharp mongodb driver works, so i cant really help with that

also it seems like the service is not properly shutdown, not that this would change anything (.stop never being called and just terminated i guess)

diegosasw commented 1 year ago

Thanks.

I created a different tester project for GitLab CI/CD to leave the C# Mongo Driver out of the picture and use mongosh instead Here it is https://gitlab.com/sunnyatticsoftware/mongodb-rs-tester-mongosh

The CI/CD pipeline fails. Log attached raw_log_pipeline.txt

Things I found

The command I run in pipeline is

mongosh "mongodb://mongors:27017?replicaSet=rs0" --quiet --eval "db.runCommand({ ping: 1 })" || exit 1

as per my .gitlab-ci.yml

hasezoey commented 1 year ago

actually now that i look at the logs again, the drivers are trying to connect to 127.0.0.1 (localhost), but from my understanding it should be different because the service will get its own internal ip which should be replaced by the mongors variable, right?

could you maybe print the output of cat /etc/hosts in the consuming gitlab ci (where your driver runs)?

though it is somewhat weird, because the server actually logs a connection attempt, so it is resolved but refused?

diegosasw commented 1 year ago

It seems to reject the connection, yes. But I also think it's not a problem of unreachable host/alias as it connects well when not specifying replicaSet query parameter.

Below it's what the log shows when I display the hosts file. As you can see, in addition to showing /etc/hosts I try to connect to 

$ mongosh --version
2.0.2
$ cat /etc/hosts
127.0.0.1   localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.3  registry.gitlab.com__sunnyatticsoftware__mongodb-rs 398338eeb54b runner-ns46nmmj-project-51414559-concurrent-0-e41c37375e72e41f-registry.gitlab.com__sunnyatticsoftware__mongodb-rs-0
172.17.0.3  registry.gitlab.com-sunnyatticsoftware-mongodb-rs 398338eeb54b runner-ns46nmmj-project-51414559-concurrent-0-e41c37375e72e41f-registry.gitlab.com__sunnyatticsoftware__mongodb-rs-0
172.17.0.3  mongors 398338eeb54b runner-ns46nmmj-project-51414559-concurrent-0-e41c37375e72e41f-registry.gitlab.com__sunnyatticsoftware__mongodb-rs-0
172.17.0.4  runner-ns46nmmj-project-51414559-concurrent-0

$ echo "Connect mongosh to mongodb://mongors:27017"
Connect mongosh to mongodb://mongors:27017
$ mongosh "mongodb://mongors:27017" --quiet --eval "db.runCommand({ ping: 1 })" || exit 1
[service:registry.gitlab.com__sunnyatticsoftware__mongodb-rs-registry.gitlab.com-sunnyatticsoftware-mongodb-rs-mongors] 2023-10-21T20:48:48.268613610Z 2023-10-21T20:48:48.268Z MongoMS:MongoInstance Mongo[27017]: stdoutHandler: ""{"t":{"$date":"2023-10-21T20:48:48.268+00:00"},"s":"I",  "c":"NETWORK",  "id":22943,   "ctx":"listener","msg":"Connection accepted","attr":{"remote":"172.17.0.4:55660","uuid":"2a8e7616-78df-4b99-99e6-85c58352c0eb","connectionId":4,"connectionCount":1}}""
[service:registry.gitlab.com__sunnyatticsoftware__mongodb-rs-registry.gitlab.com-sunnyatticsoftware-mongodb-rs-mongors] 2023-10-21T20:48:48.272056363Z 2023-10-21T20:48:48.271Z MongoMS:MongoInstance Mongo[27017]: stdoutHandler: ""{"t":{"$date":"2023-10-21T20:48:48.271+00:00"},"s":"I",  "c":"NETWORK",  "id":51800,   "ctx":"conn4","msg":"client metadata","attr":{"remote":"172.17.0.4:55660","client":"conn4","doc":{"application":{"name":"mongosh 2.0.2"},"driver":{"name":"nodejs|mongosh","version":"6.0.0|2.0.2"},"platform":"Node.js v20.8.1, LE","os":{"name":"linux","architecture":"x64","version":"5.4.109+","type":"Linux"}}}}""
[service:registry.gitlab.com__sunnyatticsoftware__mongodb-rs-registry.gitlab.com-sunnyatticsoftware-mongodb-rs-mongors] 2023-10-21T20:48:48.286567180Z 2023-10-21T20:48:48.286Z MongoMS:MongoInstance Mongo[27017]: stdoutHandler: ""{"t":{"$date":"2023-10-21T20:48:48.286+00:00"},"s":"I",  "c":"NETWORK",  "id":22943,   "ctx":"listener","msg":"Connection accepted","attr":{"remote":"172.17.0.4:55662","uuid":"dd86bb85-3095-4003-ac6e-759bdbd5ee73","connectionId":5,"connectionCount":2}}
[service:registry.gitlab.com__sunnyatticsoftware__mongodb-rs-registry.gitlab.com-sunnyatticsoftware-mongodb-rs-mongors] 2023-10-21T20:48:48.286589530Z {"t":{"$date":"2023-10-21T20:48:48.286+00:00"},"s":"I",  "c":"NETWORK",  "id":22943,   "ctx":"listener","msg":"Connection accepted","attr":{"remote":"172.17.0.4:55664","uuid":"f878666f-a628-445f-b06f-5f4f9464c5f2","connectionId":6,"connectionCount":3}}""
[service:registry.gitlab.com__sunnyatticsoftware__mongodb-rs-registry.gitlab.com-sunnyatticsoftware-mongodb-rs-mongors] 2023-10-21T20:48:48.287491289Z 2023-10-21T20:48:48.287Z MongoMS:MongoInstance Mongo[27017]: stdoutHandler: ""{"t":{"$date":"2023-10-21T20:48:48.287+00:00"},"s":"I",  "c":"NETWORK",  "id":51800,   "ctx":"conn5","msg":"client metadata","attr":{"remote":"172.17.0.4:55662","client":"conn5","doc":{"application":{"name":"mongosh 2.0.2"},"driver":{"name":"nodejs|mongosh","version":"6.0.0|2.0.2"},"platform":"Node.js v20.8.1, LE","os":{"name":"linux","architecture":"x64","version":"5.4.109+","type":"Linux"}}}}""
[service:registry.gitlab.com__sunnyatticsoftware__mongodb-rs-registry.gitlab.com-sunnyatticsoftware-mongodb-rs-mongors] 2023-10-21T20:48:48.288369637Z 2023-10-21T20:48:48.288Z MongoMS:MongoInstance Mongo[27017]: stdoutHandler: ""{"t":{"$date":"2023-10-21T20:48:48.288+00:00"},"s":"I",  "c":"NETWORK",  "id":51800,   "ctx":"conn6","msg":"client metadata","attr":{"remote":"172.17.0.4:55664","client":"conn6","doc":{"application":{"name":"mongosh 2.0.2"},"driver":{"name":"nodejs|mongosh","version":"6.0.0|2.0.2"},"platform":"Node.js v20.8.1, LE","os":{"name":"linux","architecture":"x64","version":"5.4.109+","type":"Linux"}}}}""
[service:registry.gitlab.com__sunnyatticsoftware__mongodb-rs-registry.gitlab.com-sunnyatticsoftware-mongodb-rs-mongors] 2023-10-21T20:48:48.296276792Z 2023-10-21T20:48:48.296Z MongoMS:MongoInstance Mongo[27017]: stdoutHandler: ""{"t":{"$date":"2023-10-21T20:48:48.296+00:00"},"s":"I",  "c":"NETWORK",  "id":22943,   "ctx":"listener","msg":"Connection accepted","attr":{"remote":"172.17.0.4:55666","uuid":"529da4a0-1ddf-4d87-b4fc-ed56c1d3f9be","connectionId":7,"connectionCount":4}}""
[service:registry.gitlab.com__sunnyatticsoftware__mongodb-rs-registry.gitlab.com-sunnyatticsoftware-mongodb-rs-mongors] 2023-10-21T20:48:48.297127200Z 2023-10-21T20:48:48.297Z MongoMS:MongoInstance Mongo[27017]: stdoutHandler: ""{"t":{"$date":"2023-10-21T20:48:48.296+00:00"},"s":"I",  "c":"NETWORK",  "id":51800,   "ctx":"conn7","msg":"client metadata","attr":{"remote":"172.17.0.4:55666","client":"conn7","doc":{"application":{"name":"mongosh 2.0.2"},"driver":{"name":"nodejs|mongosh","version":"6.0.0|2.0.2"},"platform":"Node.js v20.8.1, LE","os":{"name":"linux","architecture":"x64","version":"5.4.109+","type":"Linux"}}}}""
{
  ok: 1,
  '$clusterTime': {
    clusterTime: Timestamp({ t: 1697921325, i: 1 }),
    signature: {
      hash: Binary.createFromBase64("AAAAAAAAAAAAAAAAAAAAAAAAAAA=", 0),
      keyId: Long("0")
    }
  },
  operationTime: Timestamp({ t: 1697921325, i: 1 })
}

$ echo "Connect mongosh to mongodb://mongors:27017?replicaSet=rs0 (notice the replicaSet parameter)"
Connect mongosh to mongodb://mongors:27017?replicaSet=rs0 (notice the replicaSet parameter)
$ mongosh "mongodb://mongors:27017?replicaSet=rs0" --quiet --eval "db.runCommand({ ping: 1 })" || exit 1
[service:registry.gitlab.com__sunnyatticsoftware__mongodb-rs-registry.gitlab.com-sunnyatticsoftware-mongodb-rs-mongors] 2023-10-21T20:48:48.555348507Z 2023-10-21T20:48:48.555Z MongoMS:MongoInstance Mongo[27017]: stdoutHandler: ""{"t":{"$date":"2023-10-21T20:48:48.554+00:00"},"s":"I",  "c":"NETWORK",  "id":22944,   "ctx":"conn5","msg":"Connection ended","attr":{"remote":"172.17.0.4:55662","uuid":"dd86bb85-3095-4003-ac6e-759bdbd5ee73","connectionId":5,"connectionCount":2}}
[service:registry.gitlab.com__sunnyatticsoftware__mongodb-rs-registry.gitlab.com-sunnyatticsoftware-mongodb-rs-mongors] 2023-10-21T20:48:48.555404277Z {"t":{"$date":"2023-10-21T20:48:48.554+00:00"},"s":"I",  "c":"NETWORK",  "id":22944,   "ctx":"conn7","msg":"Connection ended","attr":{"remote":"172.17.0.4:55666","uuid":"529da4a0-1ddf-4d87-b4fc-ed56c1d3f9be","connectionId":7,"connectionCount":1}}
[service:registry.gitlab.com__sunnyatticsoftware__mongodb-rs-registry.gitlab.com-sunnyatticsoftware-mongodb-rs-mongors] 2023-10-21T20:48:48.555413937Z {"t":{"$date":"2023-10-21T20:48:48.554+00:00"},"s":"I",  "c":"NETWORK",  "id":22944,   "ctx":"conn4","msg":"Connection ended","attr":{"remote":"172.17.0.4:55660","uuid":"2a8e7616-78df-4b99-99e6-85c58352c0eb","connectionId":4,"connectionCount":0}}
[service:registry.gitlab.com__sunnyatticsoftware__mongodb-rs-registry.gitlab.com-sunnyatticsoftware-mongodb-rs-mongors] 2023-10-21T20:48:48.555420517Z {"t":{"$date":"2023-10-21T20:48:48.554+00:00"},"s":"I",  "c":"NETWORK",  "id":22944,   "ctx":"conn6","msg":"Connection ended","attr":{"remote":"172.17.0.4:55664","uuid":"f878666f-a628-445f-b06f-5f4f9464c5f2","connectionId":6,"connectionCount":3}}""
[service:registry.gitlab.com__sunnyatticsoftware__mongodb-rs-registry.gitlab.com-sunnyatticsoftware-mongodb-rs-mongors] 2023-10-21T20:48:48.950560737Z 2023-10-21T20:48:48.950Z MongoMS:MongoInstance Mongo[27017]: stdoutHandler: ""{"t":{"$date":"2023-10-21T20:48:48.950+00:00"},"s":"I",  "c":"NETWORK",  "id":22943,   "ctx":"listener","msg":"Connection accepted","attr":{"remote":"172.17.0.4:55668","uuid":"261247c9-9600-4006-a558-1bd88230adaf","connectionId":8,"connectionCount":1}}""
[service:registry.gitlab.com__sunnyatticsoftware__mongodb-rs-registry.gitlab.com-sunnyatticsoftware-mongodb-rs-mongors] 2023-10-21T20:48:48.954180531Z 2023-10-21T20:48:48.954Z MongoMS:MongoInstance Mongo[27017]: stdoutHandler: ""{"t":{"$date":"2023-10-21T20:48:48.953+00:00"},"s":"I",  "c":"NETWORK",  "id":51800,   "ctx":"conn8","msg":"client metadata","attr":{"remote":"172.17.0.4:55668","client":"conn8","doc":{"application":{"name":"mongosh 2.0.2"},"driver":{"name":"nodejs|mongosh","version":"6.0.0|2.0.2"},"platform":"Node.js v20.8.1, LE","os":{"name":"linux","architecture":"x64","version":"5.4.109+","type":"Linux"}}}}""
[service:registry.gitlab.com__sunnyatticsoftware__mongodb-rs-registry.gitlab.com-sunnyatticsoftware-mongodb-rs-mongors] 2023-10-21T20:48:48.960618122Z 2023-10-21T20:48:48.960Z MongoMS:MongoInstance Mongo[27017]: stdoutHandler: ""{"t":{"$date":"2023-10-21T20:48:48.960+00:00"},"s":"I",  "c":"NETWORK",  "id":22944,   "ctx":"conn8","msg":"Connection ended","attr":{"remote":"172.17.0.4:55668","uuid":"261247c9-9600-4006-a558-1bd88230adaf","connectionId":8,"connectionCount":0}}""
MongoNetworkError: connect ECONNREFUSED 127.0.0.1:27017
Cleaning up project directory and file based variables
00:00
ERROR: Job failed: exit code 1

Full raw log here raw_log_pipeline.txt

hasezoey commented 1 year ago

just to confirm this has nothing to do with a / missing between the port and ?? thought that would not explain why there is a connection log in the instance, but the connection failing

But I also think it's not a problem of unreachable host/alias as it connects well when not specifying replicaSet query parameter.

this is quite weird and i dont understand as well, because according to gitlabs documentation / issues it should not work and should be:

172.17.0.3  mongors 398338eeb54b runner-ns46nmmj-project-51414559-concurrent-0-e41c37375e72e41f-registry.gitlab.com__sunnyatticsoftware__mongodb-rs-0

personally i dont know anything else to try or suggest to fix this, from what i can tell the server (instance) is configured correctly (it is a replset with correct name, it is the port that is set, it is bound to the documentation suggested all interfaces)

pnordhus commented 7 months ago

I think this issue might come from the server discovery logic implemented in many (all?) MongoDB drivers:

When the client connects to the replica set via any accessible IP/port, it fetches the list of all replica set members, disconnects and then connects to one (or multiple) of the member hosts it received from the server.

I assume in this case the following is happening:

  1. the replica set is configured with 127.0.0.1:27017 as only member. This can be seen in the server log: "members":[{"_id":0,"host":"127.0.0.1:27017", ...}]
  2. the client connects to mongors:27017 and fetches the members list. This is the successful connection in the server log
  3. the client disconnects and then connects to the only member host returned by the server: 127.0.0.1:27017. This fails, because the server is running in a different container

In similar CI/CD setups, I've used the directConnection argument when connecting, e.g. mongodb://mongors:27017?directConnection=true. This disables the aforementioned member discovery logic and makes the client connect only to the address specified in the connection URI.

Alternatively, you could explicitly set mongors:27017 as member host on the MongoDB server when initializing the replica set. I'm not sure if this is possible with mongodb-memory-server, though.

hasezoey commented 7 months ago

Alternatively, you could explicitly set mongors:27017 as member host on the MongoDB server when initializing the replica set. I'm not sure if this is possible with mongodb-memory-server, though.

this is currently not possible to be overwritten in MMS, it will always be 127.0.0.1 for the replset member's host, unless a the user decides to do a manual rsconfig command (overwriting what MMS has set)