通过 websockets 将 traefik 用于 docker 内部流量

Question

I'm using docker in swarm mode for the services in my application and traefik to handle, well, the traffic. My goal is to make a separate service for each API section my application has (so for example requests on domain.com/api/foo_api go to the foo_api service and requests on domain.com/api/bar_api go to the bar_api service.

Now all this is pretty straightforward with traefik. However, I'm also using the API services with other internal services not related to the API. They use a websocket connection to the internal docker URL, so currently it's ws://api:api_port/ws . However, if I split up the API part I'd need something like ws://foo_api:foo_api_port/ws which obviously leaves the service only access to the foo_api , not every other one.

So my question is: Can I route this websocket traffic with traefik similiar to how I do it externally, but internally in the docker net?

Answer 1

Traefik is a north-south reverse proxy. Most people historically in traditional infrastructure would use NGINX or Apache to address inbound - good to see you using a more modern tool. What you are describing is an east-west pattern of communication inside your firewall behind traefik (assuming you control all ingress through traefik).

Have you considered using service discovery and registry capabilities with tools like Hashicorp Consul - https://consul.io ?

The idea of having service discovery is so that your containers / services inside the swarm can be discovered and made available through the registry and referenced in proximation to each other by name without the pains of manual labor in building and maintaining complicated name-IP-lookups. Most understand this historically in a more persistent model behind DNS SRV which requires external query. Consul can still support that legacy reference integration as well.

This site might help you along: https://attx-project.github.io/Consul-for-Service-Discovery-on-Docker-Swarm.html

They appear to have addressed a similar case to yours. And the work is likely reusable with a few tweaks.