Grab a Snapshot of Your Container Image with Checkpoint
Have you ever been in a situation where you have a Docker or Podman container running exactly how you need and wished you had the ability to save a snapshot of it, so you can ensure you’ve got a running state saved in case something goes awry with the container? Should disaster strike, you can simply start a new container using the snapshot.
That’d be nice, wouldn’t it?
Well, it’s actually possible, thanks to the checkpoint feature. Consider this feature as a handy way to back up a running container state, so you can use it any time you need. When you start a container from a checkpoint, that container will be in the same state (including memory and processes) it was in when the checkpoint was created. Another really cool feature of checkpoint is that, when you start a new container from a saved state, it will deploy faster than it originally did.
Bonus!
Now, before we continue, know that this is an experimental feature, so use it with caution. I would suggest using it on a non-production machine until you A) get the hang of it and B) you trust it. Until then, consider it only for testing purposes.
With that said, let’s create some checkpoints.
What You’ll Need
To use docker checkpoints, you’ll need a running instance of docker on a Ubuntu Server platform and a user with sudo privileges. That’s it. Let’s get to work.
Installing the Necessary Dependency
The first thing to do is install the lone dependency, Criu, the core Linux checkpoint utility. Log in to your Ubuntu Server instance and add the necessary repository for the software with the command:
|
1 |
sudo add-apt-repository ppa:criu/ppa |
Update apt with:
|
1 |
sudo apt-get update |
You can now install Criu with the command:
|
1 |
sudo apt-get install criu -y |
Enabling Experimental Features
Now that you have Criu installed, you’ll need to enable experimental features for Docker. To do this, create a new file with the command:
|
1 |
sudo nano /etc/docker/daemon.json |
Add the following three lines to the file:
|
1 2 3 |
{ "experimental": true } |
Save and close the file.
Restart Docker with:
|
1 |
sudo systemctl restart docker |
Experimental features have now been enabled.
Deploy a Test Container
Instead of testing this on your currently running containers, let’s deploy a sample NGINX container to use. Deploy that container with the command:
|
1 |
docker run --name checkpoint-test -p 8005:80 -d nginx |
Give the container a moment to spin up. You should be able to access the running container with the command:
|
1 |
docker exec -it checkpoint-test /bin/bash |
Once inside the container, let’s modify the NGINX index.html page. Install the nano editor in the container with the following two commands:
|
1 2 |
apt update apt install nano -y |
Open index.html for editing with the command:
|
1 |
nano /usr/share/nginx/html/index.html |
Change the contents of that file to:
<!doctype html>
<html lang=”en”>
<head>
<meta charset=”utf-8″>
<title>Checkpoint Test</title>
</head>
<body>
<h2>Hello from The New Stack</h2>
</body>
</html>
Save and close the file. Exit from the container with the exit command and restart the container with:
|
1 |
docker restart checkpoint-test |
Create Your First Checkpoint
We’re going to create a checkpoint, while still leaving the NGINX container running, which is achieved with the following command:
|
1 |
docker checkpoint create --leave-running=true checkpoint-test checkpoint00 |
You can name the checkpoint anything you like. In this demonstration, I’ve opted for checkpoint00. After you run the command, you’ll see:
|
1 |
checkpoint00 |
The checkpoint was successfully created.
Now, I have run into instances where Docker CE and the checkpoint feature failed to work. On the other hand, I’ve always had success installing the version of Docker that is found in the standard repositories, which can be installed with the command:
|
1 |
sudo apt-get install docker.io -y |
Using a Checkpoint
Let’s say you do some work on the NGINX container and it fails on you. Since you’ve created a checkpoint, you can use it. Remember, our checkpoint is named checkpoint00. Let’s spin up a new container, which can be done with the command:
|
1 |
docker start --checkpoint checkpoint00 checkpoint-test |
You might be smarter than me and give your checkpoints meaningful names, such as something that indicates the current state or a date. So instead of checkpoint00, you might have checkpoint022323 (for February 23, 2023).
You can verify the checkpoints you’ve created for a particular container. For example, to list all of the checkpoints you’ve created from checkpoint-test, issue the command:
|
1 |
docker checkpoint ls checkpoint-test |
You might see something like this in the output:
|
1 2 3 4 5 |
CHECKPOINT NAME checkpoint01 checkpoint02 checkpoint03 checkpoint04 |
But What about Podman?
Podman has a checkpoint feature built into it, but there’s a problem with its usage. The only way to checkpoint a container is to do so with sudo privileges. The catch is that is you deploy a container as a standard user, you can’t checkpoint it with sudo, because podman won’t see the running container (as it was deployed by another user).
However, if you deploy the podman container with root, like so:
|
1 |
sudo podman run --name checkpoint-test -p 8006:80 -d nginx |
You can then checkpoint the container like so:
|
1 |
sudo podman container checkpoint checkpoint-test |
As you’ve probably expected, doing this defeats the purpose of rootless containers. However, there are rumblings that eventually podman will allow checkpointing with rootless containers. We’ll see what the future holds.
And that’s all there is to using the checkpoint command for both Docker and Podman. Give this a try and see if it doesn’t help you always have a running state for the containers you depend on.