You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a podman-compose.yaml file that creates a fully functional pod when I do podman-compose up. I can connect to it from the browser just as expected and everything works fine. However, I wanted to turn it into a quadlet, so to achieve this purpose, I've used podlet -u compose --pod podman-compose.yaml. It created the files and I could start my pod using systemctl --user, but for some reason I am unable to connect to any container inside this pod. The same configuration works just right away with compose.
I've seen the issue #90 and manually added .network to my .container files, but it still doesn't resolve the issue.
I tried to connect to it using both localhost:port (this work when run from compose) and containerName:port, but I couldn't connect to it in either case. Using curl gives me (56) Recv failure and (6) Could not resolve host respectively.
journalctl doesn't report any issues for systemctl --user daemon-reload nor systemctl --user start sonarr-pod /usr/lib/systemd/system-generators/podman-system-generator --user --dryrun doesn't report any issues as well.
I can also confirm that each individual container in itself is also running just fine.
Am I doing something wrong or missing something crucial here?
The content of my podman-compose.yaml is as follows:
I created a pod from a Kubernetes YAML file generated from a Docker Compose file, and it works fine. However, I don’t achieve the same result when using compose --pod and systemd --user. The network is created as specified, but when I attempt to access a service via the Firefox web browser, it shows a “PR_END_OF_FILE_ERROR.” Interestingly, it doesn’t require the corresponding service’s container to be up; it only needs the pod to be running.
I managed to resolve the issue by removing all"PublishPort=" from .container files, leaving PublishPorts only in .pod file. I also deleted all "Network=" lines from all files, including .pod file itself, and removed .network file altogether.
Pod now behaves like expected from the original compose file.
@tiritto As you discovered, the problem was that your containers were part of a network that was separate from the pod's network and therefore couldn't communicate using the pod's exposed ports. I'm not sure what the correct solution here is for Podlet if any. Do what you did manually and remove the networks from the containers if they are all the same and move it to the .pod file? That might be surprising to some. Just add a warning to the --pod help saying to make sure you understand how pods work?
I have a
podman-compose.yaml
file that creates a fully functional pod when I dopodman-compose up
. I can connect to it from the browser just as expected and everything works fine. However, I wanted to turn it into a quadlet, so to achieve this purpose, I've usedpodlet -u compose --pod podman-compose.yaml
. It created the files and I could start my pod usingsystemctl --user
, but for some reason I am unable to connect to any container inside this pod. The same configuration works just right away with compose.I've seen the issue #90 and manually added
.network
to my.container
files, but it still doesn't resolve the issue.I tried to connect to it using both
localhost:port
(this work when run from compose) andcontainerName:port
, but I couldn't connect to it in either case. Usingcurl
gives me(56) Recv failure
and(6) Could not resolve host
respectively.journalctl
doesn't report any issues forsystemctl --user daemon-reload
norsystemctl --user start sonarr-pod
/usr/lib/systemd/system-generators/podman-system-generator --user --dryrun
doesn't report any issues as well.I can also confirm that each individual container in itself is also running just fine.
Am I doing something wrong or missing something crucial here?
The content of my
podman-compose.yaml
is as follows:podman version 5.1.1
podlet 0.3.0
Nobara Linux 40 (based on Fedora 40)
The text was updated successfully, but these errors were encountered: