Routing HTTP requests between containers with a reverse proxy

A reverse proxy is a very useful piece of technology to add to your project, whether you're looking at building a new microservices architecture or modernizing a legacy monolith. The reverse proxy is just an HTTP server that receives all the incoming web traffic from the outside world, fetches content from another HTTP server, and returns it to the client. In Docker the reverse proxy runs in a container with published ports, and it proxies traffic from other containers, which do not have any published ports.

This is the architecture of the UI and API containers with the reverse proxy in place:

All the routing rules for incoming traffic are in the proxy container. It will be configured to load requests for the home page location / from the nerd-dinner-homepage container; requests that start with the path /api will be loaded from the nerd-dinner-api container, and any other requests will be loaded from the original app in the nerd-dinner-web container.

It's important to realize that the proxy does not redirect the client to these other services. The proxy is the only endpoint that the client connects to. The proxy makes HTTP requests to the actual service on the client's behalf, using the containers' host names.

Reverse proxies can do a lot more than routing requests. All traffic passes through the reverse proxy, so it can be the layer where you apply SSL termination and HTTP caching. You can even build security into your reverse proxy, using it for authentication and as a web application firewall, protecting you from common attacks like SQL injection. This is especially attractive for legacy applications. You can make performance and security improvements in the proxy layer, leaving the original app as an internal component in a container that can't be reached except through the proxy.

There are many technology options for the reverse proxy. Nginx and HAProxy are popular options in the Linux world, and they can also be used in Windows containers. You can even implement IIS as a reverse proxy, running it in a separate container with all the routing rules set up using the URL rewrite module. These options are powerful, but need quite a lot of configuration to get up and running. I'm going to use a reverse proxy called Traefik, which was built to run in a container in cloud-native applications, and it gets the configuration it needs from Docker.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.119.111.179