Running Podman in an Isolated Environment

[gravypod]

I'm a maintainer of rules_docker and I've been thinking of rewriting the rule set to use podman under the hood. Right now we have a lot of custom code for doing the following things:

1. Take a set of files and turn them into a layer of a container (tar file)
2. Take a set of layers (as a list of paths to layers tar files) + environment variables, start a container, run a command in that container, and create a new layer from the change.
3. Pull an image from a registry
4. Push an image to a registry (load each layer into the registry then create a tag)
5. Create a docker docker save of the container (.tar file with layers + metadata)
6. Create a bundle of multiple images in the docker save format.

The code in our repo is not in a healthy state and we'd like to transition to something more maintainable. I think using podman as a backend for managing images is probably the best bet but there are some constraints that I haven't found how to make podman work in. The biggest difficulty I see is that when commands are running in Bazel it is expected that they do not access files they are not explicitly told to access. I think podman loads some configuration, accesses caches, and writes to folders/files that would be difficult for me to predict. Would there be a way to implement something like podman -only_access_directory ./some_directory to make it so podman only ever reads/writes to that folder?

Another question: is there a good way to start podman within a golang program? I'm imagining some kind of library that has an init method that forks off podman and kills podman on exit that provides an easy to understand api.LoadImage()-like API.

[mheon]

Our usual recommendation is the REST API, which provides Go bindings and has a stability guarantee. However, it does require that you run an API server. I think it should be possible for you to fork off a copy of the server (podman system service -t 0 PATH_TO_API_SOCKET) and then use the bindings to connect to that service, then stop the service once you are finished with the operation in question, if the desire is to ensure that you don't require a persistent service be running.