We are building a system with multiple micro services that are forwarded by a gateway.
For service discovery we are using our own solution that listens to UDP broadcast messages from services.
It all work fine on a development machines but when we are running it with docker, UDP communication is not working.
We are using Microsoft.NET.Build.Containers to build our images. Service responsible for gathering and distributing service information listens for broadcasts on UDP port 4022. csproj contains port information.
<ItemGroup>
<ContainerPort Include="4022" Type="udp" />
</ItemGroup>
Our compose file look something like this:
version: "3.8"
services:
diag:
image: "praqma/network-multitool:extra"
restart: unless-stopped
networks:
- internal
discovery:
image: "registry/discovery:latest"
restart: unless-stopped
networks:
- internal
expose:
- 4022/udp
some-service:
image: "registry/some-service:latest"
restart: unless-stopped
networks:
- internal
gateway:
image: "registry/gateway:latest"
restart: unless-stopped
networks:
- external
- internal
expose:
- 4494:80
logger:
image: "registry/logger:latest"
restart: unless-stopped
networks:
- internal
networks:
internal:
driver: overlay
external: false
external:
external: false
When testing using nmap, from container running praqma/network-multitool:extra image, we have a port closed information:
bash-5.1# nmap -sU -p 4022 discovery
Starting Nmap 7.91 ( https://nmap.org ) at 2023-09-14 06:08 UTC
Nmap scan report for test-stack_discovery.1.5fofkkppphmw6xpsygni2ux39.test_stack_internal (10.0.16.15)
Host is up (0.00021s latency).
PORT STATE SERVICE
4022/udp closed dnox
MAC Address: 02:42:0A:00:10:0F (Unknown)
So all other services fail to start because they require configuration from that service.
How we can diagnose that further? Is it even possible to use UDP broadcast approach in docker containers or we need to move to some other form of service discovery?