Possible bug on resolve hostname in compose #730

Jul 17, 2023

joubertredrat
Jul 17, 2023

Hi guys,

I'm testing podman to be a alternative for docker in my open source project Devbox.

During my tests, I discovered a issue and I don't know it's expected behavior or a bug. In my compose file I use hostname to define service hostname, like this example.

In docker, the service name and hostname is resolvable as expected

/home/dbgate-docker # ping db
PING db (172.18.0.2) 56(84) bytes of data.
64 bytes from devbox9ad-db-1.devbox9ad_mysql80_network_local (172.18.0.2): icmp_seq=1 ttl=64 time=0.859 ms
64 bytes from devbox9ad-db-1.devbox9ad_mysql80_network_local (172.18.0.2): icmp_seq=2 ttl=64 time=0.079 ms
64 bytes from devbox9ad-db-1.devbox9ad_mysql80_network_local (172.18.0.2): icmp_seq=3 ttl=64 time=0.241 ms
64 bytes from devbox9ad-db-1.devbox9ad_mysql80_network_local (172.18.0.2): icmp_seq=4 ttl=64 time=0.313 ms
^C
--- db ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3037ms
rtt min/avg/max/mdev = 0.079/0.373/0.859/0.293 ms

/home/dbgate-docker # ping db.mysql80.devbox.local
PING db.mysql80.devbox.local (172.18.0.2) 56(84) bytes of data.
64 bytes from devbox9ad-db-1.devbox9ad_mysql80_network_local (172.18.0.2): icmp_seq=1 ttl=64 time=0.092 ms
64 bytes from devbox9ad-db-1.devbox9ad_mysql80_network_local (172.18.0.2): icmp_seq=2 ttl=64 time=0.357 ms
64 bytes from devbox9ad-db-1.devbox9ad_mysql80_network_local (172.18.0.2): icmp_seq=3 ttl=64 time=0.168 ms
64 bytes from devbox9ad-db-1.devbox9ad_mysql80_network_local (172.18.0.2): icmp_seq=4 ttl=64 time=0.224 ms
^C
--- db.mysql80.devbox.local ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3008ms
rtt min/avg/max/mdev = 0.092/0.210/0.357/0.096 ms

But in podman, only service name is resolvable

/home/dbgate-docker # ping db
PING db.dns.podman (10.89.1.10) 56(84) bytes of data.
64 bytes from 1c1bde24bcb0 (10.89.1.10): icmp_seq=1 ttl=64 time=0.018 ms
64 bytes from 1c1bde24bcb0 (10.89.1.10): icmp_seq=2 ttl=64 time=0.056 ms
64 bytes from 1c1bde24bcb0 (10.89.1.10): icmp_seq=3 ttl=64 time=0.296 ms
64 bytes from 1c1bde24bcb0 (10.89.1.10): icmp_seq=4 ttl=64 time=0.234 ms
^C
--- db.dns.podman ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3082ms
rtt min/avg/max/mdev = 0.018/0.151/0.296/0.116 ms

/home/dbgate-docker # ping db.mysql80.devbox.local
ping: db.mysql80.devbox.local: Try again

My doubt is: This is expected behavior or a bug? I need to know to open a issue if needed.
Thanks

joubertredrat · Jul 18, 2023

muayyad-alsadi
Jul 18, 2023
Collaborator

it's supposed to work fine

please double check your setup
here is a minimal busybox example

https://github.com/containers/podman-compose/tree/devel/tests/nets_test1

look at discussion here

#500 (comment)

if you are using 4 make sure you use netavark and disable cni networking or vice versa
it seems they are typically half installed or badly configured

4 replies

joubertredrat Jul 18, 2023
Author

Hi @muayyad-alsadi, I tested using the minimal busybox example with little changes, because service name and hostname are same, then I added suffix super only to be different from service name.
With this, the behavior was same, working in docker, but not in podman, as below:

Docker

dev@Devs-MBP ~/source/opensource/other/containers__podman-compose/tests/nets_test1 (devel)> docker compose exec web2 sh
/var/www/html # ping web1
PING web1 (172.20.0.3): 56 data bytes
64 bytes from 172.20.0.3: seq=0 ttl=64 time=2.094 ms
^C
--- web1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 2.094/2.094/2.094 ms

/var/www/html # ping superweb1
PING superweb1 (172.20.0.3): 56 data bytes
64 bytes from 172.20.0.3: seq=0 ttl=64 time=0.474 ms
^C
--- superweb1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.323/0.398/0.474 ms
/var/www/html #

Podman

dev@Devs-MBP ~/source/opensource/other/containers__podman-compose/tests/nets_test1 (devel)> podman-compose exec web2 sh
podman-compose version: 1.0.6
['podman', '--version', '']
using podman version: 4.5.1
podman exec --interactive --tty nets_test1_web2_1 sh
/var/www/html # ping web1
PING web1 (10.89.3.26): 56 data bytes
ping: permission denied (are you root?)

/var/www/html # ping superweb1
ping: bad address 'superweb1'
/var/www/html #

I checked my setup and sounds fine, as below.

dev@Devs-MBP ~> podman-compose --version
podman-compose version: 1.0.6
['podman', '--version', '']
using podman version: 4.5.1
podman-compose version 1.0.6
podman --version
podman version 4.5.1
exit code: 0
dev@Devs-MBP ~> podman --version
podman version 4.5.1
dev@Devs-MBP ~> podman info --format {{.Host.NetworkBackend}}
netavark

I also used cni for test and had same issue.

muayyad-alsadi Aug 2, 2023
Collaborator

$ podman info  | grep -i net
  networkBackend: netavark

joubertredrat Aug 3, 2023
Author

Yes @muayyad-alsadi, I used this command too. Then should I create a issue on repo about it?

joubertredrat Aug 3, 2023
Author

@muayyad-alsadi I made more debugs here and have more informations.

dev@Devs-MacBook-Pro ~/source/opensource/other/containers__podman-compose/tests/nets_test1 (devel)> podman-compose up -d
podman-compose version: 1.0.7
['podman', '--version', '']
using podman version: 4.6.0
** excluding:  set()
['podman', 'ps', '--filter', 'label=io.podman.compose.project=nets_test1', '-a', '--format', '{{ index .Labels "io.podman.compose.config-hash"}}']
podman pod create --name=pod_nets_test1 --infra=false --share=
0d42072e5c4c6b3b2c1761ade6a30f5ec58ebb62e7dc4acc45bf3a667c4fad37
exit code: 0
['podman', 'network', 'exists', 'nets_test1_default']
podman run --name=nets_test1_web1_1 -d --pod=pod_nets_test1 --label io.podman.compose.config-hash=95575f6d89e15dc8614e950c85d977aaa9caf5c9a57d14b610803ef37fdf653c --label io.podman.compose.project=nets_test1 --label io.podman.compose.version=1.0.7 --label PODMAN_SYSTEMD_UNIT=podman-compose@nets_test1.service --label com.docker.compose.project=nets_test1 --label com.docker.compose.project.working_dir=/Users/dev/source/opensource/other/containers__podman-compose/tests/nets_test1 --label com.docker.compose.project.config_files=docker-compose.yml --label com.docker.compose.container-number=1 --label com.docker.compose.service=web1 -v /Users/dev/source/opensource/other/containers__podman-compose/tests/nets_test1/test1.txt:/var/www/html/index.txt:ro --net nets_test1_default --network-alias web1,web1.dev.local -p 38001:8001 -w /var/www/html --hostname superweb1 busybox /bin/busybox httpd -f -h /var/www/html -p 8001
793e1af3d633eeeeea21a25f792f278d279c131fca77b53f0b0363312ff16e98
exit code: 0
['podman', 'network', 'exists', 'nets_test1_default']
podman run --name=nets_test1_web2_1 -d --pod=pod_nets_test1 --label io.podman.compose.config-hash=95575f6d89e15dc8614e950c85d977aaa9caf5c9a57d14b610803ef37fdf653c --label io.podman.compose.project=nets_test1 --label io.podman.compose.version=1.0.7 --label PODMAN_SYSTEMD_UNIT=podman-compose@nets_test1.service --label com.docker.compose.project=nets_test1 --label com.docker.compose.project.working_dir=/Users/dev/source/opensource/other/containers__podman-compose/tests/nets_test1 --label com.docker.compose.project.config_files=docker-compose.yml --label com.docker.compose.container-number=1 --label com.docker.compose.service=web2 -v /Users/dev/source/opensource/other/containers__podman-compose/tests/nets_test1/test2.txt:/var/www/html/index.txt:ro --net nets_test1_default --network-alias web2,web2.dev.local -p 38002:8001 -w /var/www/html --hostname superweb2 busybox /bin/busybox httpd -f -h /var/www/html -p 8001
cedf5764810183858c13630b601bab8c4754ee652c342b8ad16644f8f50052b2
exit code: 0

If you see --network-alias web1,web1.dev.local, I inserted the part .dev.local hardcoded just to test, then, flag --network-alias is working fine.

But, hostname is defined by --hostname superweb1 flag. Now I have the doubt, is expected that hostname defined in --hostname is resolvable in dns inside de podman like is with --network-alias? I guess yes but not 100% sure about it.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Possible bug on resolve hostname in compose #730

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 1 comment · 4 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

Select a reply

Search code, repositories, users, issues, pull requests...

Possible bug on resolve hostname in compose #730

joubertredrat Jul 17, 2023

Replies: 1 comment · 4 replies

muayyad-alsadi Jul 18, 2023 Collaborator

joubertredrat Jul 18, 2023 Author

muayyad-alsadi Aug 2, 2023 Collaborator

joubertredrat Aug 3, 2023 Author

joubertredrat Aug 3, 2023 Author

joubertredrat
Jul 17, 2023

muayyad-alsadi
Jul 18, 2023
Collaborator

joubertredrat Jul 18, 2023
Author

muayyad-alsadi Aug 2, 2023
Collaborator

joubertredrat Aug 3, 2023
Author

joubertredrat Aug 3, 2023
Author