Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable name resolution issues on networks with icc=false #1907

Closed
1 task
Ageraluon opened this issue Mar 31, 2018 · 3 comments
Closed
1 task

Disable name resolution issues on networks with icc=false #1907

Ageraluon opened this issue Mar 31, 2018 · 3 comments

Comments

@Ageraluon
Copy link

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

container2:
    image: alpine
    container_name: container2
    entrypoint: ping container1
    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?

  • [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

@Ageraluon
Copy link
Author

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.

docker_networks.log
docker-compose.log

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.

@Ageraluon
Copy link
Author

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.

@docker-robott
Copy link
Collaborator

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked

@docker docker locked and limited conversation to collaborators Jun 27, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants