什么是有状态服务和无状态服务
无状态服务
服务器仅根据当前连接来处理请求，服务器不会保存状态信息，所以请求不会依赖于先前请求的信息，但是可以通过外部获取信息，例如数据库。还有一个点是相同的请求可以由不同的服务进行处理。
有状态服务
有状态服务则与无状态服务相反，会根据每个请求的信息或者从早期请求的信息来处理该请求，必须使用同一个服务器来处理相同的请求。
例子
我们熟知的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的经验来看，应该是 没有生成 容器规范文件引起的
哎，溜了溜了
