testcontainers-java: `MongoDbContainer` is not working with custom username, password and db
import org.testcontainers.containers.MongoDBContainer
import org.testcontainers.utility.DockerImageName
val mongoDBContainer = new MongoDBContainer(DockerImageName.parse(“mongo:4.0.10”))
.withEnv(“MONGO_INITDB_DATABASE”, “mytestdb”)
.withEnv(“MONGO_INITDB_ROOT_USERNAME”, “any-user”)
.withEnv(“MONGO_INITDB_ROOT_PASSWORD”, “whatever”)
mongoDBContainer.start()
mongoDBContainer.getLogs
Getting below error:
ERROR 24/11/2021 16:16:44.815 org.testcontainers.containers.MongoDBContainer A single node replica set was not initialized in a set timeout: 60 attempts
ERROR 24/11/2021 16:16:44.819 :whale: [mongo:4.0.10] Could not start container
org.testcontainers.containers.MongoDBContainer$ReplicaSetInitializationException: A single node replica set was not initialized in a set timeout: 60 attempts
Below are containers logs:
2021-11-24T10:46:44.009+0000 I CONTROL [main] ***** SERVER RESTARTED *****
2021-11-24T10:46:44.012+0000 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols ‘none’
2021-11-24T10:46:44.017+0000 I CONTROL [initandlisten] MongoDB starting : pid=28 port=27017 dbpath=/data/db 64-bit host=9d088e8e9add
2021-11-24T10:46:44.017+0000 I CONTROL [initandlisten] db version v4.0.10
2021-11-24T10:46:44.017+0000 I CONTROL [initandlisten] git version: c389e7f69f637f7a1ac3cc9fae843b635f20b766
2021-11-24T10:46:44.017+0000 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
2021-11-24T10:46:44.017+0000 I CONTROL [initandlisten] allocator: tcmalloc
2021-11-24T10:46:44.017+0000 I CONTROL [initandlisten] modules: none
2021-11-24T10:46:44.017+0000 I CONTROL [initandlisten] build environment:
2021-11-24T10:46:44.017+0000 I CONTROL [initandlisten] distmod: ubuntu1604
2021-11-24T10:46:44.017+0000 I CONTROL [initandlisten] distarch: x86_64
2021-11-24T10:46:44.017+0000 I CONTROL [initandlisten] target_arch: x86_64
2021-11-24T10:46:44.017+0000 I CONTROL [initandlisten] options: { net: { bindIp: “127.0.0.1”, port: 27017, ssl: { mode: “disabled” } }, processManagement: { fork: true, pidFilePath: “/tmp/docker-entrypoint-temp-mongod.pid” }, systemLog: { destination: “file”, logAppend: true, path: “/proc/1/fd/1” } }
2021-11-24T10:46:44.018+0000 I STORAGE [initandlisten]
2021-11-24T10:46:44.018+0000 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2021-11-24T10:46:44.018+0000 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2021-11-24T10:46:44.018+0000 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=4470M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
2021-11-24T10:46:44.482+0000 I STORAGE [initandlisten] WiredTiger message [1637750804:482274][28:0x7f2b33840a80], txn-recover: Set global recovery timestamp: 0
2021-11-24T10:46:44.490+0000 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2021-11-24T10:46:44.504+0000 I CONTROL [initandlisten]
2021-11-24T10:46:44.504+0000 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2021-11-24T10:46:44.504+0000 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2021-11-24T10:46:44.504+0000 I CONTROL [initandlisten]
2021-11-24T10:46:44.505+0000 I STORAGE [initandlisten] createCollection: admin.system.version with provided UUID: 147d194f-30f2-47ec-8121-87068d509b1e
2021-11-24T10:46:44.514+0000 I COMMAND [initandlisten] setting featureCompatibilityVersion to 4.0
2021-11-24T10:46:44.518+0000 I STORAGE [initandlisten] createCollection: local.startup_log with generated UUID: 8dc76bdb-13dc-44c7-857c-365fb90a93de
2021-11-24T10:46:44.529+0000 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory ‘/data/db/diagnostic.data’
2021-11-24T10:46:44.531+0000 I NETWORK [initandlisten] waiting for connections on port 27017
2021-11-24T10:46:44.531+0000 I STORAGE [LogicalSessionCacheRefresh] createCollection: config.system.sessions with generated UUID: 385865bb-893f-407a-a5bc-26c3b8628135
child process started successfully, parent exiting
2021-11-24T10:46:44.547+0000 I INDEX [LogicalSessionCacheRefresh] build index on: config.system.sessions properties: { v: 2, key: { lastUse: 1 }, name: “lsidTTLIndex”, ns: “config.system.sessions”, expireAfterSeconds: 1800 }
2021-11-24T10:46:44.547+0000 I INDEX [LogicalSessionCacheRefresh] building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2021-11-24T10:46:44.549+0000 I INDEX [LogicalSessionCacheRefresh] build index done. scanned 0 total records. 0 secs
2021-11-24T10:46:44.583+0000 I NETWORK [listener] connection accepted from 127.0.0.1:46572 #1 (1 connection now open)
2021-11-24T10:46:44.587+0000 I NETWORK [conn1] received client metadata from 127.0.0.1:46572 conn1: { application: { name: “MongoDB Shell” }, driver: { name: “MongoDB Internal Client”, version: “4.0.10” }, os: { type: “Linux”, name: “Ubuntu”, architecture: “x86_64”, version: “16.04” } }
2021-11-24T10:46:44.591+0000 I NETWORK [conn1] end connection 127.0.0.1:46572 (0 connections now open)
2021-11-24T10:46:44.646+0000 I NETWORK [listener] connection accepted from 127.0.0.1:46574 #2 (1 connection now open)
2021-11-24T10:46:44.647+0000 I NETWORK [conn2] received client metadata from 127.0.0.1:46574 conn2: { application: { name: “MongoDB Shell” }, driver: { name: “MongoDB Internal Client”, version: “4.0.10” }, os: { type: “Linux”, name: “Ubuntu”, architecture: “x86_64”, version: “16.04” } }
2021-11-24T10:46:44.652+0000 I NETWORK [listener] connection accepted from 127.0.0.1:46576 #3 (2 connections now open)
2021-11-24T10:46:44.653+0000 I NETWORK [conn3] received client metadata from 127.0.0.1:46576 conn3: { application: { name: “MongoDB Shell” }, driver: { name: “MongoDB Internal Client”, version: “4.0.10” }, os: { type: “Linux”, name: “Ubuntu”, architecture: “x86_64”, version: “16.04” } }
2021-11-24T10:46:44.658+0000 I NETWORK [conn3] end connection 127.0.0.1:46576 (1 connection now open)
2021-11-24T10:46:44.691+0000 I STORAGE [conn2] createCollection: admin.system.users with generated UUID: 5e685272-8668-4ca7-bab6-c0f2e39c8767
Successfully added user: {
“user” : “any-user”,
“roles” : [
{
“role” : “root”,
“db” : “admin”
}
]
}
2021-11-24T10:46:44.706+0000 E - [main] Error saving history file: FileOpenFailed: Unable to open() file /home/mongodb/.dbshell: Unknown error
2021-11-24T10:46:44.708+0000 I NETWORK [conn2] end connection 127.0.0.1:46574 (0 connections now open)
/usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
2021-11-24T10:46:44.738+0000 I CONTROL [main] ***** SERVER RESTARTED *****
2021-11-24T10:46:44.740+0000 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols ‘none’
killing process with pid: 28
2021-11-24T10:46:44.742+0000 I CONTROL [signalProcessingThread] got signal 15 (Terminated), will terminate after current cmd ends
2021-11-24T10:46:44.742+0000 I NETWORK [signalProcessingThread] shutdown: going to close listening sockets…
2021-11-24T10:46:44.742+0000 I NETWORK [signalProcessingThread] removing socket file: /tmp/mongodb-27017.sock
2021-11-24T10:46:44.743+0000 I CONTROL [signalProcessingThread] Shutting down free monitoring
2021-11-24T10:46:44.743+0000 I FTDC [signalProcessingThread] Shutting down full-time diagnostic data capture
2021-11-24T10:46:44.743+0000 I STORAGE [signalProcessingThread] WiredTigerKVEngine shutting down
2021-11-24T10:46:44.744+0000 I STORAGE [signalProcessingThread] Shutting down session sweeper thread
2021-11-24T10:46:44.745+0000 I STORAGE [signalProcessingThread] Finished shutting down session sweeper thread
2021-11-24T10:46:44.826+0000 I STORAGE [signalProcessingThread] shutdown: removing fs lock…
2021-11-24T10:46:44.826+0000 I CONTROL [signalProcessingThread] now exiting
2021-11-24T10:46:44.826+0000 I CONTROL [signalProcessingThread] shutting down with code:0
About this issue
- Original URL
- State: open
- Created 3 years ago
- Reactions: 5
- Comments: 31 (10 by maintainers)
In this case, providing a PR to extend the
MongoDBContainerto support username and password might be the best approach.Ok, thanks for the clarification. While I think the proposed workaround is decent for many users, I’d also say this a missing feature of our included
MongoDbContainer(that should allow setting those values directly via methods).Not sure how replica sets play into this story though.
At the end of mongo container log you’d see `MongoDB init process complete; ready for start up.
BadValue: security.keyFile is required when authorization is enabled with replica sets try ‘mongod --help’ for more information`
MongoDBContainer is using replica sets. Use GenericContainer instead.
Thanks for your interest in MongoDB in general and the MongoDBContainer in particular. The MongoDB official docs state which operations require a replica set. MongoDB evolves quite rapidly these days. I’m not sure that
complement documentationof the MongoDBContainer every time when MongoDB announces a new replica set feature is a good idea. Please, note that the idea of the MongoDBContainer is to cover most test cases without an end user thinking whether or not an operation requires a replica set. Regarding the MongoDBContainer doc, it explains in detail it’s motivation (test MongoDB transactions) and some difficulties in initialisation a replica set manuallyOkay, understood. The issue seems to be for average user this is not explicit enough. He wants to use testcontainers for mongodb, sees that there a specific module for it and uses it.
I see many different paths this issue could take
I think most of you already figure it out but would like to summarize and provide more context about mongodb auth.
MONGO_INITDB_ROOT_USERNAMEandMONGO_INITDB_ROOT_PASSWORDenv vars are used with an standalone instance (no ReplicaSet), which doesn’t work withMongoDBContainerbecause of the checks running against ReplicaSet. As mongodb docs stateAuthentication in MongoDB is fairly complex,. There is a PR provided by @silaev (thank you!) in order to enable authentication against a ReplicaSet. I would like to guess that most of you are interested in ReplicaSet due to is the way to go to prod instead of standalone mode.I have created a poll in order to know about needs in the community. Looking forward to see the results.