blob: e38c2b13d29aa1fd347ec76100ae5f3b1d9f96b0 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
# 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.
Using the REST API
---
Advantages:
- Stable, versioned API
- Language-agnostic
- [Well-documented](http://docs.podman.io/en/latest/_static/api.html) API
Disadvantages:
- Error handling is less verbose than Golang API
- May be slower
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
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 or using the HTTP API. 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.
|
