[GH-ISSUE #451] [Enhancement] Relax Docker dependencies to enable other container engines. #226

New issue

Open

opened 2026-03-04 01:35:42 +03:00 by kerem · 2 comments

kerem commented

2026-03-04 01:35:42 +03:00

Owner

Originally created by @MrDrMcCoy on GitHub (Oct 7, 2025).
Original GitHub issue: https://github.com/spr-networks/super/issues/451

I was very nearly successful in getting SPR running with Podman / systemd Quadlets, but ran into some issues:

Many of the scripts seem to be trying to make changes pertaining to the default Docker container network. Is this really needed? All of the containers are configured to use host networking, so it seems strange to me that SPR would care about the internal Docker net (which doesn't exist with Podman, and may not with other engines either).
It seems that every time SPR wants to restart one of its components, one of the services tries to shell out to the literal docker compose binary to try and restart the container. Why do that when the api and superd containers already bind to the Docker control socket? If the restart is initiated via the control socket, it can target the desired containers by name and not rely on brittle shell commands. Podman provides a compatible control socket, so no special handling is needed beyond not talking to the Docker CLI.
Docker automatically creates volume bind paths on the host if they don't exist, but Podman does not. Many of the paths requested are not defined as part of the example configs that are copied. This is as simple to fix as including the directories in the example config paths, which would as a bonus help users to know where to place additional configs.

For now, I will wipe my setup and try again with official Docker.

Originally created by @MrDrMcCoy on GitHub (Oct 7, 2025). Original GitHub issue: https://github.com/spr-networks/super/issues/451 I was very nearly successful in getting SPR running with Podman / systemd Quadlets, but ran into some issues: 1. Many of the scripts seem to be trying to make changes pertaining to the default Docker container network. Is this really needed? All of the containers are configured to use host networking, so it seems strange to me that SPR would care about the internal Docker net (which doesn't exist with Podman, and may not with other engines either). 2. It seems that every time SPR wants to restart one of its components, one of the services tries to shell out to the literal `docker compose` binary to try and restart the container. Why do that when the `api` and `superd` containers already bind to the Docker control socket? If the restart is initiated via the control socket, it can target the desired containers by name and not rely on brittle shell commands. Podman provides a compatible control socket, so no special handling is needed beyond not talking to the Docker CLI. 3. Docker automatically creates volume bind paths on the host if they don't exist, but Podman does not. Many of the paths requested are not defined as part of the example configs that are copied. This is as simple to fix as including the directories in the example config paths, which would as a bonus help users to know where to place additional configs. For now, I will wipe my setup and try again with official Docker.

kerem commented

2026-03-04 01:35:43 +03:00

Author

Owner

@lts-rad commented on GitHub (Oct 7, 2025):

This is awesome! Feel free to make a PR even if it isnt working yet.

When I last worked on podman there was some question on how to work with docker networks as defined by compose, that was one area where podman+compose seemed lacking. I know podman has been very actively developed but have not checked in if this is resolved yet. Another path to try might be moving into systemd defined networks and services from docker compose. I would say the main value add for compose right now is building, and everything else is not really needed

Regarding 1, we use nftables rather than iptables and manage the network ourselves to block 1-hop forwarding attacks as well as have more control over containers, are you referring to this or something else?

definitely worth replacing this, i think some aspect of this was related to ensuring correctness if launching a container from source. the other huge reason to do this is shrinking superd & api

@lts-rad commented on GitHub (Oct 7, 2025): This is awesome! Feel free to make a PR even if it isnt working yet. When I last worked on podman there was some question on how to work with docker networks as defined by compose, that was one area where podman+compose seemed lacking. I know podman has been very actively developed but have not checked in if this is resolved yet. Another path to try might be moving into systemd defined networks and services from docker compose. I would say the main value add for compose right now is building, and everything else is not really needed Regarding 1, we use nftables rather than iptables and manage the network ourselves to block 1-hop forwarding attacks as well as have more control over containers, are you referring to this or something else? 2. definitely worth replacing this, i think some aspect of this was related to ensuring correctness if launching a container from source. the other huge reason to do this is shrinking superd & api

kerem commented

2026-03-04 01:35:43 +03:00

Author

Owner

@MrDrMcCoy commented on GitHub (Oct 7, 2025):

Indeed, the first point was about the nftables configs. Some of them specifically target the docker0 interface, which of course doesn't exist without actually running Docker. I didn't look too closely to see if the errors surrounding the attempts to create rules for the non-existent interface caused any of the other rules to not be applied. It may be worth re-visiting this to see if there is a good way to apply these rules with dynamic targeting, both to handle missing Docker interfaces and potentially additional interfaces that may exist from other configs.

@MrDrMcCoy commented on GitHub (Oct 7, 2025): Indeed, the first point was about the nftables configs. Some of them specifically target the docker0 interface, which of course doesn't exist without actually running Docker. I didn't look too closely to see if the errors surrounding the attempts to create rules for the non-existent interface caused any of the other rules to not be applied. It may be worth re-visiting this to see if there is a good way to apply these rules with dynamic targeting, both to handle missing Docker interfaces and potentially additional interfaces that may exist from other configs.