podman利用criu进行容器迁移

一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第6天，点击查看活动详情。

什么是有状态服务和无状态服务

无状态服务

服务器仅根据当前连接来处理请求，服务器不会保存状态信息，所以请求不会依赖于先前请求的信息，但是可以通过外部获取信息，例如数据库。还有一个点是相同的请求可以由不同的服务进行处理。

有状态服务

有状态服务则与无状态服务相反，会根据每个请求的信息或者从早期请求的信息来处理该请求，必须使用同一个服务器来处理相同的请求。

例子

我们熟知的web网页，绝大部分是使用的无状态服务，而我们常说的游戏服务器，是使用的有状态服务。

podman 准备工作

准备工作

我们假设有一个博客系统，有一个路由reader专门叠加阅读量，我们将其抽象出来用go写出来大概是这样的

我们编译后尝试下访问路由信息

制作镜像

我们编写DockerFile，并且使用 docker build构建镜像，正如前文所述，因为docker和podman都遵循OCI规范，所以镜像理论上是通用的。

我们将上述信息拷贝到服务器上，并且编写DockerFile，如下

我们将DockerFile拷贝到服务器上，用docker build进行构建

构建完毕后，将其push到docker hub 上即可

使用podman启动容器

我们使用podman启动容器，并且访问几次接口

下载刚刚上传的pdudojuejin镜像

启动容器

podman 迁移有状态服务

访问有状态服务

我们尝试访问有状态服务，制造一些“证据”以证明我们迁移是成功了的

使用checkpoint为容器制造“快照”

使用命令: podman container checkpoint可以建立快照

我们发现建立快照后，容器停止了

现在尝试访问

使用checkpoint恢复快照

使用命令: podman container restore -k可以恢复快照运行

我们发现，有状态服务还在持续运行中，赞

垮机器迁移有状态服务容器

除了在本地进行制作“快照” 和 恢复 以外，还可以直接导出到 tar文件中，而后在别的机器进行恢复即可

启动容器并且访问有状态服务

可以看见，目前访问为2

将容器制作“快照”并且导出到文件

命令: podman container checkpoint juejin_pdudo_test -e juejin_pdudo_test.tar

-e: 导出到本地文件路径

导出现在的容器

将容器和“快照”发送需要恢复的podman机器上

在其他podman恢复容器

可以看到，已经恢复，且状态还在

探寻checkpoint底层逻辑

其实podman checkpoint 使用的底层技术为 criu，这玩意是干啥的呢？ 它是一个linux``namespace 实现checkpoint/restore的项目，这就是我们此前俗称的快照，可以将在在运行的程序，以文件的形式存储在磁盘上，后期又可以恢复的进程中，哎，就这样吧，不想写了，今天累了，我们可以把这个放在后面，后面可以单独列一篇文章来玩玩 criu(挖个坑，后面填一下，嘿嘿)。

心得体会

podman我们今天看了criu相关功能，结合我们之前玩的runc是不是觉得podman越来越像一个盒子，把各种东西都装在里面，对内封装，对外提供接口供我们调用，不管是criu也好，runc也好，我们会逐渐意识到，容器技术，不仅仅是个别项目的成果，越来越趋向于整个生态链，最初容器技术，都是野蛮生长，后来几个大佬商量商量，于是有了相关规范协议，有了协议，其他厂商照着抄就是了，反正根据协议，都会兼容。

docker 打包在podman无法运行探查

其实最开始的时候，想直接利用docker将镜像拖出来，然后放到podman运行，但是实际上操作了之后，报错了，报错信息

经过排查，排查过程就不叙述了，我们将docker容器导入到podman后，使用inspect查看镜像的信息是这样的, config为空

我们将docker上传到docker hub(已经将docker hub信息给隐藏了，不算引流吧)上，再利用podman pull 下来，使用inspect大概是这样的

结合上次我们使用runc的经验来看，应该是 没有生成 容器规范文件引起的

哎，溜了溜了