MongoDB(R) is a relational open source NoSQL database. Easy to use, it stores data in JSON-like documents. Automated scalability and high-performance. Ideal for developing cloud native applications.

Overview of MongoDB®

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(R) 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.

• Kubernetes 1.19+
• Helm 3.2.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 chart allows installing MongoDB(®) using two different architecture setups: standalone or replicaset. Use the architecture parameter to choose the one to use:

architecture="standalone"
architecture="replicaset"

Refer to the chart documentation for more information on each of these architectures.

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 supports the use of custom scripts to initialize a fresh instance. In order to execute the scripts, two options are available:

• Specify them using the initdbScripts parameter as dict.
• Define an external Kubernetes ConfigMap with all the initialization scripts by setting the initdbScriptsConfigMap parameter. Note that this will override the previous option.

The allowed script 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.

Refer to the chart documentation for more details and configuration examples.

To add extra environment variables (useful for advanced operations like custom init scripts), 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 additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the sidecars config parameter. Similarly, extra init containers can be added using the initContainers parameter.

Refer to the chart documentation for more information on, and examples of, configuring and using sidecars and init containers.

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.

If you encounter errors when working with persistent volumes, refer to our troubleshooting guide for persistent volumes.

Custom Prometheus rules can be defined for the Prometheus Operator by using the prometheusRule parameter.

Refer to the chart documentation for an example of a custom rule.

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

Refer to the chart documentation for more information on enabling TLS.

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

As an alternative, you can use 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.

This major release renames several values in this chart and adds missing features, in order to be inline with the rest of assets in the Bitnami charts repository.

Affected values:

• strategyType is replaced by updateStrategy
• service.port is renamed to service.ports.mongodb
• service.nodePort is renamed to service.nodePorts.mongodb
• externalAccess.service.port is renamed to externalAccess.hidden.service.ports.mongodb
• rbac.role.rules is renamed to rbac.rules
• externalAccess.hidden.service.port is renamed ot externalAccess.hidden.service.ports.mongodb
• hidden.strategyType is replaced by hidden.updateStrategy
• metrics.serviceMonitor.relabellings is renamed to metrics.serviceMonitor.relabelings(typo fixed)
• metrics.serviceMonitor.additionalLabels is renamed to metrics.serviceMonitor.labels

Additionally also updates the MongoDB image dependency to it newest major, 5.0

In this version, the mongodb-exporter bundled as part of this Helm chart was updated to a new version which, even it is not a major change, can contain breaking changes (from 0.11.X to 0.30.X). Please visit the release notes from the upstream project at https://github.com/percona/mongodb_exporter/releases

On November 13, 2020, Helm v2 support formally ended. 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.

Learn more about this change and related upgrade considerations.

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

To add extra deployments (useful for advanced features like sidecars), use the extraDeploy property.

In the example below, you can find how to use a example here for a MongoDB replica set pod labeler sidecar to identify the primary pod and dynamically label it as the primary node:

extraDeploy:
  - apiVersion: v1
    kind: Service
    metadata:
      name: mongodb-primary
      namespace: default
      labels:
        app.kubernetes.io/component: mongodb
        app.kubernetes.io/instance: mongodb
        app.kubernetes.io/managed-by: Helm
        app.kubernetes.io/name: mongodb
    spec:
      type: NodePort
      externalTrafficPolicy: Cluster
      ports:
        - name: mongodb-primary
          port: 30001
          nodePort: 30001
          protocol: TCP
          targetPort: mongodb
      selector:
        app.kubernetes.io/component: mongodb
        app.kubernetes.io/instance: mongodb
        app.kubernetes.io/name: mongodb
        primary: "true"

Copyright © 2022 Bitnami

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.