I have a Docker image, that launches a server application upon startup. The problem, that I am facing is the servers startup time, which takes several minutes.
So, my question: Would it be possible, to
1.) Launch the server application as part of the image building process.
2.) As the last step in the image building process: Persist the server application to a file.
3.) When the image is being launched, don’t start the server application. Instead, restore the persisted
process from the same file.
Sounds like science fiction? Well, so did Docker, 30 years back in the past.
An image encapsulates the core application and all its dependencies, config files and idealy a clever entrypoint script that applies configuration individualization when the container is started. The files inside the image are at rest - there is no way to snapshot in-memory state or “keep an aplication running”.
If a container - based on an image - is started, the entrypoint script (or in absence of it the command) is executed and whetever action is declared will be executed. A container is merly an isolated process with some additional storage and network “magic”.
Thus said, you would need a workflow that snapshots the in-memory state of the application. This is not possible with docker itself. You would need something additionaly that takes care of this, probably something like a vm solution that allows to suspend the vm.
I strongly advise you to script this workflow outside docker to see wether it’s feasable, and if so, package it in an image.
Though, the whole idea does not realy sound like a good fit for a container.
I was not aware of docker checkpoint. I learned something new today
Though it is a checkpoint for containers, not for images. But it still seem to solve the problem hat you can at least freeze a container with cpu and in-memory state, pretty much like when a vm is suspended.
The command indeed does exist ootb and even with Docker 20.10.16 still requires experimental features to be enabled.
