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?