MongoDB® is a cross-platform document-oriented database. Classified as a NoSQL database, MongoDB® eschews the traditional table-based relational database structure in favor of JSON-like documents with dynamic schemas, making the integration of data in certain types of applications easier and faster.

Disclaimer: The respective trademarks mentioned in the offering are owned by the respective companies. We do not provide a commercial license for any of these products. This listing has an open-source license. MongoDB® is run and maintained by MongoDB, which is a completely separate project from Bitnami.

$ helm repo add bitnami https://charts.bitnami.com/bitnami
$ helm install my-release bitnami/mongodb

This chart bootstraps a MongoDB® deployment on a Kubernetes cluster using the Helm package manager.

Bitnami charts can be used with Kubeapps for deployment and management of Helm Charts in clusters. This chart has been tested to work with NGINX Ingress, cert-manager, fluentd and Prometheus on top of the BKPR.

• Kubernetes 1.12
• Helm 3.1.0
• PV provisioner support in the underlying infrastructure

To install the chart with the release name my-release:

$ helm install my-release bitnami/mongodb

The command deploys MongoDB® on the Kubernetes cluster in the default configuration. The Parameters section lists the parameters that can be configured during installation.

Tip: List all releases using helm list

To uninstall/delete the my-release deployment:

$ helm delete my-release

The command removes all the Kubernetes components associated with the chart and deletes the release.

This charts allows you install MongoDB® using two different architecture setups: "standalone" or "replicaset". You can use the architecture parameter to choose the one to use:

architecture="standalone"
architecture="replicaset"

The standalone architecture installs a deployment (or statefulset) with one MongoDB® server (it cannot be scaled):

                ┌────────────────┐
                │   MongoDB® │
                |      svc       │
                └───────┬────────┘
                        │
                        ▼
                  ┌────────────┐
                  │MongoDB®│
                  │   Server   │
                  │    Pod     │
                  └────────────┘

The chart supports the replicaset architecture with and without a MongoDB® Arbiter:

• When the MongoDB® Arbiter is enabled, the chart installs two statefulsets: A statefulset with N MongoDB® servers (organised with one primary and N-1 secondary nodes), and a statefulset with one MongoDB® arbiter node (it cannot be scaled).

      ┌────────────────┐ ┌────────────────┐ ┌────────────────┐    ┌─────────────┐
      │ MongoDB® 0 │ │ MongoDB® 1 │ │ MongoDB® N │    │   Arbiter   │
      |  external svc  │ |  external svc  │ |  external svc  │    |     svc     │
      └───────┬────────┘ └───────┬────────┘ └───────┬────────┘    └──────┬──────┘
              │                  │                  │                    │
              ▼                  ▼                  ▼                    ▼
      ┌────────────────┐ ┌────────────────┐ ┌────────────────┐    ┌──────────────┐
      │ MongoDB® 0 │ │ MongoDB® 1 │ │ MongoDB® N │    │ MongoDB® │
      │    Server      │ │     Server     │ │     Server     │    │    Arbiter   │
      │     Pod        │ │      Pod       │ │      Pod       │    │     Pod      │
      └────────────────┘ └────────────────┘ └────────────────┘    └──────────────┘
           primary           secondary         secondary
  

  The PSA model is useful when the third Availability Zone cannot hold a full MongoDB® instance. The MongoDB® Arbiter as decision maker is lightweight and can run alongside other workloads.

  Note: An update takes your MongoDB® replicaset offline if the Arbiter is enabled and the number of MongoDB® replicas is two. Helm applies updates to the statefulsets for the MongoDB® instance and the Arbiter at the same time so you loose two out of three quorum votes.

• Without the Arbiter, the chart deploys a single statefulset with N MongoDB® servers (organised with one primary and N-1 secondary nodes)

      ┌────────────────┐ ┌────────────────┐ ┌────────────────┐
      │ MongoDB® 0 │ │ MongoDB® 1 │ │ MongoDB® N │
      |  external svc  │ |  external svc  │ |  external svc  │
      └───────┬────────┘ └───────┬────────┘ └───────┬────────┘
              │                  │                  │
              ▼                  ▼                  ▼
      ┌────────────────┐ ┌────────────────┐ ┌────────────────┐
      │ MongoDB® 0 │ │ MongoDB® 1 │ │ MongoDB® N │
      │    Server      │ │     Server     │ │     Server     │
      │     Pod        │ │      Pod       │ │      Pod       │
      └────────────────┘ └────────────────┘ └────────────────┘
           primary           secondary         secondary
  

There are no services load balancing requests between MongoDB® nodes, instead each node has an associated service to access them individually.

Note: although the 1st replica is initially assigned the "primary" role, any of the "secondary" nodes can become the "primary" if it is down, or during upgrades. Do not make any assumption about what replica has the "primary" role, instead configure your Mongo client with the list of MongoDB® hostnames so it can dynamically choose the node to send requests.

The following tables lists the configurable parameters of the MongoDB® chart and their default values per section/component:

Specify each parameter using the --set key=value[,key=value] argument to helm install. For example,

$ helm install my-release \
    --set auth.rootPassword=secretpassword,auth.username=my-user,auth.password=my-password,auth.database=my-database \
    bitnami/mongodb

The above command sets the MongoDB® root account password to secretpassword. Additionally, it creates a standard database user named my-user, with the password my-password, who has access to a database named my-database.

NOTE: Once this chart is deployed, it is not possible to change the application's access credentials, such as usernames or passwords, using Helm. To change these application credentials after deployment, delete any persistent volumes (PVs) used by the chart and re-deploy it, or use the application's built-in administrative tools if available.

Alternatively, a YAML file that specifies the values for the parameters can be provided while installing the chart. For example,

$ helm install my-release -f values.yaml bitnami/mongodb

Tip: You can use the default values.yaml

It is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.

Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.

The Bitnami MongoDB® image allows you to use your custom scripts to initialize a fresh instance. In order to execute the scripts, you can specify them using the initdbScripts parameter as dict.

You can also set an external ConfigMap with all the initialization scripts. This is done by setting the initdbScriptsConfigMap parameter. Note that this will override the previous option.

The allowed extensions are .sh, and .js.

In order to access MongoDB® nodes from outside the cluster when using a replicaset architecture, a specific service per MongoDB® pod will be created. There are two ways of configuring external access:

• Using LoadBalancer services
• Using NodePort services.

You have two alternatives to use LoadBalancer services:

• Option A) Use random load balancer IPs using an initContainer that waits for the IPs to be ready and discover them automatically.

architecture=replicaset
replicaCount=2
externalAccess.enabled=true
externalAccess.service.type=LoadBalancer
externalAccess.service.port=27017
externalAccess.autoDiscovery.enabled=true
serviceAccount.create=true
rbac.create=true

Note: This option requires creating RBAC rules on clusters where RBAC policies are enabled.

• Option B) Manually specify the load balancer IPs:

architecture=replicaset
replicaCount=2
externalAccess.enabled=true
externalAccess.service.type=LoadBalancer
externalAccess.service.port=27017
externalAccess.service.loadBalancerIPs[0]='external-ip-1'
externalAccess.service.loadBalancerIPs[1]='external-ip-2'}

Note: You need to know in advance the load balancer IPs so each MongoDB® node advertised hostname is configured with it.

Manually specify the node ports to use:

architecture=replicaset
replicaCount=2
externalAccess.enabled=true
externalAccess.service.type=NodePort
externalAccess.service.nodePorts[0]='node-port-1'
externalAccess.service.nodePorts[1]='node-port-2'

Note: You need to know in advance the node ports that will be exposed so each MongoDB® node advertised hostname is configured with it.

The pod will try to get the external ip of the node using curl -s https://ipinfo.io/ip unless externalAccess.service.domain is provided.

In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the extraEnvVars property.

extraEnvVars:
  - name: LOG_LEVEL
    value: error

Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the extraEnvVarsCM or the extraEnvVarsSecret properties.

If you have a need for additional containers to run within the same pod as MongoDB® (e.g. an additional metrics or logging exporter), you can do so via the sidecars config parameter. Simply define your container according to the Kubernetes container spec.

sidecars:
  - name: your-image-name
    image: your-image
    imagePullPolicy: Always
    ports:
      - name: portname
       containerPort: 1234

Similarly, you can add extra init containers using the initContainers parameter.

initContainers:
  - name: your-image-name
    image: your-image
    imagePullPolicy: Always
    ports:
      - name: portname
        containerPort: 1234

The Bitnami MongoDB® image stores the MongoDB® data and configurations at the /bitnami/mongodb path of the container.

The chart mounts a Persistent Volume at this location. The volume is created using dynamic volume provisioning.

As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions.

As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. You can enable this initContainer by setting volumePermissions.enabled to true.

You can use custom Prometheus rules for Prometheus operator by using the prometheusRule parameter, see below a basic configuration example:

metrics:
  enabled: true
  prometheusRule:
    enabled: true
    rules:
    - name: rule1
      rules:
      - alert: HighRequestLatency
        expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
        for: 10m
        labels:
          severity: page
        annotations:
          summary: High request latency

This container supports enabling SSL/TLS between nodes in the cluster, as well as between mongo clients and nodes, by setting the MONGODB_EXTRA_FLAGS and MONGODB_CLIENT_EXTRA_FLAGS environment variables, together with the correct MONGODB_ADVERTISED_HOSTNAME. To enable full TLS encryption set tls.enabled to true

The secrets-ca.yaml utilizes the helm "pre-install" hook to ensure that the certs will only be generated on chart install. The genCA function will create a new self-signed x509 certificate authority, the genSignedCert function creates an object with a pair of items in it — the Cert and Key which we base64 encode and use in a yaml like object. With the genSignedCert function, we pass the CN, an empty IP list (the nil part), the validity and the CA created previously. To hold the signed certificate created above, we can use a kubernetes Secret object and the initContainer sets up the rest. Using Helm’s hook annotations ensures that the certs will only be generated on chart install. This will prevent overriding the certs anytime we upgrade the chart’s released instance.

To use your own CA set tls.caCert and tls.caKey with appropriate base64 encoded data. The secrets-ca.yaml will utilize this data to create secret. Please Note:- Currently only RSA private keys are supported.

To access the cluster you will need to enable the initContainer which generates the MongoDB® server/client pem needed to access the cluster. Please ensure that you include the $my_hostname section with your actual hostname and alternative hostnames section should contain the hostnames you want to allow access to the MongoDB® replicaset. Additionally, if the external access is enabled, the loadBalancerIPs are added to the alternative names list. Note: You will be generating self signed certs for the MongoDB® deployment. With the initContainer it will generate a new MongoDB® private key which will be used to create your own Certificate Authority (CA),the public cert for the CA will be created, the Certificate Signing Request will be created as well and signed using the private key of the CA previously created. Finally the PEM bundle will be created using the private key and public certificate. The process will be repeated for each node in the cluster.

After the certs have been generated and made available to the containers at the correct mount points, the mongod server will be started with TLS enabled. The options for the TLS mode will be (disabled|allowTLS|preferTLS|requireTLS). This value can be changed via the MONGODB_EXTRA_FLAGS field using the tlsMode. The client should now be able to connect to the TLS enabled cluster with the provided certs.

This chart allows you to set your custom affinity using the XXX.affinity parameter(s). Find more information about Pod's affinity in the kubernetes documentation.

As an alternative, you can use of the preset configurations for pod affinity, pod anti-affinity, and node affinity available at the bitnami/common chart. To do so, set the XXX.podAffinityPreset, XXX.podAntiAffinityPreset, or XXX.nodeAffinityPreset parameters.

Find more information about how to deal with common errors related to Bitnami’s Helm charts in this troubleshooting guide.

If authentication is enabled, it's necessary to set the auth.rootPassword (also auth.replicaSetKey when using a replicaset architecture) when upgrading for readiness/liveness probes to work properly. When you install this chart for the first time, some notes will be displayed providing the credentials you must use under the 'Credentials' section. Please note down the password, and run the command below to upgrade your chart:

$ helm upgrade my-release bitnami/mongodb --set auth.rootPassword=[PASSWORD] (--set auth.replicaSetKey=[REPLICASETKEY])

Note: you need to substitute the placeholders [PASSWORD] and [REPLICASETKEY] with the values obtained in the installation notes.

On November 13, 2020, Helm v2 support was formally finished, this major version is the result of the required changes applied to the Helm Chart to be able to incorporate the different features added in Helm v3 and to be consistent with the Helm project itself regarding the Helm v2 EOL.

What changes were introduced in this major version?

• Previous versions of this Helm Chart use apiVersion: v1 (installable by both Helm 2 and 3), this Helm Chart was updated to apiVersion: v2 (installable by Helm 3 only). Here you can find more information about the apiVersion field.
• Move dependency information from the requirements.yaml to the Chart.yaml
• After running helm dependency update, a Chart.lock file is generated containing the same structure used in the previous requirements.lock
• The different fields present in the Chart.yaml file has been ordered alphabetically in a homogeneous way for all the Bitnami Helm Charts

Considerations when upgrading to this version

• If you want to upgrade to this version from a previous one installed with Helm v3, you shouldn't face any issues
• If you want to upgrade to this version using Helm v2, this scenario is not supported as this version doesn't support Helm v2 anymore
• If you installed the previous version with Helm v2 and wants to upgrade to this version with Helm v3, please refer to the official Helm documentation about migrating from Helm v2 to v3

Useful links

• https://docs.bitnami.com/tutorials/resolve-helm2-helm3-post-migration-issues/
• https://helm.sh/docs/topics/v2_v3_migration/
• https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/

MongoDB® container images were updated to 4.4.x and it can affect compatibility with older versions of MongoDB®. Refer to the following guides to upgrade your applications:

• Standalone
• Replica Set

• Architecture used to configure MongoDB® as a replicaset was completely refactored. Now, both primary and secondary nodes are part of the same statefulset.
• Chart labels were adapted to follow the Helm charts best practices.
• This version introduces bitnami/common, a library chart as a dependency. More documentation about this new utility could be found here. Please, make sure that you have updated the chart dependencies before executing any upgrade.
• Several parameters were renamed or disappeared in favor of new ones on this major version. These are the most important ones:
  • replicas is renamed to replicaCount.
  • Authentication parameters are reorganized under the auth.* parameter:
    • usePassword is renamed to auth.enabled.
    • mongodbRootPassword, mongodbUsername, mongodbPassword, mongodbDatabase, and replicaSet.key are now auth.rootPassword, auth.username, auth.password, auth.database, and auth.replicaSetKey respectively.
  • securityContext.* is deprecated in favor of podSecurityContext and containerSecurityContext.
  • Parameters prefixed with mongodb are renamed removing the prefix. E.g. mongodbEnableIPv6 is renamed to enableIPv6.
  • Parameters affecting Arbiter nodes are reorganized under the arbiter.* parameter.

Consequences:

• Backwards compatibility is not guaranteed. To upgrade to 8.0.0, install a new release of the MongoDB® chart, and migrate your data by creating a backup of the database, and restoring it on the new release.

From this version, the way of setting the ingress rules has changed. Instead of using ingress.paths and ingress.hosts as separate objects, you should now define the rules as objects inside the ingress.hosts value, for example:

ingress:
  hosts:
  - name: mongodb.local
    path: /

From this version, mongodbEnableIPv6 is set to false by default in order to work properly in most k8s clusters, if you want to use IPv6 support, you need to set this variable to true by adding --set mongodbEnableIPv6=true to your helm command. You can find more information in the bitnami/mongodb image README.

When enabling replicaset configuration, backwards compatibility is not guaranteed unless you modify the labels used on the chart's statefulsets. Use the workaround below to upgrade from versions previous to 5.0.0. The following example assumes that the release name is my-release:

$ kubectl delete statefulset my-release-mongodb-arbiter my-release-mongodb-primary my-release-mongodb-secondary --cascade=false