A decision was made by my company to containerise the entirety of a solution with multiple services into a single monolithic container (best practices aside please as I am well aware this goes against the microservice approach of 1 container = 1 service). In essence the following ports should in theory be listening for traffic:
- Port 3000 (static React frontend)
- Port 8081 (backend services)
- Port 8545 (additional service) [can deal with this later as I feel illumination of the problem with the Port 8081 service will lead to a similar resolution for this one]
When I host this container on an Azure Web App for Containers instance the frontend service comes up on it's own, no problem, (route is
/). However, the backend service is mapped to
:8081/services/* as above) and contains a config file the frontend needs to be truly "functional". However, this appears to be inaccessible as the web app attempts to proxy to
localhost:8081/services/* in order to get it (as it is localhost WITHIN the container itself).
What it is the best approach to allow the web app to call out to the additional service(s) on these different ports?
I initially thought I could place an Azure Application Gateway in front of the web app to act as a reverse proxy and do a hostname rewrite to rewrite requests on Port 8081 to (FQDN/IP):8081, but this doesn't seem to be working correctly (no difference in error codes or visually). I also thought about placing a reverse proxy like Nginx WITHIN the container, but was interested in seeing if I could do it outside first to stop increasing the size of this already large image or if this would even be an option.