Is there an Golang API without socket connection

[axetroy]

I found API use cases for Golang https://github.com/containers/Demos/blob/master/podman_go_bindings/main.go

	// Connect to Podman socket
	connText, err := bindings.NewConnection(context.Background(), socket)
	if err != nil {
		fmt.Println(err)
		os.Exit(1)
	}

I'm a little curious. podman don't a daemon process, but why connect socket?

Is there a simple API for pull image/create container/run container without connecting to the socket?

eg.

	// Connect to Podman socket
	connText, err := bindings.NewConnection(context.Background())
	if err != nil {
		fmt.Println(err)
		os.Exit(1)
	}

	_, err = images.Pull(connText, "docker.io/busybox", entities.ImagePullOptions{})
	if err != nil {
		fmt.Println(err)
		os.Exit(1)
	}

    // create container
    // run container

another words:

Is there be an independent API to create containers and run easily, and does not need to install podman

I'm trying to create an isolated test environment based on podman, if this can be achieved, that would be great.

thank you all for help.

[mheon]

You can directly call into the Libpod API (https://godoc.org/github.com/containers/podman/libpod) but it does not have the degree of documentation (or the stability guarantee) of the HTTP API.

[hickersonj]

@vrothberg when you say the bindings do you mean like the examples in this page: https://podman.io/blogs/2020/08/10/podman-go-bindings.html
I wanted to use them in v3 but the demo only has v2. In fact the tutorials for the bindings were pulled out of v3 from the documentation folder. Does that mean the only suggested/supported method is to use RESTFul APIs for pull/load/push etc? Thank you!

[mheon]

The tutorial for the bindings was moved to https://github.com/containers/podman/blob/main/pkg/bindings/README.md

I think we'll need to update the links in that blog post.

[baude]

We all need to get more specific here. The only supported "bindings" are the RESTful bindings. There are not a "specific set of bindings" available for consumption with golang--only socket based.

[hickersonj]

Ok thanks for the updated information. I don't want to head down the wrong path by using the golang API if it is not recommended.

I'm writing a utility in go and the following APIs for images pretty much has everything I need, barring that is socket based, which is fine for my use case.
https://github.com/containers/podman/blob/main/pkg/bindings/images/images.go

[lsm5]

@mheon @rhatdan would it suffice to update the links in the bindings blog, or do we need a new blog or something for v3?

[baude]

@mheon longer term, do we need to create a high level api for this kind of use case? I know we talked about it.

[mheon]

In my ideal scenario, we simplify and document the existing image API so we don't need something on top of it. But given how long the image refactor is taking, higher-level might be our best option. We already (sort of) did this with specgen for the bad parts of containers.

[vrothberg]

I think the bindings should be the only officially supported go package. Otherwise, we have to fight at too many fronts in parallel.

[baude]

they asked about not using a socket. but yes.

[petebowden]

Has there been any further progress on determining what the future will be from an API perspective? I'd rather not have to have a socket running to interact with podman - not having a socket open is an advantage over docker

[mheon]

Not really - no one's found the time to make this a priority.

I will say that it is highly unlikely rootless Podman will ever support a non-socket-based API. There's too many things that need to happen that can't be done in the API itself - joining the user namespace on application startup is very complicated and we can't automate it, as an example.

For root, I'm still of the position that we can make the existing Libpod API work with some review and tweaking, plus a stability guarantee. Unfortunately that last bit is going to be difficult to do without a review of the API and major version bump to fix the existing issues.

[baude]

imho, blogs are always welcome!

[lsm5]

@baude umm, was that a response to my recent comment? first time i'm seeing this discussion tab and this looks like a new comment.

[superewald]

I just stumbled across this discussion because I searched for a daemonless API for podman, seems there is not going to be an alternative to the go bindings but is that really required ?

Couldn't we just implement a simple cli wrapper for podman which uses --format=json to parse the output ?
I will probably do so for my own little project but maybe that is of interest for others too.
Do you know of any issues with that approach ? I'm curious because I can't find such a library whereas it should be relatively easy to implement.

[debarshiray]

Couldn't we just implement a simple cli wrapper for podman which
uses --format=json to parse the output ?

I will probably do so for my own little project but maybe that is of interest
for others too.

This is what Toolbx does, and seems to have held up over time.

We couldn't or didn't switch to the HTTP API because:

• A desire to be easily portable across a wide cross-section of operating systems (eg., from Fedora and Arch to potentially RHEL 7)
• The HTTP API didn't exist when Toolbx was re-written in Go, and switching to it will require another major overhaul, which we can't afford right now.

[superewald]

This is what Toolbx does, and seems to have held up over time.

That's fun, I was just about implementing the same on my own because I didn't find such a project. I really have to improve my search behavior.. Thanks for bringing that up :)