Can't communicate with replicaset using external access

igolka97 commented 1 month ago

Name and Version

bitnami/mongodb 15.6.26

What architecture are you using?

amd64

What steps will reproduce the bug?

deploy regular bitnami/mongodb helm chart
try to connect to replicaset externally using MongoDB Compass client without directConnection=true

Are you using any custom parameters or values?

architecture: replicaset
replicaCount: 2
externalAccess:
  enabled: true
  service:
    type: NodePort
    port: 27017
    nodePorts:
      - 30001
      - 30002
    publicNames:
      - sub.domain.com
      - sub.domain.com
    domain: "sub.domain.com"
    externalTrafficPolicy: Cluster

What is the expected behavior?

I can connect to cluster without any issues

What do you see instead?

getting error connect ENETUNREACH 192.168.0.7:30001

Additional information

Closed issue: #13485

I found out that replicaset initialised with names like 192.168.0.7:30001 (where 192.168.0.7 is my internal host ip and 30001 is nodePort). It possible to connect externally with directConnection=true setting FQDN or ip only once. In case of that, when you try to connect to cluster without directConnection your external client trying to connect to all replicas in set at once right after connection init and fails, as of 192.168.0.7 ip available only in cluster network. I guess that MONGODB_ADVERTISED_HOSTNAME and following lines is a culprit: https://github.com/bitnami/charts/blob/973a2792e0bc5967e3180c6d44eebf223b9f1d83/bitnami/mongodb/templates/replicaset/statefulset.yaml#L202-L205

values:

architecture: replicaset
replicaCount: 2
externalAccess:
  enabled: true
  service:
    type: NodePort
    port: 27017
    nodePorts:
      - 30001
      - 30002
    publicNames:
      - sub.domain.com
      - sub.domain.com
    domain: "sub.domain.com"
    externalTrafficPolicy: Cluster


members: [
    {
      _id: 0,
      name: '192.168.0.7:30001',
      health: 1,
      state: 1,
      stateStr: 'PRIMARY',
      uptime: 586,
      optime: [Object],
      optimeDate: 2024-09-28T22:21:37.000Z,
      lastAppliedWallTime: 2024-09-28T22:21:37.619Z,
      lastDurableWallTime: 2024-09-28T22:21:37.619Z,
      syncSourceHost: '',
      syncSourceId: -1,
      infoMessage: '',
      electionTime: Timestamp({ t: 1727561547, i: 1 }),
      electionDate: 2024-09-28T22:12:27.000Z,
      configVersion: 4,
      configTerm: 8,
      self: true,
      lastHeartbeatMessage: ''
    },
    {
      _id: 1,
      name: '192.168.0.6:30002',
      health: 1,
      state: 2,
      stateStr: 'SECONDARY',
      uptime: 562,
      optime: [Object],
      optimeDurable: [Object],
      optimeDate: 2024-09-28T22:21:37.000Z,
      optimeDurableDate: 2024-09-28T22:21:37.000Z,
      lastAppliedWallTime: 2024-09-28T22:21:37.619Z,
      lastDurableWallTime: 2024-09-28T22:21:37.619Z,
      lastHeartbeat: 2024-09-28T22:21:39.875Z,
      lastHeartbeatRecv: 2024-09-28T22:21:40.286Z,
      pingMs: Long('0'),
      lastHeartbeatMessage: '',
      syncSourceHost: '192.168.0.7:30001',
      syncSourceId: 0,
      infoMessage: '',
      configVersion: 4,
      configTerm: 8
    }
  ],```

carrodher commented 1 month ago

Thank you for bringing this issue to our attention. We appreciate your involvement! If you're interested in contributing a solution, we welcome you to create a pull request. The Bitnami team is excited to review your submission and offer feedback. You can find the contributing guidelines here.

Your contribution will greatly benefit the community. Feel free to reach out if you have any questions or need assistance.

github-actions[bot] commented 1 month ago

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

github-actions[bot] commented 4 weeks ago

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.

bitnami / charts