Containers on different swarm nodes can't reach eachother - docker

in short, I've got the problem that containers in a swarm can't reach containers that sit on another node. The worker node is in my home network, so not directly accessible externally.
Setup:
Manager node that is a publicly available server, let's give it the IP A.A.A.A
Worker node that is at home, behind a router, with the internal IP B.B.B.B and the router with public IP C.C.C.C
The worker can without a problem join the swarm, the manager can without problems allocate containers to that worker, so some sort of communication is established and working.
What is not working is, that containers on the manager can't reach containers on the worker and vice versa (but can reach containers on the same node)
docker node ls shows the worker node as Ready and Active. docker node inspect <NODE NAME> show the IP C.C.C.C under Status
minimal working example:
docker-compose
version: "3.8"
services:
manager1:
image: jwilder/whoami
hostname: manager1
deploy:
placement:
constraints:
- node.role == manager
manager2:
image: jwilder/whoami
hostname: manager2
deploy:
placement:
constraints:
- node.role == manager
worker1:
image: jwilder/whoami
hostname: worker1
deploy:
placement:
constraints:
- node.role == worker
worker2:
image: jwilder/whoami
hostname: worker2
deploy:
placement:
constraints:
- node.role == worker
deploying with docker stack deploy -c docker-compose.yml testing
docker network inspect testing_default -v on manager shows
"Peers": [
{
"Name": "f0de4150d01e",
"IP": "A.A.A.A"
}
],
"Services": {
"testing_manager1": {
"VIP": "10.0.25.5",
"Ports": [],
"LocalLBIndex": 21646,
"Tasks": [
{
"Name": "testing_manager1.1.w6b2wufu96vk1jmtez9dtewr0",
"EndpointID": "213b7182882e267f249edc52be57f6c56d83efafeba471639f2cbb9398854fe0",
"EndpointIP": "10.0.25.6",
"Info": {
"Host IP": "A.A.A.A"
}
}
]
},
"testing_manager2": {
"VIP": "10.0.25.8",
"Ports": [],
"LocalLBIndex": 21645,
"Tasks": [
{
"Name": "testing_manager2.1.5w51imw8toh81oyeruu48z2pr",
"EndpointID": "41eeb9eaf97cd3f744873ccea9577332e24c799f61171c59447e084de9c829a4",
"EndpointIP": "10.0.25.9",
"Info": {
"Host IP": "A.A.A.A"
}
}
]
}
}
docker network inspect testing_default -v on worker shows
"Peers": [
{
"Name": "75fba815742b",
"IP": "B.B.B.B"
},
{
"Name": "f0de4150d01e",
"IP": "A.A.A.A"
}
],
"Services": {
"testing_worker1": {
"VIP": "10.0.25.10",
"Ports": [],
"LocalLBIndex": 293,
"Tasks": [
{
"Name": "testing_worker1.1.ol4x1h560613l7e7yqv94sj68",
"EndpointID": "3a9dc067b4a0e7e5d26fabdcb887b823f49bfad21fc0ec159edd8dd4f976b702",
"EndpointIP": "10.0.25.11",
"Info": {
"Host IP": "B.B.B.B"
}
}
]
},
"testing_worker2": {
"VIP": "10.0.25.2",
"Ports": [],
"LocalLBIndex": 292,
"Tasks": [
{
"Name": "testing_worker2.1.m2d5fwn83uxg9b7udakq1o41x",
"EndpointID": "8317415fe2b0fa77d1195d33e91fa3354fcfd00af0bab5161c69038eb8fe38bb",
"EndpointIP": "10.0.25.3",
"Info": {
"Host IP": "B.B.B.B"
}
}
]
}
}
So the worker sees the manager as a peer, but does not see the other services. What confuses me, is that the Host IP for worker services is B.B.B.B, which is the internal IP of the worker node (so a 192.168.x.x IP) instead of the external IP of my home network.
Attaching to one of the containers with docker exec -it <CONTAINER ID> /bin/sh and executing wget -qO- <ANOTHER CONTAINERS IP>:8000 returns fine for containers on the same node, but Host unreachable for containers on the other node. (Testing with the defined host names returns "bad address" for the ones on the other node)
Looking at the docs, it reads at https://docs.docker.com/engine/swarm/swarm-tutorial/#open-protocols-and-ports-between-the-hosts that there need to be some ports open.
I was under the impression that creating the swarm comes with a virtual network between the nodes (which kinda seems to be the case, as the services can get created without a problem, so there is a connection). But as it did not work like that, I tested it with just plain port forwarding, which resulted in the manager "sometimes" seeing the other services when inspecting the network, but the containers still can't reach eachother.
Am I supposed to spin up a VPN for the nodes to be inside the same network, or what am I missing?

Related

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.

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

AWS ECS containers are not connecting but works perfectly in my local machine

I have an application(runs at http://localhost:8080) that talks to a backend api which runs at http://localhost:8081. I have dockerized the frontend and the backend separately and running them through docker-compose locally works perfectly without any issues. But, when I run it in ECS, the frontend couldn't find http://localhost:8081(backend).
I am using an AutoScaling group with an Elastic Load Balancer and I have my both containers defined in a single Task Definition. Also, I have the backend linked to the front end. When I ssh into my ECS instance and run docker ps -a i can see both of my containers are running at the correct ports exactly like in my local machine(Result of docker ps -a) and I can successfully ping each of them from one container to the other.
Task Definition
"CartTaskDefinition": {
"Type": "AWS::ECS::TaskDefinition",
"Properties": {
"ContainerDefinitions": [
{
"Name": "cs-cart",
"Image": "thishandp7/cs-cart",
"Memory": 400,
"PortMappings":[
{
"ContainerPort": "8080",
"HostPort": "8080"
}
],
"Links": [
"cs-server"
]
},
{
"Name": "cs-server",
"Image": "thishandp7/cs-server",
"Memory": 450,
"PortMappings":[
{
"ContainerPort": "8081",
"HostPort": "8081"
}
],
}
]
}
}
Listeners in my ElasticLoadBalancer,
The first listener is for the frontend and the second one is for the backend
"Listeners" : [
{
"LoadBalancerPort": 80,
"InstancePort": 8080,
"Protocol": "http"
},
{
"LoadBalancerPort": 8081,
"InstancePort": 8081,
"Protocol": "tcp"
}
],
EC2 instacne security Group Ingress rules:
"SecurityGroupIngress" : [
{
"IpProtocol" : "tcp",
"FromPort" : 8080,
"ToPort" : 8080,
"SourceSecurityGroupId" : { "Ref": "ElbSecurityGroup" }
},
{
"IpProtocol" : "tcp",
"FromPort" : 8081,
"ToPort" : 8081,
"SourceSecurityGroupId" : { "Ref": "ElbSecurityGroup" }
},
{
"IpProtocol" : "tcp",
"FromPort" : 22,
"ToPort" : 22,
"CidrIp" : "0.0.0.0/0"
}
],
Docker Compose
version: "3.5"
services:
cart:
build:
context: ..
dockerfile: docker/Dockerfile
args:
APP_LOCATION: /redux-saga-cart/
PORT: 8080
networks:
- server-cart
ports:
- 8080:8080
depends_on:
- server
server:
build:
context: ..
dockerfile: docker/Dockerfile
args:
APP_LOCATION: /redux-saga-shopping-cart-server/
PORT: 8081
ports:
- 8081:8081
networks:
- server-cart
networks:
server-cart:
Quick update: I have tried it with awsvpc network mode with application load balancer. Still not working
Thanks in advance.
What kind of Docker Network mode are you using(Brdige/Host) on ECS?. I don't think localhost will work properly on ECS containers. I had same issue so I used private IP or DNS name of EC2 host for my communication as temp testing purpose. Ex - http://10.0.1.100:8081.
Note - Please make sure to give security group rule to allow 8081 traffic from within EC2(Edit EC2 security group to allow 8081 from same sgid as source).
For Production deployments, I would recommend to use a service discovery to identify the backend service(Consul by Hashicorp) or AWS Private Service Discovery on ECS.
-- Update --
Since you are running both containers under same task def(under same ECS service), so typically ECS will bring both docker containers on same host. Do something like following.
By default ECS brings containers using Bridge mode on Linux.
You should be able to have each containers communicate using Docker Gateway IP - 172.17.0.1 on Linux. So for your case, try configuring http://172.17.0.1:8081

Cannot access a Docker Swarm service through its published port on the host

I have deployed a Docker Swarm cluster on several machines and I am now trying to access to the server running in Docker from the host.
I use docker compose file to define my service and the exposed port appears when I inspect the service:
"Endpoint": {
"Spec": {
"Mode": "vip",
"Ports": [
{
"Protocol": "tcp",
"TargetPort": 27017,
"PublishedPort": 3017,
"PublishMode": "host"
}
]
},
"Ports": [
{
"Protocol": "tcp",
"TargetPort": 27017,
"PublishedPort": 3017,
"PublishMode": "host"
}
],
"VirtualIPs": [
{
"NetworkID": "**********",
"Addr": "10.0.0.34/24"
}
]
}
I use host mode because the service is constrained to run on a particular machine, and I want it accessible only from this machine.
But when I list the processes listening on ports on the host machine, the port doesn't appear.
And of course I cannot connect to the server from the host through the exposed port.
I am using iptables as firewall and restrains as much as possible the open ports, but the Docker Swarm needed ones are opened.
Here is my docker-compose.yml file:
version: '3.4'
services:
mongo-router:
image: mongo
networks:
- mongo-cluster
volumes:
- db-data-router:/data/db
- db-config-router:/data/configdb
ports:
- target: 27017
published: 3017
protocol: tcp
mode: host
deploy:
placement:
constraints:
- node.labels.mongo.router == true
command: mongos --configdb cnf/mongodb-cnf_mongo-cnf-1:27017,mongodb-cnf_mongo-cnf-2:27017,mongodb-cnf_mongo-cnf-3:27017
volumes:
db-data-router:
db-config-router:
networks:
mongo-cluster:
external: true
The network is an overlay network on which all services are subscribing.
I had a similar issue. After installing hyper-v feature on windows (even though the cpu did not support hyper-v) I was able to access published ports from the host (even in ingress mode).

Resources