Allow communication between two containers in the same bridged network

General
1

Hi!
Here is my docker-compose.yml:

version: "2.4"
services:
    portainer:
        image: portainer/portainer-ce:2.17.1-alpine
        container_name: byod-portainer
        restart: always
        volumes:
            - /var/run/docker.sock:/var/run/docker.sock
            - portainer_data:/data
        ports:
            - "9999:9000"
        logging:
            driver: none

    portainer_agent:
        image: portainer/agent:2.17.1-alpine
        volumes:
            - /var/run/docker.sock:/var/run/docker.sock
            - /var/lib/docker/volumes:/var/lib/docker/volumes
        ports:
            - "9001:9001"
        restart: always

volumes:
    portainer_data:

So I have two containers in the same bridged network named myapp_default.
My portainer container must be allowed to contact portainer_agent on port 9001.
Here is the iptable rule automatically created by my docker compose:

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp  --  !br-e46741861868 br-e46741861868  0.0.0.0/0            172.21.0.3           tcp dpt:9001

In my case when my portainer request request https://10.0.0.17:9001/ping (my eth0 ip), packet is in input on br-e46741861868 and in output on the same interface, so this rule doesn’t match (in = ! br-e46741861868).

Should I:

  • Use the br- interface?

iptables -A INPUT -i br-e46741861868 -p tcp --dport 9001 -j ACCEPT

I’m not sure is a good idea creating iptables rules on a “virtual” interface, and it not really script friendly…

  • Use a larger rule?

iptables -A INPUT -p tcp --dport 9001 -j ACCEPT

But less secure…

What would be the good practice to allow communication between these containers?

2

Every compose project creates a user defined network. Every user defined network has built-in dns-based service discovery. Containers in the same network can communicate with any other container in the same network on any port (as long as a process is listening on that port). So the good and the bad part is: there is no port-filter or restriction of any kind. Just use the service name of the target container and the container port for the connection.

3

Much more easier with your solution, indeed! Thanks a lot!