1

I'm more of a software developer than a networking/ops person to give you some context.

I'm currently creating an application that is a standard containerised microservices architecture, where my frontend is some static assets in an nginx container, and my backend APIs are expressjs servers running on node containers.

When my frontend makes a call to a backend endpoint, it's going to look like:

const response = await fetch("/api1/v1/items"); 

Because by default the browser is going to make this request to the frontend container, we need some way of redirecting that traffic to the correct backend container.

One standard way to do this, is that I can setup a reverse-proxy in the frontend container's nginx.conf to direct all /api1/* traffic to another service.

ie. you would do something like this:


location /a {
   proxy_pass         http://api1;

Where you have defined api1 as a service in your docker-compose.yml.

I'm a bit uncomfortable with this, at the cluster configuration is mixed up with the implementation.

I am aware with Kubernetes ingresses, this routing can be done from outside of the container - where essentially the traffic is routed as it enters the cluster.

This is a much nicer solution in my view.

But the reason I'm using docker-compose is just for simplicity - it's more for running the cluster on your local machine and just getting the whole thing up and running.

Is there a similar configurable ingress concept for docker-compose?

1
  • you want to run microservices. you want to run on docker alone. you don't want to mix routing concerns into your frontend container. so why not just run a separate routing container that has conf for routes to all the other microservices and the frontend? if you eventually migrate to Kubernetes you would replace the routing component with the built in infrastructure. you can then evaluate different routing tech in the routing container such as openresty if pure nginx isn't smart enough.
    – simbo1905
    Apr 21 '19 at 7:02
1

Kubernetes ingress is implemented by changing the configuration of another container or the cloud load balancer to route traffic to the service port/ip. Docker by itself is fairly lightweight, only runs the containers you start, and does not have external dependencies on things like your cloud load balancer. The solutions to setup a reverse proxy inside a container are almost identical to the kubernetes nginx based ingress controllers, with the key difference being the configuration of that reverse proxy.

There are a variety of docker based reverse proxies that configure themselves, including docker-flow-proxy, nginx-proxy, and Docker-EE ships with interlock that configures HA proxy. Probably the easies solution I've seen to implement is traefik which can be configured to monitor the docker socket for changes and automatically reconfigure based on labels set on your containers.

One important difference from Kubernetes is that docker networks are not flat, you will need to explicitly place the proxy container on the same docker network as your application in order for them to be able to route traffic between each other.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.