Can anyone shed some light on what is what with the Docker Compose YML file?
All I want to do is to be able to control the IP addresses of the various containers. I am using version 3.1 (but also tried 3.3 as I recently upgraded to version 17.06). The documentation says:
A full example:
ipam:
driver: default
config:
- subnet: 172.28.0.0/16
Note: Additional IPAM configurations, such as gateway, are only honored for version 2 at the moment.
When I do this, I need that subnet honored when I inspect the network. However the gateway is completely different [read the Note: above], so the containers do not start. Why did they lose capability (at the moment) in version 3 for something that worked in version 2? Worse, why wasn't that restored in version 3.2 or 3.3?
Maybe I am way off base here - certainly wouldn't be first time! What is most important to me: is there a way to modify a compose file to allow a docker stack deploy command (in a Docker Swarm) to provide control of the gateway and subnets used?
Finally figured this out and I am posting what I did in the hopes that it might help someone else. While I did not know this when I started, what I really wanted [needed? :) ] to do was to redefine the default settings of the docker_gwbridge network.
This is how I did that:
docker swarm init # I am assuming this was already done, this creates the network with default settings
docker swarm leave -f # only if you did an 'init'
docker network ls # just to see the docker_gwbridge network
docker network rm docker_gwbridge
# if you never created/initialized a swarm, you can start here
SUBNET=172.19.0.0/16 # my defaults were always 172.18, using 19 only to test that this works
GATEWAY=172.19.0.1
docker network create --subnet=$SUBNET --gateway $GATEWAY \
-o com.docker.network.bridge.name=docker_gwbridge \
-o com.docker.network.bridge.enable_icc=false \
-o com.docker.network.bridge.enable_ip_masquerade=true \
docker_gwbridge
docker swarm init # now start the swarm
docker network inspect docker_gwbridge # if you want to see your changes
docker stack deploy --compose-file yourFile.yml YOURSTACKNAME
Now all your containers start on the subnet you defined as well as using the gateway you specified.
Configuration of a network within compose v3 is:
networks:
my_network:
driver: overlay
ipam:
driver: default
config:
-
subnet: 172.28.0.0/16
You can then assign your containers to this network and specify the IP
services
my_service:
networks:
my_network:
ipv4_address: 172.28.0.100
For already defined networks, use:
networks:
default:
external:
name: my-pre-existing-network
Related
I'm setting up a docker swarm deployment across two hosts: one linux and one windows. For some reason my containers cannot see (eg. ping) each other when they are deployed on different hosts. I have tried using plain wsl2 docker and docker via docker desktop with wsl2 as the backend. However, if I use two linux hosts (instead of one being windows), my containers can see each other without problems.
I set up my network like this:
networks:
mtmsnetwork:
ipam:
config:
- subnet: 172.30.0.0/16
And then I add both of my services to this network:
networks:
mtmsnetwork:
Is there some additional configuration I should make?
For testing our escrow build, I'm attempting to set up a docker network that's isolated from the host and from the outside world.
I've got the following docker-compose.yml (inspired by this forum post):
version: '3'
services:
redis:
image: "redis:2.8.23"
networks:
- isolated
# ... more services (TODO)
networks:
isolated:
driver: overlay
internal: true
When I run docker-compose up -d; it creates the network, but then fails to create the containers, reporting the following:
ERROR: This node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again.
But I'm not using docker swarm, nor do I want to.
If I remove the services: stanza from the file, it brings up the network without the error. It warns that the network is unused (obviously).
If I remove the services/redis/networks stanza, it brings up the container correctly.
What am I doing wrong?
I found this answer, which uses driver: bridge for the network, but that still allows access to the host.
Docker version 18.09.3, build 774a1f4
docker-compose version 1.21.2, build a133471
You have specified the network driver to be overlay.
The overlay network driver very much depends on swarm mode and can effectively be considered to be a swarm mode component.
Instead, you should choose a driver that is a local scope driver rather than a swarm scope driver.
The driver you should use is the bridge driver. The bridge network driver is not part of swarm mode and does not depend on swarm mode being active to utilize it.
Since you are using docker-compose, you can just leave the specific driver out entirely, and it will choose the appropriate driver for you. I would recommend removing the driver: overlay line out completely and leaving the rest of the file as-is:
version: '3'
services:
redis:
image: "redis:2.8.23"
networks:
- isolated
# ... more services (TODO)
networks:
isolated:
internal: true
I learned from docker documentation that I can not use docker DNS to find containers using their hostnames without utilizing user-defined bridge network. I created one using the command:
docker network create --driver=overlay --subnet=172.22.0.0/16 --gateway=172.22.0.1 user_defined_overlay
and tried to deploy a container that uses it. compose file looks like:
version: "3.0"
services:
web1:
image: "test"
ports:
- "12023:22"
hostname: "mytest-web1"
networks:
- test
web2:
image: "test"
ports:
- "12024:22"
hostname: "mytest-web2"
networks:
- test
networks:
test:
external:
name: user_defined_overlay
my docker version is: Docker version 17.06.2-ce, build cec0b72
and I got the following error when I tried deploying the stack:
network "user_defined_bridge" is declared as external, but it is not in the right scope: "local" instead of "swarm"
I was able to create an overlay network and define it in compose file. that worked fine but it didn't for bridge.
result of docker network ls:
NETWORK ID NAME DRIVER SCOPE
cd6c1e05fca1 bridge bridge local
f0df22fb157a docker_gwbridge bridge local
786416ba8d7f host host local
cuhjxyi98x15 ingress overlay swarm
531b858419ba none null local
15f7e38081eb user_defined_overlay overlay swarm
UPDATE
I tried creating two containers running on two different swarm nodes(1st container runs on manager while second runs on worker node) and I specified the user-defined overlay network as shown in stack above. I tried pinging mytest-web2 container from within mytest-web1 container using hostname but I got unknown host mytest-web2
As of 17.06, you can create node local networks with a swarm scope. Do so with the --scope=swarm option, e.g.:
docker network create --scope=swarm --driver=bridge \
--subnet=172.22.0.0/16 --gateway=172.22.0.1 user_defined_bridge
Then you can use this network with services and stacks defined in swarm mode. For more details, you can see PR #32981.
Edit: you appear to have significantly overcomplicated your problem. As long as everything is being done in a single compose file, there's no need to define the network as external. There is a requirement to use an overlay network if you want to communicate container-to-container. DNS discovery is included on bridge and overlay networks with the exception of the default "bridge" network that docker creates. With a compose file, you would never use this network without explicitly configuring it as an external network with that name. So to get container to container networking to work, you can let docker-compose or docker stack deploy create the network for your project/stack automatically with:
version: "3.0"
services:
web1:
image: "test"
ports:
- "12023:22"
web2:
image: "test"
ports:
- "12024:22"
Note that I have also removed the "hostname" setting. It's not needed for DNS resolution. You can communicate directly with a service VIP with the name "web1" or "web2" from either of these containers.
With docker-compose it will create a default bridge network. Swarm mode will create an overlay network. These defaults are ideal to allow DNS discovery and container-to-container communication in each of the scenarios.
The overlay network is the network to be used in swarm. Swarm is meant to be used to manage containers on multiple hosts and overlay networks are docker's multi-host networks https://docs.docker.com/engine/userguide/networking/get-started-overlay/
I tried to setup an nginx-proxy container to access my other containers via subdomains on port 80 instead of special ports. As you can guess, I could not get it to work.
I'm kind of new to docker itself and found that it's more comfortable for me to write docker-compose.yml files so I don't have to constantly write long docker run ... commands. I thought there's no difference in how you start the containers, either with docker or docker-compose. However, one difference I noticed is that starting the container with docker does not create any new networks, but with docker-compose there will be a xxx_default network afterwards.
I read that containers on different networks cannot access each other and maybe that might be the reason why the nginx-proxy is not forwarding the requests to the other containers. However, I was unable to find a way to configure my docker-compose.yml file to not create any new networks, but instead join the default bridge network like docker run does.
I tried the following, but it resulted in an error saying that I cannot join system networks like this:
networks:
default:
external:
name: bridge
I also tried network_mode: bridge, but that didn't seem to make any difference.
How do I have to write the docker-compose.yml file to not create a new network, or is that not possible at all?
Bonus question: Are there any other differences between docker and docker-compose that I should know of?
Adding network_mode: bridge to each service in your docker-compose.yml will stop compose from creating a network.
If any service is not configured with this bridge (or host), a network will be created.
Tested and confirmed with:
version: "2.1"
services:
app:
image: ubuntu:latest
network_mode: bridge
I've following coder-compose configuration:
version: '2'
services:
nginx:
build: ./nginx
links:
- tomcat1:tomcat1
- tomcat2:tomcat2
- tomcat3:tomcat3
ports:
- "80:80"
tomcat1:
build: ./tomcat
ports:
- "8080"
tomcat2:
build: ./tomcat
ports:
- "8080"
tomcat3:
build: ./tomcat
ports:
- "8080"
So, the question is, how to get access to the host network from the linked container(s):tomcat1, tomcat2, tomcat3. Here is the diagram:
Update
Seems, my diagram doesn't help much. Nginx is a load balancer, Tomcat 1-3 are application nodes. Deployed web. app needs to get access to internet resource.
Internet access is by default active on all containers (in bridge mode). All you need to check is if the http(s)_proxy variables are set if you are behind a proxy.
If your question if how to access docker host from a container (and not the reverse: access a container from the local docker host), then you would need to inspect the routing table of a container: see "From inside of a Docker container, how do I connect to the localhost of the machine?"
export DOCKER_HOST_IP=$(route -n | awk '/UG[ \t]/{print $2}')
There is a recent (June 2016) effort to add a adding a dockerhost as an entry in /etc/hosts of all running containers: issue 23177.
Update March 2020: this issue has been closed, and redirect to PR 40007: "Support host.docker.internal in dockerd on Linux"
This PR allows containers to connect to Linux hosts by appending a special string "host-gateway" to --add-host e.g. "--add-host=host.docker.internal:host-gateway" which adds host.docker.internal DNS entry in /etc/hosts and maps it to host-gateway-ip
This PR also add a daemon flag call host-gateway-ip which defaults to
the default bridge IP
Docker Desktop will need to set this field to the Host Proxy IP so DNS requests for host.docker.internal can be routed to VPNkit
This will be in Docker for Linux (and Docker Desktop, which runs the Linux daemon, although inside a lightweight VM).
Difference between this and the current implementation on Docker Desktop is that;
the current Docker Desktop implementation is in a part of the code-base that's proprietary (i.e., part of how Docker Desktop is configured internally)
this code could be used by the Docker Desktop team in future as well (to be discussed)
this PR does not set up the "magic" host.docker.internal automatically on every container, but it can be used to run a container that needs this host by adding docker run --add-host host.docker.internal:host-gateway
(to be discussed); setting that "magic" domain automatically on containers that are started could be implemented by adding an option for this in the ~/.docker/config.json CLI configuration file.