mirror of https://github.com/containers/podman.git synced 2025-05-20 08:36:23 +08:00

Files

TomSweeneyRedHat 5f932fa441 Add api link to tutorials

We recently moved the "How to use libpod for custom/derivative projects" page to
the docs/tutorials directory.  This adds a link to the README.md there so it can
be more easily found and adds a logo to the tutorial itself.

Signed-off-by: TomSweeneyRedHat <tsweeney@redhat.com>

2019-10-02 10:25:42 -04:00

1.3 KiB

Raw Blame History

How to use libpod for custom/derivative projects

libpod today is a Golang library and a CLI. The choice of interface you make has advantages and disadvantages.

Running as a subprocess

Advantages:

Many commands output JSON
Works with languages other than Golang
Easy to get started

Disadvantages:

Error handling is harder
May be slower
Can't hook into or control low-level things like how images are pulled

Vendoring into a Go project

Advantages:

Significant power and control

Disadvantages:

You are now on the hook for container runtime security updates (partially, runc/crun are separate)
Binary size
Potential skew between multiple libpod versions operating on the same storage can cause problems

Varlink

Some code exists for this; splits the difference. Future uncertain.

Making the choice

A good question to ask first is: Do you want users to be able to use podman to manipulate the containers created by your project? If so, that makes it more likely that you want to run podman as a subprocess. If you want a separate image store and a fundamentally different experience; if what you're doing with containers is quite different from those created by the podman CLI, that may drive you towards vendoring.

1.3 KiB Raw Blame History