podman-compose
Closed this issue · 4 comments
Trying to run podman-compose instead of using docker, I get first errors due to wrong paths: buildme.sh creates deploy/dc/target/prometheus but the docker-compose requires ./target/data/prometheus (note the data).
After fixing this oversight, I still cannot start as several services listen on port 8080. IIUC with podman containers that should communicate must live in a single pod and share the network (so these cannot listen on the same IP:port). Unlike docker it's not possible to connect from within container to the docker-IP:external-port.
Good catch on the missing data directory. I must not have wiped the slate completely clean in awhile to trip on the directory permissions issue.
I think your understanding of what docker compose is doing is incorrect. Each container is assigned a separate hostname (based on service name) within a shared network. That's why Graphana references prometheus using http://prometheus:.. The containers are not (to my knowledge) using the docker-ip to do this, but it may be that I'm missing something or not understanding you properly.
In any event, this is a fundamental nicety about docker-compose: it does not impose requirements on configuration of the container for you to compose several of them together for local test/development. I would rather not reconfigure the ports in each of the service variants to satisfy podman-compose when neither docker-compose nor kubernetes impose those requirements.
Well my knowledge of podman is rudimentary, but the thing is that containers running in the same pod are sharing the IP address. Accessing them by service name is certainly possible but it resolves to the same IP. But in this case the containers on the same port cannot start.
I might have mixed in another issue with container -> host communication that's not relevant here (and I can't find a reference ATM), sorry for confusion.
Anyway, I've heard recent versions of Docker support cgroups2 so eventually even users on modern Fedoras will be able to run this. I am not a fan of podman myself, just trying to dogfood (and having no other option).
It's ok. ;) But I don't think I'll be changing the ports of the various services to make podman-compose happy.. it is the outlier here, IMO. If they want to run existing docker-compose configurations unchanged, they'll have to sort out how to deal with this.
The answer may lie somewhere within transform_policy options...
parser.add_argument("-t", "--transform_policy",
help="how to translate docker compose to podman [1pod|hostnet|accurate]",
choices=['1pod', '1podfw', 'hostnet', 'cntnet', 'publishall', 'identity'], default='1podfw')