docker-compose hostname to communicate between containers works with postgres but not app - docker

I have the following docker-compose.yml:
services:
postgres:
image: "postgres:11.0-alpine"
app:
build: .
ports:
- "4000:4000"
depends_on:
- postgres
- nuxt
nuxt:
image: node:latest
ports:
- "3000:3000"
I need nuxt service to communicate with app.
Within the nuxt service (docker-compose run --rm --service-ports nuxt bash), if I run
root#62cafc299e8a:/app# ping postgres
PING postgres (172.18.0.2) 56(84) bytes of data.
64 bytes from avril_postgres_1.avril_default (172.18.0.2): icmp_seq=1 ttl=64 time=0.283 ms
64 bytes from avril_postgres_1.avril_default (172.18.0.2): icmp_seq=2 ttl=64 time=0.130 ms
64 bytes from avril_postgres_1.avril_default (172.18.0.2): icmp_seq=3 ttl=64 time=0.103 ms
but if I do:
root#62cafc299e8a:/app# ping app
ping: app: No address associated with hostname
Why does it work for postgres but not with app?
If I do docker network inspect 4fcb63b4b1c9, they appear to all be on the same network:
[
{
"Name": "myapp_default",
"Id": "4fcb63b4b1c9fe37ebb26e9d4d22c359c9d5ed6153bd390b6f0b63ffeb0d5c37",
"Created": "2019-05-16T16:46:27.820758377+02:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.18.0.0/16",
"Gateway": "172.18.0.1"
}
]
},
"Internal": false,
"Attachable": true,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"53b726bdd01159b5f18e8dcb858e979e6e2f8ef68c62e049b824899a74b186c3": {
"Name": "myapp_app_run_c82e91ca4ba0",
"EndpointID": "b535b6ca855a5dea19060b2f7c1bd82247b94740d4699eff1c8669c5b0677f78",
"MacAddress": "02:42:ac:12:00:03",
"IPv4Address": "172.18.0.3/16",
"IPv6Address": ""
},
"62cafc299e8a90fd39530bbe4a6af8b86098405e54e4c9e61128539ffd5ba928": {
"Name": "myapp_nuxt_run_3fb01bb2f778",
"EndpointID": "7eb8f5f8798baee4d65cbbfe5f0f5372790374b48f599f32490700198fa6d54c",
"MacAddress": "02:42:ac:12:00:04",
"IPv4Address": "172.18.0.4/16",
"IPv6Address": ""
},
"9dc1c848b2e347876292650c312e8aaf3f469f2efa96710fb50d033b797124b4": {
"Name": "myapp_postgres_1",
"EndpointID": "a925438ad5644c03731b7f7c926cff095709b2689fd5f404e9ac4e04c2fbc26a",
"MacAddress": "02:42:ac:12:00:02",
"IPv4Address": "172.18.0.2/16",
"IPv6Address": ""
}
},
"Options": {},
"Labels": {
"com.docker.compose.network": "default",
"com.docker.compose.project": "myapp",
"com.docker.compose.version": "1.23.2"
}
}
]
So why is that? Also tried with aliases, without success. :(

Your app container is most likely not running. Its appearance in docker network inspect means that the container exists but it may be exited (i.e. is not running). You can check with docker ps -a, for example:
$ docker ps -a
CONTAINER ID ... STATUS ... NAMES
fe908e014fdd Exited (0) Less than a second ago so_app_1
3b2ca418c051 Up 2 minutes so_postgres_1
container app exists but is not running: you won't be able to ping it even if it exists in the network
container postgres exists and is running: you will be able to ping it
It's probably due to the fact that docker-compose run --rm --service-ports nuxt bash will only create and run the nuxt container, it won't run app nor postgres. You are able to ping postgres because it was already running before you used docker-compose run nuxt bash
To be able to ping other containers after running docker-compose run nuxt ..., you should either:
Have the other containers already running before (such as by using docker-compose up -d)
Have the other containers depends_on the container you are trying to run, for example:
nuxt:
image: node:latest
ports:
- "3000:3000"
# this will ensure posgres and app are run as well when using docker-compose run
depends_on:
- app
- nuxt
Even with that, your container may fail to start (or exit right after start) and you won't be able to ping it. Check with docker ps -a that it is running and docker logs to see why it may have exited.

As #Pierre said, most probably your container is not running.
From below docker-compose from your question, it seems you are not doing anything in that container such as running a server or uwsgi to keep it alive.
app:
build: .
ports:
- "4000:4000"
depends_on:
- postgres
- nuxt
To keep it running in docker compose, add command directive like below.
app:
build: .
command: tail -f /dev/null #trick to stop immediate exit and keep the container alive.
ports:
- "4000:4000"
depends_on:
- postgres
- nuxt
It should be 'pingable' container now.
If you wish to run via docker run, use -t, which creates a psuedo-tty
docker run -t -d <image> <command>

Related

connect from inside a docker container to IP address on host network

Question: (the short version)
When using Docker for application development, how do I configure a Docker-compose file to let me access the IP address of a server on the host network from inside the docker container? I don't want to access the host itself -- but instead want to access another server on the same network as the host. I also need to have various docker containers be able to talk to each other.
What is the cleanest way to allow access to host-network IPv4 resources from inside of a docker container and still allow inter-container communication?
All the background and details are below (aka the long version).
Setup:
I'm writing an application that polls a Modbus server to collect measured data at a given interval. The Modbus server is at 192.168.1.50 port 502 on my local network. I can successfully ping that server from my computer.
Here's my development approach:
application is inside a docker container
developing in a Mac environment
using Django-3.1/postgres to build the UI and store the data (for now)
using the pymodbus library to manage communication between the application and the remote Modbus server
Here's the Docker-compose file that creates the application environment:
version: '3.8'
services:
db:
container_name: db
image: postgres:10.7
environment:
POSTGRES_PASSWORD: pwd
POSTGRES_DB: app_db
volumes:
- ./data/postgres:/var/lib/postgresql/data
ports:
- 5432:5432
web:
container_name: web
build:
context: ../.
dockerfile: ./_app/dev/Dockerfile
volumes:
- ../.:/app
ports:
- 8000:8000
depends_on:
- db
env_file:
- app.env
command: ./manage.py runserver 0.0.0.0:8000
And here's the Dockerfile:
FROM python:3.8.5-buster
RUN mkdir /app
WORKDIR /app
RUN apt-get update -y
RUN apt-get install inetutils-traceroute -y
COPY ./_app/dev/python_reqs.txt /app/python_reqs.txt
RUN pip install --upgrade pip
RUN pip install -r python_reqs.txt
# Install wait-for-it
COPY ./_app/wait-for-it.sh /usr/local/bin/
RUN chmod u+x /usr/local/bin/wait-for-it.sh
# Configure custom entrypoint to wait for postgres and run webserver
COPY ./_app/dev/custom-entrypoint /usr/local/bin/
RUN chmod u+x /usr/local/bin/custom-entrypoint
ENTRYPOINT ["custom-entrypoint"]
EXPOSE 8000
Problem:
From inside the 'web' docker container I cannot access the Modbus server on the host LAN. I cannot ping its IP address (192.168.1.50).
traceroute 192.168.1.50 provides no useful info. It just fails.
When I run docker-compose up a docker network called '_app_default' is created. Here's what I get when I run docker network inspect _app_default:
[
{
"Name": "_app_default",
"Id": "59f0836c2f3017c537f973a38ab3a55ad96e2ed737c4ac111fc0e911fa0c8a67",
"Created": "2020-09-13T18:51:14.6395366Z",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "192.168.112.0/20",
"Gateway": "192.168.112.1"
}
]
},
"Internal": false,
"Attachable": true,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"28af77ef2d6f99812cb392c8f9eca045b150256c464befc3bb249c9de9e653c1": {
"Name": "db",
"EndpointID": "d657f2f29699ada859447c919ad2c94195a6e9a7ae7eeb35989560d2717183c5",
"MacAddress": "02:42:c0:a8:70:02",
"IPv4Address": "192.168.112.2/20",
"IPv6Address": ""
},
"a8a619d664a27286e276614e549514dff2c15c5c3c44c39e127fec54ec2b5c6b": {
"Name": "web",
"EndpointID": "8f1661c6fa24104a70171d1f830e1fe34ed8d89bacd55c9b9d05dc62f64112c0",
"MacAddress": "02:42:c0:a8:70:03",
"IPv4Address": "192.168.112.3/20",
"IPv6Address": ""
}
},
"Options": {},
"Labels": {
"com.docker.compose.network": "default",
"com.docker.compose.project": "_app",
"com.docker.compose.version": "1.27.0"
}
}
]
What I Already Tried:
I tried using network_mode: "host" in the 'web' service definition. That did not help.
I did my best to read through the Docker networking documentation but I can't find a straightforward solution to this situation and I get all turned around -- I'm unfortunately not good with networking topics -- yet :) . Do I need an 'overlay' network? Or a 'macvlan'? Help!
Any assistance that you StackOverflow superstars can send would be greatly appreciated. Thank you!!
-Allan
It looks like you have overlapping ip ranges of docker network and local network.
To solve this you need to override docker network address pool e.g.
edit docker daemon config
$ cat ~/.docker/daemon.json
{
"debug" : true,
"default-address-pools" : [
{
"base" : "172.31.0.0/16",
"size" : 24
}
]
}

container running on docker swarm not accessible from outside

I am running my containers on the docker swarm. asset-frontend service is my frontend application which is running Nginx inside the container and exposing port 80. now if I do
curl http://10.255.8.21:80
or
curl http://127.0.0.1:80
from my host where I am running these containers I am able to see my asset-frontend application but it is not accessible outside of the host. I am not able to access it from another machine, my host machine operating system is centos 8.
this is my docker-compose file
version: "3.3"
networks:
basic:
services:
asset-backend:
image: asset/asset-management-backend
env_file: .env
deploy:
replicas: 1
depends_on:
- asset-mongodb
- asset-postgres
networks:
- basic
asset-mongodb:
image: mongo
restart: always
env_file: .env
ports:
- "27017:27017"
volumes:
- $HOME/asset/mongodb:/data/db
networks:
- basic
asset-postgres:
image: asset/postgresql
restart: always
env_file: .env
ports:
- "5432:5432"
environment:
- POSTGRES_USER=postgres
- POSTGRES_PASSWORD=password
- POSTGRES_DB=asset-management
volumes:
- $HOME/asset/postgres:/var/lib/postgresql/data
networks:
- basic
asset-frontend:
image: asset/asset-management-frontend
restart: always
ports:
- "80:80"
environment:
- ENV=dev
depends_on:
- asset-backend
deploy:
replicas: 1
networks:
- basic
asset-autodiscovery-cron:
image: asset/auto-discovery-cron
restart: always
env_file: .env
deploy:
replicas: 1
depends_on:
- asset-mongodb
- asset-postgres
networks:
- basic
this is my docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
auz640zl60bx asset_asset-autodiscovery-cron replicated 1/1 asset/auto-discovery-cron:latest
g6poofhvmoal asset_asset-backend replicated 1/1 asset/asset-management-backend:latest
brhq4g4mz7cf asset_asset-frontend replicated 1/1 asset/asset-management-frontend:latest *:80->80/tcp
rmkncnsm2pjn asset_asset-mongodb replicated 1/1 mongo:latest *:27017->27017/tcp
rmlmdpa5fz69 asset_asset-postgres replicated 1/1 asset/postgresql:latest *:5432->5432/tcp
My 80 port is open in firewall
following is the output of firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: eth0
sources:
services: cockpit dhcpv6-client ssh
ports: 22/tcp 2376/tcp 2377/tcp 7946/tcp 7946/udp 4789/udp 80/tcp
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
if i inspect my created network the output is following
[
{
"Name": "asset_basic",
"Id": "zw73vr9xigfx7hy16u1myw5gc",
"Created": "2019-11-26T02:36:38.241352385-05:00",
"Scope": "swarm",
"Driver": "overlay",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "10.0.3.0/24",
"Gateway": "10.0.3.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"9348f4fc6bfc1b14b84570e205c88a67aba46f295a5e61bda301fdb3e55f3576": {
"Name": "asset_asset-frontend.1.zew1obp21ozmg8r1tzmi5h8g8",
"EndpointID": "27624fe2a7b282cef1762c4328ce0239dc70ebccba8e00d7a61595a7a1da2066",
"MacAddress": "02:42:0a:00:03:08",
"IPv4Address": "10.0.3.8/24",
"IPv6Address": ""
},
"943895f12de86d85fd03d0ce77567ef88555cf4766fa50b2a8088e220fe1eafe": {
"Name": "asset_asset-mongodb.1.ygswft1l34o5vfaxbzmnf0hrr",
"EndpointID": "98fd1ce6e16ade2b165b11c8f2875a0bdd3bc326c807ba6a1eb3c92f4417feed",
"MacAddress": "02:42:0a:00:03:04",
"IPv4Address": "10.0.3.4/24",
"IPv6Address": ""
},
"afab468aefab0689aa3488ee7f85dbc2cebe0202669ab4a58d570c12ee2bde21": {
"Name": "asset_asset-autodiscovery-cron.1.5k23u87w7224mpuasiyakgbdx",
"EndpointID": "d3d4c303e1bc665969ad9e4c9672e65a625fb71ed76e2423dca444a89779e4ee",
"MacAddress": "02:42:0a:00:03:0a",
"IPv4Address": "10.0.3.10/24",
"IPv6Address": ""
},
"f0a768e5cb2f1f700ee39d94e380aeb4bab5fe477bd136fd0abfa776917e90c1": {
"Name": "asset_asset-backend.1.8ql9t3qqt512etekjuntkft4q",
"EndpointID": "41587022c339023f15c57a5efc5e5adf6e57dc173286753216f90a976741d292",
"MacAddress": "02:42:0a:00:03:0c",
"IPv4Address": "10.0.3.12/24",
"IPv6Address": ""
},
"f577c539bbc3c06a501612d747f0d28d8a7994b843c6a37e18eeccb77717539e": {
"Name": "asset_asset-postgres.1.ynrqbzvba9kvfdkek3hurs7hl",
"EndpointID": "272d642a9e20e45f661ba01e8731f5256cef87898de7976f19577e16082c5854",
"MacAddress": "02:42:0a:00:03:06",
"IPv4Address": "10.0.3.6/24",
"IPv6Address": ""
},
"lb-asset_basic": {
"Name": "asset_basic-endpoint",
"EndpointID": "142373fd9c0d56d5a633b640d1ec9e4248bac22fa383ba2f754c1ff567a3502e",
"MacAddress": "02:42:0a:00:03:02",
"IPv4Address": "10.0.3.2/24",
"IPv6Address": ""
}
},
"Options": {
"com.docker.network.driver.overlay.vxlanid_list": "4100"
},
"Labels": {
"com.docker.stack.namespace": "asset"
},
"Peers": [
{
"Name": "8170c4487a4b",
"IP": "10.255.8.21"
}
]
}
]
Ran into this same issue and it turns out it was a clash between my local networks subnet and the subnet of the automatically created ingress network. This can be verified using docker network inspect ingress and checking if the IPAM.Config.Subnet value overlaps with your local network.
To fix you can update the configuration of the ingress network as specified in Customize the default ingress network; in summary:
Remove services that publish ports
Remove existing network: docker network rm ingress
Recreate using non-conflicting subnet:
docker network create \
--driver overlay \
--ingress \
--subnet 172.16.0.0/16 \ # Or whatever other subnet you want to use
--gateway 172.16.0.1 \
ingress
Restart services
You can avoid a clash to begin with by specifying the default subnet pool when initializing the swarm using the --default-addr-pool option.
docker service update your-service --publish-add 80:80
You can publish ports by updating the service.
Can you try this url instead of the ip adres? host.docker.internal so something like http://host.docker.internal:80
I suggest you verify the "right" behavior using docker-compose first. Then, try to use docker swarm without network specification just to verify there are no network interface problems.
Also, you could use the below command to verify your LISTEN ports:
netstat -tulpn
EDIT: I faced this same issue but I was able to access my services through 127.0.0.1
While running docker provide an port mapping, like
docker run -p 8081:8081 your-docker-image
Or, provide the port mapping in the docker desktop while starting the container.
I got into this same issue. It turns out that's my iptables filter causes external connections not work.
In docker swarm mode, docker create a virtual network bridge device docker_gwbridge to access to overlap network. My iptables has following line to drop packet forwards:
:FORWARD DROP
That makes network packets from physical NIC can't reach the docker ingress network, so that my docker service only works on localhost.
Change iptables rule to
:FORWARD ACCEPT
And problem solved without touching the docker.

How to configure containers in one network to connect to each other (server -> mysql)?

I have ran ubuntu docker-containers (mysql) and (nodejs server app) on windows
docker run -d --network bridge --name own -p 80:3000 own:latest
docker run -d --name mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=12345678 mysql:5
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
3ce966e43414 own:latest "docker-entrypoint.s…" 5 minutes ago Up 5 minutes 0.0.0.0:80->3000/tcp own
ed10cfc93dd5 mysql:5 "docker-entrypoint.s…" 20 minutes ago Up 20 minutes 0.0.0.0:3306->3306/tcp, 33060/tcp mysql
When i open port localhost:3000 with server app just via cmd (NOT via docker VM) all is good, I see success connection to the docker-container 0.0.0.0:3306, but when i:
docker start own
check browser 0.0.0.0:80 and i see Error: connect ECONNREFUSED 127.0.0.1:3306
docker network ls
NETWORK ID NAME DRIVER SCOPE
019f0886d253 bridge bridge local
fa1842bad14c host host local
85e7d1e38e14 none null local
docker inspect bridge
[
{
"Name": "bridge",
"Id": "019f0886d253091c1367863e38a199fe9b539a72ddb7575b26f40d0d1b1f78dc",
"Created": "2019-11-19T09:15:53.2096944Z",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.17.0.0/16",
"Gateway": "172.17.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"a79ec12c4cc908326c54abc2b47f80ffa3da31c5e735bf5ff2755f23b9d562dd": {
"Name": "own",
"EndpointID": "2afc225e29138ff9f1da0f557e9f7659d3c4ccaeb5bfaa578df88a672dac003f",
"MacAddress": "02:42:ac:11:00:02",
"IPv4Address": "172.17.0.2/16",
"IPv6Address": ""
},
"ed10cfc93dd5eda7cfb8a26e5e4b2a8ccb4e9db7a4957b3d1048cb93f5137fd4": {
"Name": "mysql",
"EndpointID": "ea23d009f959d954269c0554cecf37d01f8fe71481965077f1372df27f05208a",
"MacAddress": "02:42:ac:11:00:03",
"IPv4Address": "172.17.0.3/16",
"IPv6Address": ""
}
},
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
},
"Labels": {}
}
]
maybe could i somehow assign the own container to the bridge network like mysql. After localhost of the mysql container will be seen for own container? Help please what should i do?
#create network mynetwork
docker network create --subnet 172.17.0.0/16 mynetwork
#create own container (without starting it)
docker create -d --name own -p 80:3000 own:latest
#add own container to the network mynetwork
docker network connect --ip 172.17.0.2 mynetwork own
#start container own
docker start own
#same as above but with different ip
docker create -d --name mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=12345678 mysql:5
docker network connect --ip 172.17.0.3 mynetwork mysql
docker start mysql
when you stop and remove your containers do, you may remove network this way:
docker network rm mynetwork
or if you don't do it then there is no need to create it again as above but just connect your new/other containers to it.
In your application you should use 172.17.0.3 as the MySQL address.

Two services cannot see each other through a swarm overlay

I feel like this is simple, but I can't figure it out. I have two services, consul and traefik up in a single node swarm on the same host.
> docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
3g1obv9l7a9q consul_consul replicated 1/1 progrium/consul:latest
ogdnlfe1v8qx proxy_proxy global 1/1 traefik:alpine *:80->80/tcp, *:443->443/tcp
> docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
090f1ed90972 progrium/consul:latest "/bin/start -server …" 12 minutes ago Up 12 minutes 53/tcp, 53/udp, 8300-8302/tcp, 8400/tcp, 8500/tcp, 8301-8302/udp consul_consul.1.o0j8kijns4lag6odmwkvikexv
20f03023d511 traefik:alpine "/entrypoint.sh -c /…" 12 minutes ago Up 12 minutes 80/tcp
Both containers have access to the "consul" overlay network, which was created as such.
> docker network create --driver overlay --attachable consul
ypdmdyx2ulqt8l8glejfn2t25
Traefik is complaining that it can't reach consul.
time="2019-03-18T18:58:08Z" level=error msg="Load config error: Get http://consul:8500/v1/kv/traefik?consistent=&recurse=&wait=30000ms: dial tcp 10.0.2.2:8500: connect: connection refused, retrying in 7.492175404s"
I can go into the traefik container and confirm that I can't reach consul through the overlay network, although it is pingable.
> docker exec -it 20f03023d511 ash
/ # nslookup consul
Name: consul
Address 1: 10.0.2.2
/ # curl consul:8500
curl: (7) Failed to connect to consul port 8500: Connection refused
# ping consul
PING consul (10.0.2.2): 56 data bytes
64 bytes from 10.0.2.2: seq=0 ttl=64 time=0.085 ms
However, if I look a little deeper, I find that they are connected, just that the overlay network isn't transmitting traffic to the actual destination for some reason. If I go directly to the actual consul ip, it works.
/ # nslookup tasks.consul
Name: tasks.consul
Address 1: 10.0.2.3 0327c8e1bdd7.consul
/ # curl tasks.consul:8500
Moved Permanently.
I could workaround this, technically there will only ever be one copy of consul running, but I'd like to know why the data isn't routing in the first place before I get deeper into it. I can't think of anything else to try. Here is various information related to this setup.
> docker --version
Docker version 18.09.2, build 6247962
> docker network ls
NETWORK ID NAME DRIVER SCOPE
cee3cdfe1194 bridge bridge local
ypdmdyx2ulqt consul overlay swarm
5469e4538c2d docker_gwbridge bridge local
5fd928ea1e31 host host local
9v22k03pg9sl ingress overlay swarm
> docker network inspect consul
[
{
"Name": "consul",
"Id": "ypdmdyx2ulqt8l8glejfn2t25",
"Created": "2019-03-18T14:44:27.213690506-04:00",
"Scope": "swarm",
"Driver": "overlay",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "10.0.2.0/24",
"Gateway": "10.0.2.1"
}
]
},
"Internal": false,
"Attachable": true,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"0327c8e1bdd7ebb5a7871d16cf12df03240996f9e590509984783715a4c09193": {
"Name": "consul_consul.1.8v4bshotrco8fv3sclwx61106",
"EndpointID": "ae9d5ef1d19b67e297ebf40f6db410c33e4e3c0266c56e539e696be3ed4c81a5",
"MacAddress": "02:42:0a:00:02:03",
"IPv4Address": "10.0.2.3/24",
"IPv6Address": ""
},
"c21f5dfa93a2f43b747aedc64a343d94d6c1c2e6558d81bd4a52e2ba4b5fa90f": {
"Name": "proxy_proxy.sb6oindhmfukq4gcne6ynb2o2.4zvco02we58i3ulbyrsw1b2ok",
"EndpointID": "7596a208e0b05ba688f318814e24a2a1a3401765ed53ca421bf61c73e65c235a",
"MacAddress": "02:42:0a:00:02:06",
"IPv4Address": "10.0.2.6/24",
"IPv6Address": ""
},
"lb-consul": {
"Name": "consul-endpoint",
"EndpointID": "23e74716ef54f3fb6537b305176b790b4bc4132dda55f20588d7ce4ca71d7372",
"MacAddress": "02:42:0a:00:02:04",
"IPv4Address": "10.0.2.4/24",
"IPv6Address": ""
}
},
"Options": {
"com.docker.network.driver.overlay.vxlanid_list": "4099"
},
"Labels": {},
"Peers": [
{
"Name": "e11b9bd30b31",
"IP": "10.8.0.1"
}
]
}
]
> cat consul/docker-compose.yml
version: '3.1'
services:
consul:
image: progrium/consul
command: -server -bootstrap
networks:
- consul
volumes:
- consul:/data
deploy:
labels:
- "traefik.enable=false"
networks:
consul:
external: true
> cat proxy/docker-compose.yml
version: '3.3'
services:
proxy:
image: traefik:alpine
command: -c /traefik.toml
networks:
# We need an external proxy network and the consul network
# - proxy
- consul
ports:
# Send HTTP and HTTPS traffic to the proxy service
- 80:80
- 443:443
configs:
- traefik.toml
volumes:
- /var/run/docker.sock:/var/run/docker.sock
deploy:
# Deploy the service to all nodes that match our constraints
mode: global
placement:
constraints:
- "node.role==manager"
- "node.labels.proxy==true"
labels:
# Traefik uses labels to configure routing to your services
# Change the domain to your own
- "traefik.frontend.rule=Host:proxy.mcwebsite.net"
# Route traffic to the web interface hosted on port 8080 in the container
- "traefik.port=8080"
# Name the backend (not required here)
- "traefik.backend=traefik"
# Manually set entrypoints (not required here)
- "traefik.frontend.entryPoints=http,https"
configs:
# Traefik configuration file
traefik.toml:
file: ./traefik.toml
# This service will be using two external networks
networks:
# proxy:
# external: true
consul:
external: true
There were two optional kernel configs CONFIG_IP_VS_PROTO_TCP and CONFIG_IP_VS_PROTO_UDP disabled in my kernel which, you guessed it, enable tcp and udp load balancing.
I wish I'd checked that about four hours sooner than I did.

host name not working with docker swarm mode

I am using docker version 18.06.1-ce and compose version 1.22.0.
As per docker, it should be possible to call services using service names. This is working for me with docker compose without swarm mode, but on swarm mode it is not working. I have even tried setting aliases in my compose but no result.
Below is my docker-compose.yml
version: "3"
networks:
my_network:
external:
name: new_network
services:
config-service:
image: com.test/config-service:0.0.1
deploy:
placement:
constraints: [node.role == manager]
resources:
limits:
memory: 1024M
reservations:
memory: 768M
restart_policy:
condition: on-failure
healthcheck:
test: ["CMD", "curl", "-f", "http://config-service:8888/health"]
interval: 5s
timeout: 3s
retries: 5
ports:
- 8888:8888
networks:
my_network:
aliases:
- config-service
eureka-service:
image: com.test/eureka-service:0.0.1
deploy:
placement:
constraints: [node.role == manager]
resources:
limits:
memory: 1536M
reservations:
memory: 1024M
restart_policy:
condition: on-failure
healthcheck:
test: ["CMD", "curl", "-I", "http://eureka-service:8761/health"]
interval: 5s
timeout: 3s
retries: 5
ports:
- 8761:8761
depends_on:
- config-service
networks:
my_network:
aliases:
- eureka-service
When I inspect into my network I found
[
{
"Name": "new_network",
"Id": "s2m7yq7tz4996w7eg229l59nf",
"Created": "2018-08-30T13:58:59.75070753Z",
"Scope": "swarm",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.20.0.0/16",
"Gateway": "172.20.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"355efe27067ee20868455dabbedd859b354d50fb957dcef4262eac6f25d10686": {
"Name": "test_eureka-service.1.a4pjb3ntez9ly5zhu020h0tva",
"EndpointID": "50998abdb4cd2cd2f747fadd82be495150919531b81a3d6fb07251a940ef2749",
"MacAddress": "02:42:ac:14:00:02",
"IPv4Address": "172.20.0.2/16",
"IPv6Address": ""
},
"5cdb398c598c1cea6b9032d4c696fd1581e88f0644896edd958ef59895b698a4": {
"Name": "test_config-service.1.se8ajr73ajnjhvxt3rq31xzlm",
"EndpointID": "5b3c41a8df0054e1c115d93c32ca52220e2934b6f763f588452c38e60c067054",
"MacAddress": "02:42:ac:14:00:03",
"IPv4Address": "172.20.0.3/16",
"IPv6Address": ""
}
},
"Options": {},
"Labels": {}
}
]
Now if I connect into containers terminal and ping using the long name 'test_config-service.1.se8ajr73ajnjhvxt3rq31xzlm' it is able to ping but not 'config-service'.
I believe the issue you are experiencing is because you are using a swarm scoped bridge network, instead of an overlay network. I'm not sure if this configuration is supported. The DNS entry for the service when deployed in swarm mode is at the service level, not the individual containers. From my testing, that DNS entry, along with the code to setup a VIP, only appear to work with overlay networks. You may want to follow this issue if you really need your network to be configured as a bridge: https://github.com/moby/moby/issues/37672
Otherwise, the easy fix is to replace your network with an overlay network. You can remove your network aliases since they are redundant. And if you have other containers on the host that need to also be on this network, from outside of swarm mode, be sure to configure your overlay network as "attachable". If you have other applications currently attached to the network, you can replace that with a new network, or if you need to keep the same network name, swap it out in two phases:
# create a temporary network to free up the new_network name
docker network create -d overlay --attachable temp_network
docker network connect temp_network $container_id # repeat for each container
# finish the above step for all containers before continuing
docker network disconnect new_network $container_id #repeat for each container
# remove the old bridge network
docker network rm new_network
# now create a new_network as overlay
docker network create -d overlay --attachable new_network
docker network connect new_network $container_id # repeat for each container
# finish the above step for all containers before continuing
docker network disconnect temp_network $container_id #repeat for each container
# cleanup the temporary network
docker network rm temp_network
If everything is running in swarm mode, then there's no need for --attachable. After that, you should be able to start your swarm mode stack.
Try to list your services with a docker service ls command. Because if you use stack and give a name to your stack the service name will be nameofstack_config-service
And I see in your inspect test_eureka-service.1xxxxxx so the service name should be test_eureka-service
This is a known issue with version 18.06:
https://github.com/docker/for-win/issues/2327
https://github.com/docker/for-linux/issues/375
Try 18.03

Resources