Container Images

Architecture

The architecture of static and non-static containers differs significantly and requires several steps to migrate from one to the other. To learn more, see Migrate to Static Containers and Migrate to Non-Static Containers.

Non-Static Container Architecture

The default non-static container architecture assumes you bootstrap an empty-shell container, download and start the MongoDB Agent, which then downloads the binaries for mongod and mongosh from Cloud Manager or Ops Manager.

click to enlarge

Static Container Architecture

The static container architecture uses Kubernetes' shared namespace feature to run the MongoDB Agent as a separate process so it can control the full mongod lifecycle and avoid downloading files over a network.

Static containers are more secure and simpler than non-static containers. Static containers are immutable at runtime. In addition:

• While running, static containers can't download binaries or run scripts or other utilities over network connections. Static containers can only download runtime configuration files.

• While running, static containers can't modify any file except storage volume mounts.

• Static containers don't require that you scan the containers for security vulnerabilities, as opposed to non-static containers that require container security scanning. If you use static containers, you can only run security scans on the container images themselves but not on their containers.

• If you have an air-gapped environment, static containers don't require that you host the MongoDB binary on the server that hosts Ops Manager or another HTTPS server.

• You can't run extensive CMD scripts for the static container.

• You can't copy files between static containers using initContainer.

Note

When deployed as static containers, a Kubernetes Operator deployment consists of two containers - a mongodb-agent container and a mongodb-enterprise-server container. The MongoDB database custom resource inherits resource limit definitions from the mongodb-agent container, which runs the mongod process in a static container deployment. In order to modify the resource limits for the MongoDB database resource, you must specify your desired resource limits on the mongodb-agent container.

click to enlarge

Limitations

If you enable static containers:

• You must Disable Queryable Backups so the Backup Daemon Service doesn't attempt to download the MongoDB binaries from Ops Manager, which undermines the immutable nature of static containers.

• With Ops Manager, only versions 6.0.24, 7.0.5, or later are compatible. The Kubernetes Operator automatically uses the correct version of the MongoDB Agent container based on the Ops Manager version you select to manage a specific deployment.

• With MongoDB Cloud Manager, your MongoDB Agent version could fall behind compatibility with the latest version of MongoDB Cloud Manager because the Kubernetes Operator can't call the agentVersion endpoint in MongoDB Cloud Manager. To ensure your MongoDB Agent is up to date with MongoDB Cloud Manager, you can perform one of the following actions:

  • Specify a compatible MongoDB Agent version in the MongoDB resource specification by overriding the StatefulSet container image for the MongoDB Agent. For example:

    podSpec:
      podTemplate:
        spec:
          containers:
            - name: mongodb-agent-ubi
              Image: 12.0.29.7785-1_1.24.0

  • Upgrade the Kubernetes Operator to the latest version, which automatically updates the MongoDB Agent.

• Upgrading a MongoDB version triggers a rolling restart of all Pods, in order of last to first, and could cause more elections, up to the number of Pods. This is true of any updates that trigger a rolling restart.

• You won't be able to determine whether a MongoDB database upgrade happened from the MongoDB Agent's status. When Kubernetes rotates Pods following an upgrade, the MongoDB Agent replaces the health status file so you can't tell from the health status that a version change happened, only the current health status.

Migrate to Static Containers

To migrate from non-static to static containers, set the MongoDB Agent environment variables and enable static containers by following the steps below. You can also enable static containers during installation or upgrade.

kubectl apply -f mongodb-enterprise.yaml

oc apply -f mongodb-enterprise-openshift.yaml

helm upgrade enterprise-operator mongodb/enterprise-operator \
  --set registry.pullPolicy='IfNotPresent'

kubectl apply -f <my-config-file>.yaml

oc apply -f <my-config-file>.yaml

helm upgrade enterprise-operator mongodb/enterprise-operator \
 --set <setting_1> --set <setting_2> --set operator.mdbDefaultArchitecture="static"

Migrate to Non-Static Containers

To migrate from static to non-static containers, disable static containers by following the steps below. You can also disable static containers during installation or upgrade.

kubectl apply -f <my-config-file>.yaml

oc apply -f <my-config-file>.yaml

helm upgrade enterprise-operator mongodb/enterprise-operator \
 --set <setting_1> --set <setting_2> --set operator.mdbDefaultArchitecture="non-static"