Add support for Podman runtime

[runabol]

Tork has support for Docker as its default runtime environment. Podman and Docker share many similarities in terms of functionality and concepts, but they also have some differences.

One significant difference is that Podman operates in a daemonless mode by default. It runs containers as child processes of the Podman command, while Docker traditionally uses a daemon (dockerd) to manage containers. This can be an advantage in terms of security and resource usage for Podman.

Podman has robust support for running containers as non-root users, while Docker requires privileged access to the daemon. This is seen as a security improvement in Podman.

Podman had been gaining popularity within the containerization and DevOps communities. It had a growing and active community of users and contributors.

The goal of this feature is to add first-class support to running tasks within a Podman environment.

Rough outline of the implementation:

1. Create a new podman package in the runtime package.
2. Create a podman.go file within this package.
3. Create a PodmanRuntime struct to implement the Runtime interface.
4. Wire the runtime into the engine on startup when the runtime.type config is set to podman.
5. Add tests.

[ionut-maxim]

@runabol would it be okay if you assign this issue to me?

[runabol]

Done

[ionut-maxim]

Hey @runabol,

While investigating the initial implementation, I encountered an issue. The current Podman package for Go, libpod, has dependencies on many types that Podman uses internally (see: containers/podman#12548).

A possible workaround could involve setting some build flags, as mentioned in that issue. However, I believe a better approach would be to utilize Podman's REST API, which is exposed through a Unix socket or a normal socket, similar to Docker. This would also help avoid adding approximately 40MB of dependencies to the project.

What are your thoughts on this?

[runabol]

I definitely would agree that adding the library and its attendant dependencies is probably not a great idea.

As for using the REST API through a unix socket, that doesn't sound very cross-platform friendly.

One of my favorite features about podman is its ability to run daemon-less. So if we resort to running it as a service, I feel like we're losing on that advantage. Plus I'm not sure if there's parity between the REST API and the CLI.

What about simply calling the podman cli from Go?

[ionut-maxim]

After further investigation, it looks like a CLI wrapper would be the simplest implementation. Although podman creates lightweight VMs on MacOS and Windows and establishes an SSH tunnel to the VM to access the socket, it requires parsing a configuration file and setting up the tunnel for these platforms.

So, yeah, a CLI wrapper it is for now 😄

[jspc]

I found this issue trying to see whether I could use tork via podman on arch and thought it worth adding this note for anyone who comes after me, whose situation is similar to mine.

If you're happy to run podman with a daemon (which on systemd in my distro is accomplished with systemctl start podman.socket) then just setting DOCKER_HOST to the relevant socket is enough.

[runabol]

This is great to know!