3 / 3
Mar 11

Hi everyone,

I’m trying to achieve the following workflow:

  1. Download a snapshot from our Atlas cluster.
  2. Restore it into a running container using mongodb-atlas-local.
  3. Run a cleanup script to remove sensitive data.
  4. Commit the running container’s state to a new image.
  5. Upload the image to ECR so developers can easily start a container with Atlas Search and “safe” production data preloaded.

I’ve managed everything except step 4—I’m struggling to commit the data properly and start a new container from the image.

Currently, I can commit an image with a /dump directory where developers could manually run mongorestore, but I’d prefer a cleaner solution where the image already contains the preloaded data.

I understand that MongoDB’s default behavior involves storing data in an automatic volume, which isn’t committed to the image. I’ve also tried copying the data to another directory (e.g., /data/localdb) before committing, but I run into issues when starting a new container from the image.

Has anyone successfully achieved something similar? Any ideas on how to properly commit the database state into the image?

Thanks!

Hi Mikael, the current supported mechanism for doing this is by passing --initdb with the location of the data stored as scripts. Of course this means anyone consuming your image from your private registry will also need to have access to those scripts and be aware of how to start the container from the Atlas CLI with the --initdb flag.

There a great explanation of how to do this in this blog post, and the Atlas CLI Learning Byte.

We are exploring a couple of ideas about how to improve the workflow for this use case. Would you be interested in talking more about these ideas separately?

Hi Jonny,
Thanks for the response.
Yes, I am interested in talking more about this and might have som valueable insights as well what have worked for us.
I am in Swedish time zone (UTC +1 now), but could often take meetings in the evening as well
BR
Mikael