如何将libpod用于自定义/衍生项目

libpod 如今是一个 Golang 库和一个命令行界面。你选择的接口各有优劣。

使用 REST API

优势:

• 稳定的、有版本控制的API

• 与语言无关

• API 文档完善

缺点:

• 错误处理不如 Golang API 详细

• 可能会更慢

作为子进程运行

优势:

• 许多命令输出 JSON 格式数据

• 适用于 Golang 以外的语言

• 易于上手

缺点:

• 错误处理更困难

• 可能会更慢

• 无法接入或控制底层事务，比如镜像的拉取方式

引入到 Go 项目中

优势:

• 强大的力量与控制力

缺点:

• 您现在需要负责容器运行时安全更新（部分负责，runc/crun 是独立的）

• 二进制文件大小

• 多个 libpod 版本在同一存储上运行时可能存在的偏移差异会引发问题

做出选择

首先需要明确的是：是否希望用户能使用 podman 操作项目创建的容器？

若需如此，则更倾向于将 podman 作为子进程运行或通过 HTTP API 调用。

若追求独立镜像仓库和截然不同的操作体验；若容器使用场景与 podman 命令行创建的容器存在显著差异，则可能需要考虑采用 vendoring（引入） 方案。