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 am invoking a setup consisting of several containers. Each container is connected to a "backend" network, which serves for container-to-container communication, exchange of data, etc. To ensure that the commucation is restricted to that purpose, it is set up with the --internal option. Those containers which need to expose ports to the outside or need internet access are also connected to a "frontend" network. To restrict communication other than that on that network, it is set up with the "icc=false" option.
The follwing example can be used for illustration:
Since this is not specified, it is unclear to which subnet a reference to the other container will resolve. I am experiencing issues whenever the frontend ip of the other container is given and hence the container tries to establish communication over the frontend, which is blocked.
I am experiencing these issues in different container setups. I am wondering why the dns server provides dns entries for other containers in subnets in which container-to-container communication is explicitly blocked. So one possible solution to this issue could to remove dns entries/not create them on the docker host.
Another possible solution might be to increase the metric for the interface to whichever the network with internet access is assigned to. Can that be done with a docker-compose setting or would that have to be done manually?
[x ] I have tried with the latest version of my channel (Stable or Edge)
I have submitted Diagnostics - Example docker-compose file instead
Windows Version: Windows Server 2016
Docker for Windows Version:
Client:
Version: 18.03.0-ce
API version: 1.37
Go version: go1.9.4
Git commit: 0520e24
Built: Wed Mar 21 23:06:28 2018
OS/Arch: windows/amd64
Experimental: false
Orchestrator: swarm
Server:
Engine:
Version: 18.03.0-ce
API version: 1.37 (minimum version 1.12)
Go version: go1.9.4
Git commit: 0520e24
Built: Wed Mar 21 23:14:32 2018
OS/Arch: linux/amd64
Experimental: false
Expected behavior
Docker should resolve dns entries for networks with ICC=true only
Actual behavior
Docker resolves dns entries for ICC-false networks for container-to-container communication which leads to blocked communication attempts.
Steps to reproduce the behavior
See dockerfiles above
The text was updated successfully, but these errors were encountered:
I've added the files for convenience since I've not managed to display the code properly. Please rename the docker_networks.log to docker_networks.ps1 and docker-compose.log to docker-compose.yml.
I am running this setup with the docker-compose file and externally defined networks since I am using some functions that require a new version of docker-compose above v3 which does not support all options for network setups as of now.
For reference: a more elegant solution is to reach the other container via its fully qualified DNS name, i.e. container1.backend. Using this approach helps in controlling communication paths when multiple networks are in use.
I am invoking a setup consisting of several containers. Each container is connected to a "backend" network, which serves for container-to-container communication, exchange of data, etc. To ensure that the commucation is restricted to that purpose, it is set up with the --internal option. Those containers which need to expose ports to the outside or need internet access are also connected to a "frontend" network. To restrict communication other than that on that network, it is set up with the "icc=false" option.
The follwing example can be used for illustration:
`
version: "3.6"
services:
container1:
image: alpine
container_name: containter1
entrypoint: ping container2
networks:
- frontend
- backend
networks:
frontend:
external: true
backend:
external: true
`
While the networks are set up with the following arguments:
`
docker network create
--driver=bridge
--subnet=10.2.111.0/24 ``
--gateway=10.2.111.1 ``
--opt="com.docker.network.bridge.enable_icc"="false" ``
frontend
docker network create
--driver=bridge
--subnet=10.2.112.0/24
--gateway=10.2.112.1
--opt="com.docker.network.bridge.enable_icc"="true" ``
backend
`
Now I understand that there is currently no possibility of assigning an order to the networks, i.e. which network will be assigned to eth0:
docker/compose#4962
docker/compose#4645
Since this is not specified, it is unclear to which subnet a reference to the other container will resolve. I am experiencing issues whenever the frontend ip of the other container is given and hence the container tries to establish communication over the frontend, which is blocked.
I am experiencing these issues in different container setups. I am wondering why the dns server provides dns entries for other containers in subnets in which container-to-container communication is explicitly blocked. So one possible solution to this issue could to remove dns entries/not create them on the docker host.
Another possible solution might be to increase the metric for the interface to whichever the network with internet access is assigned to. Can that be done with a docker-compose setting or would that have to be done manually?
Client:
Version: 18.03.0-ce
API version: 1.37
Go version: go1.9.4
Git commit: 0520e24
Built: Wed Mar 21 23:06:28 2018
OS/Arch: windows/amd64
Experimental: false
Orchestrator: swarm
Server:
Engine:
Version: 18.03.0-ce
API version: 1.37 (minimum version 1.12)
Go version: go1.9.4
Git commit: 0520e24
Built: Wed Mar 21 23:14:32 2018
OS/Arch: linux/amd64
Experimental: false
Expected behavior
Docker should resolve dns entries for networks with ICC=true only
Actual behavior
Docker resolves dns entries for ICC-false networks for container-to-container communication which leads to blocked communication attempts.
Steps to reproduce the behavior
See dockerfiles above
The text was updated successfully, but these errors were encountered: