My case:
I have a container (container_A) on the default bridge network (172.17.0.1/16)
I have a group of containers -- created through docker-compose -- on another bridge (172.18.0.1/16). One of them is named container_B_1 (ip: 172.18.0.2)
By default, I cannot ping from container_A to container_B_1
The question: how to make that particular container (container_B_1) accessible as well from the default bridge network? In other words: to let it have 172.17.0.x IP (beside the 172.18.0.x IP). Just that one container.
I've tried this in my docker-compose.yml
But, gettting error: "Network-scoped alias is supported only for containers in user defined networks"
Thanks!
You could create your own network and specify it in your compose file:
Create your own network:
docker network create --driver bridge my_dev_network
you could verify by docker network ls
In your docker-compose.yml for the two containers (container A) and the other group of containers, specify the network you just created:
you could verify by docker network inspect my_dev_network to see if all the containers have joined your own network
To keep the same IP series, I was having the same issue, and found this solution.
Include
network_mode: bridge
under each service in your compose file.
This way you do not have to create a custom network.
Found the answer here: https://github.com/docker/compose/issues/3012
From ninchan8328 commented on May 16, 2016:
I figured out, i can have the docker-compose to start the container in a custom network and then do a docker network connect bridge [container] to join the default network that way.
Related
Here is my situation：
First，I run a MySQL container(IP:172.17.0.2) on centOS;
Then I run a Nacos contanier with specified datasource(MySQL above) on the same host, but i didn't use the ip of the MySQL container, instead I used the ip of the bridge Gateway(172.17.0.1)(two containers both link to the default bridge).
What surprised me was that Nacos works well, it can query config data from MySQL container normally.
How did this happen? I have read some documention but didn't get the answer.It really confused me.
On modern Docker installations, try to avoid using the default bridge network. docker network create a network (it doesn't need any special options, but it does need to be created) and then launch your containers on --net that network. If you're using Compose, it creates a ("user bridge") network named default for you.
On your CentOS host, if you run ifconfig, you should see a docker0 interface with the 172.17.0.1 address. When you launch a container with the docker run -p option, that container is accessible via the first port number on all host interfaces, including the docker0 interface.
Meanwhile, inside a container (on the default bridge network), it sees that same IP address as the normal IPv4 gateway address (try docker run --rm busybox route -n). So, when you connect to 172.17.0.1:3306, you're connecting out to the host, and then connecting to the published port of the database container.
This isn't a totally standard way to connect between containers, though it will work. You should prefer using Docker named networks, which will let you connect to another container using the container's name without manually doing any IP-address lookups. If you really can't move off of the default bridge network, then the standard approach is to --link to the other container, but this entire path is considered outdated.
Is there any way to make a docker container that is accessing to all docker networks at the same time ? The idea is that I have 2 docker networks.
Let's say that they are called demo1 and demo2.
I have another docker container (called Front) that should reach demo1 and demo2 at the same time.
I can do that by declaring external networks in my docker-compose file.
However, I want to be able to declare demo3 and attach the Front container to it "dynamically", without modifying the compose file of the container and if it's possible, without restarting it.
So, I am trying to find an architecture that makes my container Front connect to any added docker network dynamically.
I can create a script in a crontab, but the idea is to do it properly.
The need is to get a common container, which can reach any other container.
In a docker compose syntaxe, I image something like this:
networks:
all:
name: '*'
external: true
Is it possible ? How ?
Regards
I guess what you need is Connect a running container to a network:
Examples
Connect a running container to a network
$ docker network connect multi-host-network container1
Just find the new network name and connect your Front container to this network out of composefile.
I'm working on Docker container and I find it strange the default network prevent from communicate between container using the name,
thanks for any hint
Containers on the default bridge network can only access each other by IP addresses, unless you use the --link option, which is considered legacy. On a user-defined bridge network, containers can resolve each other by name or alias.
From official docker documentation
Technically, there is nothing stopping docker to resolve the container names on default bridge network. I think it is just a decision that is made by docker team to force users to create bridge networks consciously. So that they know what they are doing and securely use it for production.
I've had db and server container, both running in the same network. Can ping db host by its container id with no problem.
When I set a hostname for db container manually (-h myname), it had an effect ($ hostname returns set host), but I can't ping that hostname from another container in the same network. Container id still pingable.
Although it works with no problem in docker compose.
What am I missing?
Hostname is not used by docker's built in DNS service. It's a counterintuitive exception, but since hostnames can change outside of docker's control, it makes some sense. Docker's DNS will resolve:
the container id
container name
any network aliases you define for the container on that network
The easiest of these options is the last one which is automatically configured when running containers with a compose file. The service name itself is a network alias. This lets you scale and perform rolling updates without reconfiguring other containers.
You need to be on a user created network, not something like the default bridge which has DNS disabled. This is done by default when running containers with a compose file.
Avoid using links since they are deprecated. And I'd only recommend adding host entries for external static hosts that are not in any DNS, for container to container, or access to other hosts outside of docker, DNS is preferred.
I've found out, that problem can be solved without network using --add-host option. Container's IP can be gain using inspect command.
But when containers in the same network, they are able to access each other via it names.
As stated in the docker docs, if you start containers on the default bridge network, adding -h myname will add this information to
/etc/hosts
/etc/resolv.conf
and the bash prompt
of the container just started.
However, this will not have any effect to other independent containers. (You could use --link to add this information to /etc/hosts of other containers. However, --link is deprecated.)
On the other hand, when you create a user-defined bridge network, docker provides an embedded DNS server to make name lookups between containers on that network possible, see Embedded DNS server in user-defined networks. Name resolution takes the container names defined with --name. (You
will not find another container by using its --hostname value.)
The reason, why it works with docker-compose is, that docker-compose creates a custom network for you and automatically names the containers.
The situation seems to be a bit different, when you don't specify a name for the container yourself. The run reference says
If you do not assign a container name with the --name option, then the daemon generates a random string name for you. [...] If you specify a name, you can use it when referencing the container within a Docker network.
In agreement with your findings, this should be read as: If you don't specify a custom --name, you cannot use the auto-generated name to look up other containers on the same network.
I need to know the hostnames (or ip addresses) of some container running on the same machine.
As I already commented here (but with no answer yet), I use docker-compose. The documentation says, compose will automatically create a hostname entry for all container defined in the same docker-compose.yml file:
Each container for a service joins the default network and is both reachable by other containers on that network, and discoverable by them at a hostname identical to the container name.
But I can't see any host entry via docker exec -it my_container tail -20 /etc/hosts.
I also tried to add links to my container, but nothing changed.
Docker 1.10 introduced some new networking features which include an internal DNS server where host lookups are done.
On the default bridge network (docker0), lookups continue to function via /etc/hosts as they use to. /etc/resolv.conf will point to your hosts resolvers.
On a user defined network, Docker will use the internal DNS server. /etc/resolv.conf will have an internal IP address for the Docker DNS server. This setup allows bridge, custom and overlay networks to work in a similar fashion. So an overlay network on swarm will populate host data from across the swarm like a local bridge network would.
The "legacy" setup was maintained so the new networking features could be introduced without impacting existing setups.
Discovery
The DNS resolver is able to provide IP's for a docker compose service via the name of that service.
For example, with a web and db service defined, and the db service scaled to 3, all db instances will resolve:
$ docker-compose run --rm web nslookup db
Name: db
Address 1: 172.22.0.4 composenetworks_db_2.composenetworks_mynet
Address 2: 172.22.0.5 composenetworks_db_3.composenetworks_mynet
Address 3: 172.22.0.3 composenetworks_db_1.composenetworks_mynet