Accessing podman's docker socket alias from within a toolbox

Ask Fedora
, , , ,
1

Hi,

I’m a long-time Windows software developer currently assessing how I can transition my development machine to a Linux desktop. After some exploring I decided to try Silverblue and see how I get on. Right now I’m trying to get a development environment for a personal project - one that I understand back to front - working. Hopefully it’s OK to ask for some assistance here to get me moving.

I figured it’s good practice to create a toolbox specifically for the project, although I might also create toolboxes in a more granular fashion according to required tools - will figure that out later. So I have a toolbox with required tools installed and can build my project. Great.

The test suite for this project uses testcontainers to start up required infrastructure and put the project through its paces with end-to-end tests. If I try to run my tests without modification I get:

Docker is either not running or misconfigured. Please ensure that Docker is running and that the endpoint is properly configured. You can customize your configuration using either the environment variables or the ~/.testcontainers.properties files.

I have both podman and podman-docker installed, so I did some digging and think I figured out that I need to point the testcontainers to unix:/var/run/host/var/run/docker.sock. When I do that the output changes to:

SocketException: Cannot assign requested address

From within the toolbox, if I ll /var/run/host/var/run/docker.sock I see:

lrwxrwxrwx. 1 nobody nobody 23 May  5 12:18 /var/run/host/var/run/docker.sock -> /run/podman/podman.sock

So I guess the problem here is that the toolbox user (1000) doesn’t have access to that file. But what is the correct way to fix this? On the host I see:

> ll /var/run/docker.sock
lrwxrwxrwx. 1 root root 23 May  5 12:18 /var/run/docker.sock -> /run/podman/podman.sock

So it’s not like there’s a docker or podman group I can easily add my user to to solve this. But should I even be messing with these permissions or is there a cleaner way that won’t come back to bite me?

Thanks for any pointers.

PS. eventually I’d like to remove docker from the equation and use only podman, but for now I’m trying not to change too many things at once.

3

You might want to start with rootless podman and the corresponding user socket/service. This should be accessible from your toolbox.

Otherwise you will have to make sure that your toolbox preserves the groups that you need to access the system docker/podman socket.

4

Thanks @siosm. I did some more research and indeed rootless is the way to go.

I’m almost completely in a working state now (more on that shortly), in both the toolbox and my IDE (Rider, which is installed via Flatpak). Here’s what I had to do:

  1. Enable the podman socket, which is disabled by default (for security reasons, I guess):
    systemctl --user enable podman.socket
  2. Get the location of the socket:
    systemctl --user status podman.socket
    The output of this command includes a “Listen” address for the socket. For me it is /run/user/1000/podman/podman.sock.
  3. Use that listen address when interacting with podman via Testcontainers. I believe this can be done via environment variables, but I’m currently doing it quite explicitly:
    let dockerEndpoint = "unix:/run/user/1000/podman/podman.sock"

let postgresContainer =
    PostgreSqlBuilder()
        .WithDockerEndpoint(dockerEndpoint)
        ...
  4. For Rider, I had to grant access to the socket endpoint:
    flatpak override --user --filesystem=/run/user/1000/podman/podman.sock com.jetbrains.Rider

That is enough to almost work perfectly, but around 20% of the time my tests fail to start up when attempting to set up the docker containers. The underlying issue is “connection reset by peer”, which appears to be a common historical problem with podman, though in all cases I could find it seems like it’s readily repeatable, whereas for me it is sporadic.

So that’s the issue I’m left with: unreliable podman integration due to the socket resets.