I am aware that the general wisdom when using docker is to move data out of the container and use volumes instead.
But I am trying to create a system that provides a one-click, completely containerized installation method, and saying "you should install mongodb first on your computer" is not an option.
So the current solution is to keep the data itself in the container (MongoDB for example), but I am now looking for ways to back up a snapshot of the container itself every now and then, so that I can instantly spawn up an identical container from scratch when one goes down.
How can I achieve this?
You can use docker commit to take snapshots from a container.
See this post for further information.
You can use docker commit.
With docker commit you create a new image from a container’s changes.
From the docs, you can this it covers your use case:
It can be useful to commit a container’s file changes or settings into a new image. This allows you to debug a container by running an interactive shell, or to export a working dataset to another server. Generally, it is better to use Dockerfiles to manage your images in a documented and maintainable way. Read more about valid image names and tags.
The commit operation will not include any data contained in volumes mounted inside the container.
You could export and import the docker container easily.
An export whole container in the tar file
docker export docker_container_name > latest.tarImport Docker container and run it
cat exampleimage.tar | docker import - exampleimagelocal:newHelpful link - Docker export Docker Import
If you want to export Docker image, then
docker save -o image.tar Docker_Image_NameImport Docker Image
docker load -i image.tarand then run docker images.
I think you could achieve by doing the above mostly you need to use the first approach, export docker container and deploy whenever you need it, it will contain your old data.
If you do not want to use volumes, you can save your container at a specific time by using docker commit --change "added some changes to my container" <container_id> repo/image:tag
The new image will contains all filesystem of your current container.
That being said, not using volume has several disadvantages:
By default all files created inside a container are stored on a writable container layer. This means that:
The data doesn’t persist when that container is no longer running, and it can be difficult to get the data out of the container if another process needs it. A container’s writable layer is tightly coupled to the host machine where the container is running. You can’t easily move the data somewhere else. Writing into a container’s writable layer requires a storage driver to manage the filesystem. The storage driver provides a union filesystem, using the Linux kernel. This extra abstraction reduces performance as compared to using data volumes, which write directly to the host filesystem.
So your best choice is to use volume ! Now you can choose between different kinds:
While bind mounts are dependent on the directory structure of the host machine, volumes are completely managed by Docker. Volumes have several advantages over bind mounts:
Volumes are easier to back up or migrate than bind mounts. You can manage volumes using Docker CLI commands or the Docker API. Volumes work on both Linux and Windows containers. Volumes can be more safely shared among multiple containers. Volume drivers let you store volumes on remote hosts or cloud providers, to encrypt the contents of volumes, or to add other functionality. New volumes can have their content pre-populated by a container.
Read the documentation to understand volume's features better : https://docs.docker.com/storage/volumes/