一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第13天，点击查看活动详情。
兜兜转转，我们又回来继续看
podman api，前2天我们大概复习了一下shell，我们决定使用shell来封装一下podman api接口，我们这次封装三个接口info、_ping、/_images/json
为什么需要podman api
因为podman把轮子给造好了，方便运维/开发人员调用接口，总之把接口提供出来，避免我们造轮子，对此我们可以直接使用api调用podman即可。
我们为什么需要api呢？ 假设我们在做一个自动化部署，期间要启动一个容器，如果没有api，我们应该如何做呢？ 我们会直接去调用podman命令对吧，然后再根据输出，来判断成功与否，这样很笨重，且迁移起来麻烦(比如机器执行命令路径不一致)，所以需要api，那我们来看下具体用法
开启podman api服务
podman可以套接字监听unix和tcp
使用命令: podman system service开启podman api
参数
- --time: 会话超时时间，单位为秒，默认为5秒
- --log-level: 设置
Log等级，这个是podman的语法，而非api的 - --cors: 设置CORS Headers(主要是跨域使用)
开启unix套接字
命令: podman --log-level=debug system service -t0 unix:///tmp/podman.sock
该命令含义为，开启debug在中断显示，且unix套接字文件在 /tmp/podman.sock
开启TCP套接字
命令: podman --log-level=debug system service -t0 tcp:127.0.0.1:8888
和上述类似，注意，我们将unix给更换为了tcp
如上，我们启动了podman api unix套接字 和 tcp套接字
请求方法
假设我们使用curl请求获取版本信息
TCP方式请求版本信息
格式: /版本/libpod/info 其中版本信息只要是v开头
命令: curl -s http://127.0.0.1:8881/v3.0.0/libpod/info | jq '.version'
jq是linux格式化json工具
unix套接字方式请求版本信息
格式: d/版本/libpod/info 其中版本信息只要是v开头 ，只不过需要指定unix套接字文件
命令: curl -s --unix-socket /tmp/podman.sock http://d/v3.0.0/libpod/info | jq '.version'
podman 常规请求
请求方法
/info: 获取podman api信息/_ping: 检测podman api状态/_images/json: 获取podman images信息
检测podman状态
使用路由_ping可以检测podman状态，
例如
返回OK则代表podman正常的
获取podman api信息
使用理由/info可以获取podman api信息
例如
使用jq格式化为json
例如使用命令: curl -s http://127.0.0.1:8881/v3.0.0/info | jq
获取images信息
使用理由images/json可以获取podman images信息
例如
使用命令: curl -s http://127.0.0.1:8881/v3.0.0/images/json | jq
使用shell封装podman api
脚本运行之后效果
我们通过bash shell的方式，封装了podman api之后运行的效果
我们再来查看下podman images看看是否和上面对得上
脚本列表
我们将脚本按照模块给分开了，以方便解释脚本含义
main.sh脚本有有个函数为main是该程序的入口podmanEvn.sh该脚本的一些配置变量checkHealth.sh检查podman api是否存活showVersion.sh显示出podman版本信息images.sh镜像操作，目前仅编写了列出镜像
配置变量
我们来看podmanEvn.sh的内容
全部定义为只读变量，报错了podman的版本信息(这个不重要)，是使用tcp还是socket去连接podman api，以及podman api提供的路由信息
检查podman api是否存活
该函数如下，若请求结果为空，或者字符串不为"OK" ，则返回2(异常)，否则返回0(正常)
显示podman版本信息
这个直接使用curl请求即可
显示image信息
查询images信息，我们先计算podman api返回了多少条记录，然后再循环取各个部分的信息，包括名称，id,创建时间，和大小
主函数
因为要使用别的文件的函数，所以需要引入，我们一般执行shell的方式有这么几种:
sh xxx.sh./ xxx.sh. xxx.shsource xxx.sh
其实，如上执行方案，可以归纳为2种，1. sh xxx.sh 2. source xxx.sh
那么有什么区别呢？ 我们为什么要使用source，而非sh
因为，sh去执行的时候，是开启了一个子shell，当子子shell执行完毕后，数据不会引入到父shell中,而source就是在父shell中执行的，这就是为什么我们修改了环境变量，例如: ~/.bashrc的时候，会使用 .或者source去重新执行了
感悟
虽然shell编写脚本本身不难，其核心也就那么几行代码，但是我们为了脚本的健壮性，不那么容易崩，我们需要写大量的辅助语句，来判断这个语句是否执行成功等等。失败了之后如何操作等。我们后面再来补充其他api。