一种通过改进DockerApi适应Podman调用方法、终端设备及存储介质技术

本发明专利技术涉及一种通过改进DockerApi适应Podman调用方法、终端设备及存储介质，该方法中包括：根据接入的podman和docker容器类型的不同，修改dockerapi默认连接的unix socket路径；当接入的容器类型为podman时，在调用dockerapi执行容器中的命令后，针对返回的执行结果中包含的消息数据，采用与docke不同的解析方式进行解析；当接入的容器类型为podman时，在调用dockerapi获取podman容器中的进程信息时，将dockerapi提供的top接口中的参数

【技术实现步骤摘要】
一种通过改进DockerApi适应Podman调用方法、终端设备及存储介质


[0001]本专利技术涉及容器
，尤其涉及一种通过改进DockerApi适应Podman调用方法、终端设备及存储介质。

技术介绍

[0002]Podman作为一种开源的容器运行时项目，可以在大多数Linux平台上使用，Podman提供了与Docker非常相似的功能。早期版本的PodmanApi为采用VarLink协议设计的，新版本采用与Docker相似的实现方式实现Api(都采用Http rest API方式)，但是由于Podman起步比较晚，官方提供的API只提供了比较基础的调用接口，还有大部分调用接口只提供了一个函数接口，然后直接抛出接口暂未实现的异常，导致如果直接调用现有的官方Api，大部分接口还不能实现。如果podman后期实现了所有api接口，也会因为用户原来使用的dockerapi操作docker容器，如果新增加podman的操作将会引入podman的库，而且两套库函数接口命名大不相同，调用方式区别也很大，改造起来工作量比较大。

技术实现思路

[0003]为了解决上述问题，本专利技术提出了一种通过改进DockerApi适应Podman调用方法、终端设备及存储介质。
[0004]具体方案如下：
[0005]一种通过改进DockerApi适应Podman调用方法，包括：
[0006]根据接入的podman和docker容器类型的不同，修改dockerapi默认连接的unix socket路径；
[0007]当接入的容器类型为podman时，在调用dockerapi执行容器中的命令后，针对返回的执行结果中包含的消息数据，进行如下解析过程：
[0008]S101：解析第一个消息数据后，判断后面是否存在第二个消息数据，如果存在，则解析第二个消息数据后，进入S202；如果不存在，返回第一个消息数据解析后的结果；
[0009]S102：判断后面是否存在第三个消息数据，如果存在，则解析第三个消息数据后，返回上述三个消息数据解析后的结果；如果不存在，返回前两个消息数据解析后的结果；
[0010]当接入的容器类型为podman时，在调用dockerapi获取podman容器中的进程信息时，将dockerapi提供的top接口中的参数
‑
axo与stat之间的空格字符去掉。
[0011]进一步的，当接入的容器类型为podman时，修改dockerapi默认连接的unix socket路径为unix:///run/podman/podman.sock。
[0012]进一步的，消息数据包括消息头和消息体。
[0013]进一步的，如果三种返回类型返回的消息数据均为空时，则返回标准输出对应的消息数据。
[0014]一种通过改进DockerApi适应Podman调用终端设备，包括处理器、存储器以及存储
在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现本专利技术实施例上述的方法的步骤。
[0015]一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现本专利技术实施例上述的方法的步骤。
[0016]本专利技术采用如上技术方案，通过对dockerapi进行一定的改造，使得改造后的dockerapi能同时使用docker及podman的容器环境；可以解决podman官方api占时实现不完全，造成部分接口无法的问题；也解决了需要同时维护docker和podman两套接口名称，调用方式不通的问题；减少了对docker及podman二次开发以及通过api远程管理、获取容器信息的工作量。
附图说明
[0017]图1所示为本专利技术实施例一的流程图。
具体实施方式
[0018]为进一步说明各实施例，本专利技术提供有附图。这些附图为本专利技术揭露内容的一部分，其主要用以说明实施例，并可配合说明书的相关描述来解释实施例的运作原理。配合参考这些内容，本领域普通技术人员应能理解其他可能的实施方式以及本专利技术的优点。
[0019]现结合附图和具体实施方式对本专利技术进一步说明。
[0020]实施例一：
[0021]本专利技术实施例提供了一种通过改进DockerApi适应Podman调用方法，如图1所示，所述方法中通过以下三点改进后使得能够调用dockerapi操作podman容器。
[0022](1)根据接入的podman和docker服务端的类型的不同，修改dockerapi默认连接的unix socket路径。
[0023]docker服务端默认启动的unix socket路径为unix:///var/run/docker.sock；podman服务端默认启动的unix socket路径为unix:///run/podman/podman.sock。为了兼容这两种容器，该实施例中在调用dockerapi初始化的时候根据不同的容器类型配置对应的unix socket路径，让dockerapi同时支持不同路径的unix socket。
[0024](2)当接入的容器类型为podman时，在调用dockerapi执行容器中的命令后，针对返回的执行结果中包含的消息数据，采用与docke不同的解析方式进行解析。
[0025]docker服务端用dockerapi执行了容器中的命令后，采用vnd.docker.raw
‑
stream协议返回消息数据，协议格式如下：
[0026]{STREAM_TYPE,0,0,0,SIZE1,SIZE2,SIZE3,SIZE4}
[0027]该协议采用8位(bit)表示消息头，第一位(STREAM_TYPE)用来表示返回类型，后面接着三位填0为保留字段，最后4位(SIZE1,SIZE2,SIZE3,SIZE4)用来表示该消息的长度。
[0028]返回类型STREAM_TYPE的取值分别为：0表示标准输入(stdin)、1表示标准输出(stdout)、2表示标准错误(stderr)。
[0029]紧接着消息头后面的是具体的消息体{stdin body}，如果消息头中的SIZE1、SIZE2、SIZE3、SIZE4四个参数均为零时，后面无消息体。如果消息头中的SIZE1、SIZE2、SIZE3、SIZE4四个参数中有参数不为零时，由这4个参数组合表示一个32位的整数，通过该
32位的整数来表示后面消息体的长度。
[0030]如docker返回的消息数据为：
[0031]{0,0,0,0,SIZE1,SIZE2,SIZE3,SIZE4}{stdin body}{1,0,0,0,SIZE1,SIZE2,SIZE3,SIZE4}{stdout body}{2,0,0,0,SIZE1,SIZE2,SIZE3,SIZE4}{stderr body}
[00本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种通过改进DockerApi适应Podman调用方法，其特征在于，包括：根据接入的podman和docker容器类型的不同，修改dockerapi默认连接的unixsocket路径；当接入的容器类型为podman时，在调用dockerapi执行容器中的命令后，针对返回的执行结果中包含的消息数据，进行如下解析过程：S101：解析第一个消息数据后，判断后面是否存在第二个消息数据，如果存在，则解析第二个消息数据后，进入S202；如果不存在，返回第一个消息数据解析后的结果；S102：判断后面是否存在第三个消息数据，如果存在，则解析第三个消息数据后，返回上述三个消息数据解析后的结果；如果不存在，返回前两个消息数据解析后的结果；当接入的容器类型为podman时，在调用dockerapi获取podman容器中的进程信息时，将dockerapi提供的top接口中的参数
‑
axo与stat之间的空格字符去掉。2.根据权利要求1所述的通过改进D...

【专利技术属性】
技术研发人员：严铭，陈奋，陈荣有，龚利军，孙晓波，
申请(专利权)人：厦门服云信息科技有限公司，
类型：发明
国别省市：