Run podman socket and use its API instead of calling it directly

[muayyad-alsadi]

We have been asked to re-implement podman-compose using Podman API instead of calling it directly

Many people run podman socket daemon then use stock docker-compose and it worked for them

I do NOT agree with this and we are going to discuss why.

Examples

• RFC: Supporting libpod REST API #454
• Positioning of Podman-Compose versus Docker-Compose #347
• Refactor to be called as an interface implementation from docker-compose #126
• Is this project dead or stalled? Status? #151
• podman-system-service and docker-compose #257
• Future of podman-compose #276

here we will discuss this issue

Quote from @Elkasitu

Context

Currently, all podman operations done by podman-compose are done by executing podman as a program and passing it various command-line arguments.

Podman offers a REST API exposed through unix sockets, I believe it's possible to use this API for most if not all podman operations currently used by podman-compose.

Rationale

I think using the API would result in many benefits, including but not limited to:

• Cleaner, more robust code
• Less boilerplate
• Potentially better performance
• Potentially easier to test
• Offloading of certain things (e.g. thread creation for podman start) to libpod

Notes

• At least on my machine, using the API requires either starting the socket as a user (e.g. systemctl --user start podman.socket) or running whatever program requires access to the socket as sudo. There's probably a way to config with udev rules so that a non-root user can use the socket, this should be documented if the rest API support is green lit.
• This would require a transition period, meaning for a while both command-line and rest api commands would be supported, IMO the best way to do this would be to initially test if the unix socket is available and use that by default, otherwise fallback to command-line calls. This behavior could be overridden by a flag (maybe).

Are there any reasons not to use the REST API exposed by libpod? (other than it consuming a lot of time? :^))

Any comments, questions, etc. welcome

END OF QUOTE

[muayyad-alsadi]

With respect to separation of concerns there something I always say: "even if I have many hats (concerns) but I only wear one hat at a time."
My vision to podman/podman-compose is it's single-host container orchestration tool

• for developer experience (git clone ..; cd proj; podman-compose up -d)
• sharing stacks of a simple YAML is better than sharing vargrant / VM images
• production use case: single-host container orchestration, that is generating systemd unit and start those services.

This is was very simimlar to the vision of original docker compose but it no longer the case when they merged swarm into docker daemon
(long long ago swarm was a separated daemon, not part of docker daemon, now it's just a mode for the docker daemon)

Basically they wanted to compete with kubernetes (multi-host container orchestration)
They believe in one fat daemon with "one-size fits all" approach,
cluster-everything, know everything, handle every-case,
their fat daemon do everything (the building, pulling, ...etc)

as opposed to podman model which is the process model, do one thing and do it right
podman build calls buildah, podman pull calls skopeo ..etc.

yes, one can start a podman socket (podman daemon) and use docker-compose v1 (python) or v2 (go versions)
but this is not the code vision of this project

what podman-compose do and what it should not do

podman-compose is focused on:

1. multi-user rootless-first and rootful later (two non-root users can run their own containers with no clash)
2. process model (exec podman), in ideal world "ps aux | grep podman-compose" should not give results.
3. no daemon, no long running process, podman-compose calls podman and podman setup names spaces ..etc then exec the process (here exec means it replaces the process, there should be no podman process running in the background)
4. do not reinvent the wheel: delegate to podman, systemd, ansible ...etc when possible
5. we do not compete with kubernetes. there will be never swarm mode in this podman-compose

in my opinion podman-compose up should eventually be translated into

podman pod create --name mypod
podman create --pod mypod --name mypod_db
podman create --pod mypod --requires mypod_db --name mypod_web
podman pod start mypod
exec podman pod logs -f mypod

after the last command there will be no running podman-compose (because exec replaced it) and the podamn process will be following the logs

and podman pod start mypod and podman pod stop mypod can be part of a systemd unit
and in that case there should be no podman running in the background, just the desired service (podman setup the namespaces..etc. then exec the process).

this is not yet the case, but this is what I'm aiming for.

Potentially better performance

the current code is slow, because we run into a race condition in podman 1.x (most likely it's solved in 3.x), but adding sleep 1 back then was a quick fix.

I bet you, just exec the process is way faster and efficient than running a fat daemon.

Cleaner, more robust code

a cli process calling another cli process is part of the unix philosophy, each cli command "do one thing and do it right"
it's not considered a bad messy thing

Offloading of certain things (e.g. thread creation for podman start) to libpod

the only reason for threads to exists is

• colors
• names
• bug in podman logs not following containers no started
• similar bug

if those are fixed, there will be no threads in podman compose and it will be replaced with

exec podman pod logs --name --color -f

[muayyad-alsadi]

from the discussion here
which is summarized here

there are two advantages of process model vs. daemon

• security: process is always running as current user (no chown/chmod 777 hacks), no security concerns (who can access the socket of who)
• performance: when you docker build over socket, the docker client creates a large tarball of the current directory (context) and transfer this tarball to the "remote" daemon, and the daemon extract this tarball, with podman/buildah this is not the case. if you use the current podman-compose which uses the cli interface and typed podman-compose build you will save this entire hell.

[MrPixelized]

I agree with this and like the approach more! Podman-compose being just a simpler and declarative way to run podman is exactly right.