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

一种通过改进dockerapi适应podman调用方法、终端设备及存储介质
技术领域
1.本发明涉及容器技术领域，尤其涉及一种通过改进dockerapi适应podman调用方法、终端设备及存储介质。


背景技术：

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


技术实现要素：

3.为了解决上述问题，本发明提出了一种通过改进dockerapi适应podman调用方法、终端设备及存储介质。
4.具体方案如下：
5.一种通过改进dockerapi适应podman调用方法，包括：
6.根据接入的podman和docker容器类型的不同，修改dockerapi默认连接的unix socket路径；
7.当接入的容器类型为podman时，在调用dockerapi执行容器中的命令后，针对返回的执行结果中包含的消息数据，进行如下解析过程：
8.s101：解析第一个消息数据后，判断后面是否存在第二个消息数据，如果存在，则解析第二个消息数据后，进入s202；如果不存在，返回第一个消息数据解析后的结果；
9.s102：判断后面是否存在第三个消息数据，如果存在，则解析第三个消息数据后，返回上述三个消息数据解析后的结果；如果不存在，返回前两个消息数据解析后的结果；
10.当接入的容器类型为podman时，在调用dockerapi获取podman容器中的进程信息时，将dockerapi提供的top接口中的参数-axo与stat之间的空格字符去掉。
11.进一步的，当接入的容器类型为podman时，修改dockerapi默认连接的unix socket路径为unix:///run/podman/podman.sock。
12.进一步的，消息数据包括消息头和消息体。
13.进一步的，如果三种返回类型返回的消息数据均为空时，则返回标准输出对应的消息数据。
14.一种通过改进dockerapi适应podman调用终端设备，包括处理器、存储器以及存储
在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现本发明实施例上述的方法的步骤。
15.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现本发明实施例上述的方法的步骤。
16.本发明采用如上技术方案，通过对dockerapi进行一定的改造，使得改造后的dockerapi能同时使用docker及podman的容器环境；可以解决podman官方api占时实现不完全，造成部分接口无法的问题；也解决了需要同时维护docker和podman两套接口名称，调用方式不通的问题；减少了对docker及podman二次开发以及通过api远程管理、获取容器信息的工作量。
附图说明
17.图1所示为本发明实施例一的流程图。
具体实施方式
18.为进一步说明各实施例，本发明提供有附图。这些附图为本发明揭露内容的一部分，其主要用以说明实施例，并可配合说明书的相关描述来解释实施例的运作原理。配合参考这些内容，本领域普通技术人员应能理解其他可能的实施方式以及本发明的优点。
19.现结合附图和具体实施方式对本发明进一步说明。
20.实施例一：
21.本发明实施例提供了一种通过改进dockerapi适应podman调用方法，如图1所示，所述方法中通过以下三点改进后使得能够调用dockerapi操作podman容器。
22.(1)根据接入的podman和docker服务端的类型的不同，修改dockerapi默认连接的unix socket路径。
23.docker服务端默认启动的unix socket路径为unix:///var/run/docker.sock；podman服务端默认启动的unix socket路径为unix:///run/podman/podman.sock。为了兼容这两种容器，该实施例中在调用dockerapi初始化的时候根据不同的容器类型配置对应的unix socket路径，让dockerapi同时支持不同路径的unix socket。
24.(2)当接入的容器类型为podman时，在调用dockerapi执行容器中的命令后，针对返回的执行结果中包含的消息数据，采用与docke不同的解析方式进行解析。
25.docker服务端用dockerapi执行了容器中的命令后，采用vnd.docker.raw-stream协议返回消息数据，协议格式如下：
26.{stream_type,0,0,0,size1,size2,size3,size4}
27.该协议采用8位(bit)表示消息头，第一位(stream_type)用来表示返回类型，后面接着三位填0为保留字段，最后4位(size1,size2,size3,size4)用来表示该消息的长度。
28.返回类型stream_type的取值分别为：0表示标准输入(stdin)、1表示标准输出(stdout)、2表示标准错误(stderr)。
29.紧接着消息头后面的是具体的消息体{stdin body}，如果消息头中的size1、size2、size3、size4四个参数均为零时，后面无消息体。如果消息头中的size1、size2、size3、size4四个参数中有参数不为零时，由这4个参数组合表示一个32位的整数，通过该
32位的整数来表示后面消息体的长度。
30.如docker返回的消息数据为：
31.{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}
32.其中，消息体{stdin body}{stdout body}{stderr body}均可以为空。
33.docker针对消息数据的返回类型为stream_type＝0、stream_type＝1、stream_type＝2的三种情况下，不管消息数据是否为空，至少会返回一个消息头，即docker返回的执行结果中必然包含了三种返回类型的消息数据，而这三种消息数据中可以仅包含消息头，docker原有api会遍历三次消息数据以分别获取stdin、stdout和stderr的结果。
34.该实施例中podman服务端对docker服务端做了一定的优化，当stdin、stdout、stderr这三种返回类型如果某一类型的消息数据为空时，就不会返回相应的消息头与相应的消息体。即podman返回的执行结果可能返回一个消息数据，也可能返回两个消息数据，也可能返回三个消息数据。举例来说，如果对某个命令只有标准输出，则返回的消息数据为：{1,0,0,0,size1,size2,size3,size4}{stdout body}，这种情况下我们只需遍历一次，获取到对应的消息体即可。
35.需要说明的时，如果stdin、stdout、stderr这三种返回类型返回的消息数据均为空时，则返回标准输出对应的消息数据。
36.该实施例中针对返回的执行结果中包含的消息数据，进行如下解析过程：
37.s101：解析第一个消息数据后，判断后面是否存在第二个消息数据，如果存在，则解析第二个消息数据后，进入s202；如果不存在，返回第一个消息数据解析后的结果；
38.s102：判断后面是否存在第三个消息数据，如果存在，则解析第三个消息数据后，返回上述三个消息数据解析后的结果；如果不存在，返回前两个消息数据解析后的结果。
39.(3)当接入的容器类型为podman时，在调用dockerapi获取podman容器中的进程信息时，修改传入参数。
40.如果要获取docker容器内的详细进程信息可以调用dockerapi提供的top接口获取，调用示例为：top(ps_args＝'-axostat,ppid,pid,comm')，但是podman容器无法兼容这种调用方式，直接调用上面接口会显示ps_args为非法参数。通过分析发现调用top接口，容器内部采用内置的ps命令实现，podman容器内的ps命令参数不允许中间插入空格，通过把-axo stat之间的空格字符去掉写为-axostat可以正常适配podman环境。因此，该实施例中，当接入的容器类型为podman时，将dockerapi提供的top接口中的参数-axo与stat之间的空格字符去掉，即将
“‑
axo stat”修改为
“‑
axostat”。这样通过分情况去掉参数中的空格后，能同时满足docker和podman容器环境的调用。
41.本发明实施例通过对dockerapi进行一定的改造，使得改造后的dockerapi能同时使用docker及podman的容器环境；可以解决podman官方api占时实现不完全，造成部分接口无法的问题；也解决了需要同时维护docker和podman两套接口名称，调用方式不通的问题；减少了对docker及podman二次开发以及通过api远程管理、获取容器信息的工作量。
42.实施例二：
43.本发明还提供一种通过改进dockerapi适应podman调用终端设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所
述计算机程序时实现本发明实施例一的上述方法实施例中的步骤。
44.进一步地，作为一个可执行方案，所述通过改进dockerapi适应podman调用终端设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述通过改进dockerapi适应podman调用终端设备可包括，但不仅限于，处理器、存储器。本领域技术人员可以理解，上述通过改进dockerapi适应podman调用终端设备的组成结构仅仅是通过改进dockerapi适应podman调用终端设备的示例，并不构成对通过改进dockerapi适应podman调用终端设备的限定，可以包括比上述更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述通过改进dockerapi适应podman调用终端设备还可以包括输入输出设备、网络接入设备、总线等，本发明实施例对此不做限定。
45.进一步地，作为一个可执行方案，所称处理器可以是中央处理单元(central processing unit，cpu)，还可以是其他通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列(field-programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，所述处理器是所述通过改进dockerapi适应podman调用终端设备的控制中心，利用各种接口和线路连接整个通过改进dockerapi适应podman调用终端设备的各个部分。
46.所述存储器可用于存储所述计算机程序和/或模块，所述处理器通过运行或执行存储在所述存储器内的计算机程序和/或模块，以及调用存储在存储器内的数据，实现所述通过改进dockerapi适应podman调用终端设备的各种功能。所述存储器可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据手机的使用所创建的数据等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(smart media card,smc)，安全数字(secure digital,sd)卡，闪存卡(flash card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
47.本发明还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现本发明实施例上述方法的步骤。
48.所述通过改进dockerapi适应podman调用终端设备集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)以及软件分发介质等。
49.尽管结合优选实施方案具体展示和介绍了本发明，但所属领域的技术人员应该明白，在不脱离所附权利要求书所限定的本发明的精神和范围内，在形式上和细节上可以对本发明做出各种变化，均为本发明的保护范围。