1

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 /services/* (actually :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.

1 Answer 1

1

Azure Web App for Containers expose one port from your container. Azure Web App for Containers detect port 3000 first (3000<8081).

Revers proxy in container will resolve your problem. Test outside of container will not work.

For test you may be change port 3000 to 8082. Backend /services/* will available, but frontend won't.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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