1
votes

I have three container optimised VMs running on Google Compute Engine (GCE) with each a Bitnami MongoDB Docker Container, one should be the primary Mongo DB Instance and two should be secondary.

When creating the VMs, I specified the Container Image as "bitnami/mongodb:latest" and set the environment variables according to the bitnami documentation using gce-container-declaration (also possible via the UI under "Advanced Container Options")

I can connect to the primary mongodb with the via MONGODB_ROOT_PASSWORD defined password and also the other VMs are up and are listening on their 27017 ports. The VMs can also reach each other, so the VPC and Firewall Rules are ok with Port 27017, 22 and 80 INGRESS / EGRESS.

But, when I want to get the replica set status rs.status() on the primary, I always get an "errmsg" : "no replset config has been received" error. So the nodes don't create a Replica Set... With Docker-Compose this works out of the box and the Bitnami Image also should init the Replica Set automatically, shouldn't it?

I tried a lot of things including using MONGODB_ADVERTISED_HOSTNAME with custome GCE VM Hostnames, but nothing works and I don't have any Idea how to find the issue.

enter image description here

Primary Node - Container Env. Vars:

MONGODB_ROOT_PASSWORD = 'password123'
MONGODB_REPLICA_SET_NAME = 'rep'
MONGODB_REPLICA_SET_MODE = 'primary'
MONGODB_REPLICA_SET_KEY = '321abc123'

Secondary1 Node - Container Env. Vars:

MONGODB_PRIMARY_ROOT_PASSWORD = 'password123'
MONGODB_REPLICA_SET_NAME = 'rep'
MONGODB_PRIMARY_HOST = '${VPC_LOCAL_IP_PRIMARY_NODE}'
MONGODB_PRIMARY_PORT_NUMBER = '27017'
MONGODB_REPLICA_SET_MODE = 'secondary'
MONGODB_REPLICA_SET_KEY = '321abc123'

Secondary2 Node - Container Env. Vars:

MONGODB_PRIMARY_ROOT_PASSWORD = 'password123'
MONGODB_REPLICA_SET_NAME = 'rep'
MONGODB_PRIMARY_HOST = '${VPC_LOCAL_IP_PRIMARY_NODE}'
MONGODB_PRIMARY_PORT_NUMBER = '27017'
MONGODB_REPLICA_SET_MODE = 'secondary'
MONGODB_REPLICA_SET_KEY = '321abc123'
1
" All MongoDB versions released after October 16, 2018 (3.6.9 or later, 4.0.4 or later or 4.1.5 or later) are licensed under the Server Side Public License that is not currently accepted as a Open Source license by the Open Source Iniciative (OSI)." I had no idea. Thank you for asking this question! How are you liking Bitnami?Chance
You haven't initiated a replica set it seems, which also means you can't have any primary or secondary nodes since those only exist in a replica set which you don't appear to have.D. SM
Get this working on your local machine before trying on GCP.D. SM
What do you mean with not initiated? With docker compose for example the initiation works out of the box, since "bitnami" handles it...Tobi V.
I have found an accepted answer in following thread: stackoverflow.com/questions/60822543/…Pejvak

1 Answers

0
votes

It is a strange error in fact. I have tried to launch an instance myself and could not face any issue.

Here you have a list of the steps I followed, just in case you find it helpful as a guide:

1 - Create a new VM instance in GCP: assign it a name (mongodb-01 in my case) and the properties using the UI as you stated.

Enabling VM Container deployment via UI

Specifying environment variables via UI

2 - Create the second VM instance in GCP: assign it a name (mongodb-02 in my case) and proceed similarly as with the previous example. Remember to use the private address assigned to mongodb-01 when providing the value for MONGODB_PRIMARY_HOST.

3 - Connect to mongodb-01 over SSH: you should be able to list the running containers and execute commands successfully:

$ docker exec -it klt-mongodb-01-xyz mongo -u root -p
$ rep:PRIMARY> rs.status()
{
        "set" : "rep",
        "date" : ISODate("2020-07-22T13:40:15.172Z"),
        ...
        "members" : [
                {
                        "_id" : 0,
                        "name" : "10.XXX.0.29:27017",
                        "health" : 1,
                        "state" : 1,
                        "stateStr" : "PRIMARY",
                        ...
                },
                {
                        "_id" : 1,
                        "name" : "10.XXX.0.34:27017",
                        "health" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY",
                        ...
                 }

NOTE: You can also use docker logs <container-name> to further investigate if there are any issues under the hood.