Container Images
On this page
When you install the Kubernetes Operator, it pulls the images from the Quay.io container registry. The Kubernetes Operator images are based on the Red Hat UBI 8 operating system. MongoDB rebuilds Kubernetes Operator images daily for the latest operating system and supporting library updates.
Official images provide the following advantages:
They are rebuilt daily for the latest upstream vulnerability fixes.
MongoDB tests, maintains, and supports them.
To view all available versions for each image, see the following links.
Image Name | Description |
|---|---|
MongoDB Agent image. | |
The Enterprise MongoDB image used for static containers and the Application Database. | |
| |
MongoDB Database environment image used for non-static containers. To learn about static and non-static containers, see Static Containers (Public Preview). | |
| |
Ops Manager image. | |
|
Static Containers (Public Preview)
Static containers are simpler and more secure than non-static containers. Static containers are immutable at runtime, which means that they don't change from the image used to create the container. In addition:
While running, static containers don't download binaries or run scripts or other utilities over network connections. Static containers only download runtime configuration files.
While running, static containers don't modify any file except storage volume mounts.
You can run security scans on the container images to determine what is actually run as a live container, and the container that runs won't run binaries other than what was defined in the image.
Static containers don't require that you host the MongoDB binary on either Ops Manager or another HTTPS server, which is especially useful if you have an air-gapped environment.
You can't run extensive
CMDscripts 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.
Starting with MongoDB Enterprise Kubernetes Operator 1.25, you can use the Public Preview of static containers instead of the existing non-static containers, which downloads the MongoDB binary from Cloud Manager or Ops Manager or the Internet at runtime. You can use the procedures on this page to enable or disable static containers for all or individual MongoDB deployments.
Static containers use the image from the mongodb-enterprise-server Quay.io repository by default, but you can use your own registry if you configured it for your Kubernetes nodes.
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.
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.
Compatibility With Local or Remote Mode
If you use static containers, you don't need to configure Ops Manager to
run in Local Mode or
Remote Mode, unless you use
queryable backups. In static container architecture, the binaries
for the agent and mongod have their own container images and these
are not downloaded from Ops Manager.
Queryable backups are the exception because in the non-static container architecture, by default, the Backup Daemon downloads and runs the MongoDB Server binaries for all versions that are backed-up. This default MongoDB behavior undermines the fully static nature of the containers used to run the Backup Daemon. If you use queryable backups, you must still host the relevant MongoDB Server binaries using local or remote mode. To learn more, see Configure an Ops Manager Resource to use Local Mode or Configure an Ops Manager Resource to use Remote Mode.
If you used Remote or Local mode before and don't want to use queryable
backups, do the following to ensure that mongodb-enterprise-server
images
can be downloaded on the nodes used by the pods:
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
agentVersionendpoint 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.
FAQs
Do static containers support local or remote mode?
No, if you use static containers, you don't need to configure Ops Manager to run in Local Mode or Remote Mode unless you use queryable backups. To learn more, see Local and Remote Modes.
What are the changes for static containers?
Static containers don't download the MongoDB binary at runtime. Instead, it uses the images from the mongodb-enterprise-server Quay.io repository. To learn more about the changes, see step 6.
How can I verify if my deployment is running in static?
There are many ways to determine if your deployment is using static container. To learn more, see step 7.
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.
Review the limitations.
Disable queryable backups.
Follow the procedure in Disable Queryable Backups.
If you want to use queryable backups, you must configure Ops Manager resource to use Local Mode or Remote Mode so that the binaries for all versions in-use can be pulled from Ops Manager.
Remove StatefulSet overrides for init containers, if any.
There are no init containers used with the static container architecture. If an override for an init container is present, the migration from non-static to static containers fails.
Remove any StatefulSet overrides for init containers from your
MongoDB resource specification or
Ops Manager resource specification.
For example, ensure none of the following settings have been configured for initContainers:
Ops Manager:
spec.statefulSet.specApplication Database:
spec.applicationDatabase.podSpecDatabase: StatefulSet Settings
Multi-cluster: spec.statefulSet.spec
Set environment variables for the MongoDB Agent image.
In your Kubernetes Operator configuration file, define the MDB_AGENT_IMAGE_REPOSITORY environment variable to specify the repository from which the Kubernetes Operator downloads the MongoDB Agent image for static containers.
In your Kubernetes Operator Helm chart, define registry.agent and agent.name to specify the repository from which the Kubernetes Operator downloads the MongoDB Agent image for static containers.
Save and apply the file.
After saving the changes, reapply your configuration.
If you use Kubernetes without OpenShift, run:
kubectl apply -f mongodb-enterprise.yaml
If you use Kubernetes with OpenShift:
oc apply -f mongodb-enterprise-openshift.yaml
helm upgrade enterprise-operator mongodb/enterprise-operator \ --set registry.pullPolicy='IfNotPresent'
This initiates a rolling restart of all Pods in your deployment.
Enable static containers.
Select the appropriate tab below to enable static containers for all your MongoDB deployments at once, including existing deployments, or one deployment at a time.
In your Kubernetes Operator configuration file,
set MDB_DEFAULT_ARCHITECTURE
or operator.mdbDefaultArchitecture to static.
In the MongoDB resource specification for
a specific deployment,
set the metadata.annotations.mongodb.com/v1.architecture
annotation to static.
Save and apply the file.
After saving the changes, reapply your configuration.
If you use Kubernetes without OpenShift, run:
kubectl apply -f <my-config-file>.yaml
If you use Kubernetes with OpenShift:
oc apply -f <my-config-file>.yaml
helm upgrade enterprise-operator mongodb/enterprise-operator \ --set <setting_1> --set <setting_2> --set operator.mdbDefaultArchitecture="static"
The Kubernetes Operator updates the StatefulSet images for your MongoDB deployment, transitioning from a single container that previously managed both the MongoDB Agent and MongoDB database, to a new configuration with two separate containers: one for the MongoDB Agent and another for the MongoDB database. This update initiates a rolling restart.
When you migrate to static containers, the following changes apply:
Kubernetes nodes use their configured container registry to perform the downloads.
Monitoring agent and automation agent versions are aligned.
Kubernetes Operator, instead of the agent, handles MongoDB upgrades.
Kubernetes Operator replaces the existing images, which will cause a rolling restart.
Verify that deployment is running in static.
Check the value for one of the following variables, which you must've set to
static:MDB_DEFAULT_ARCHITECTUREVariable for all deployments.
metadata.annotations[mongodb.com/v1.architecture]Per-deployment variable.
Check the database deployment to verify the usage of two separate images, one for the agent and one for MongoDB, and ensure that no init containers are deployed.
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.
Disable static containers.
Select the appropriate tab below to disable static containers for all your MongoDB deployments at once, including existing deployments, or one deployment at a time.
In the MongoDB resource specification for
a specific deployment,
set the metadata.annotations.mongodb.com/v1.architecture
annotation to non-static.
Save and apply the file.
After saving the changes, reapply your configuration.
If you use Kubernetes without OpenShift, run:
kubectl apply -f <my-config-file>.yaml
If you use Kubernetes with OpenShift:
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"
The Kubernetes Operator replaces the StatefulSet images of your MongoDB deployment and initiates a rolling restart of all Pods in your deployment.