Consider a docker image containing a React UI
and a Spring REST app
. I'd like to deploy this to Azure web app for containers, where the URL for the instance hits the UI
which is being statically served on port 5000
while the Spring app
is listening on 8080
. The UI
communicates with the Spring app
via HTTP, hence the requests made by the UI
to the Spring app
are evaluated on the user's machine (i.e. can't access the Spring app
via localhost:8080
). However, port 8080
is not mapped in the default run command. Another issue is that there is only one URL for the web app.
The default run command is: (from logging in via FTP and examining docker logs)
docker run -d -p <WEB_APP_PORT>:<UI_PORT> --name ... -e ... <IMG>
Can I run a custom docker run
command to expose the UI_PORT
and the SPRING_PORT
and also set up one web app with two URLs?
If not, are there alternative solutions?
For context:
The final image is built by extending an image which contains only the Spring app
(i.e. FROM openjdk:8-jdk-alpine
) and installing node and the UI.
An entrypoint.sh
script start both the UI and the SPRING APP
The ports exposed in the image are 8080
and 5000
.
A diagram of what I'm trying to achieve:
No, you can't do what you want with "Azure web app for containers", that platform lets you run a single container image that is mapped to ONLY one URL, and you can ONLY export web ports (80, 443) to the world, and SSH (2222) to their internal "kudzu" service.
Being "purist", you are describing a "microservice stack", so you have to go with a full container orchestration, like "Azure Container Service" (AKS, using Kubernetes), or "Azure Service Fabric" (which looks it will be awesome when they reach their goals).
However, you could get it done by internally running a "mapping service", like an Nginx proxy which would send "/" to the localhost:8080 UI and /api to localhost:5000 Spring API, or any of the techniques traditionally used for Single-page-Application "routing".
It's a decision between putting all your services inside a single container behind a single URL (microservice in a container) or putting every process in a container on a container orchestration platform (the former is cheaper in time and cost of running it, the later is more "elegant" and flexible but requires more time to build the management and is more expensive to run).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With