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).
Related
I've wrote a simple NodeJs (ExpressJs) server that uses Puppeteer to generate PDF files on JSON data being passed to it. While locally everything is working like charm, I'm struggling to run this server on Azure App Services.
I've created a Resource group, within it I've created an App Servces instance (running on Linux) that is connected to my repo at Azure DevOps (via the Deployment Center).
My server has two endpoints:
/ - returns a JSON - { status: "ok" }. I'm using this to validate the running server instance.
/generate-pdf - uses the Puppeteer to generate and return a PDF file.
After successfully starting the App Service instance I'm able to access the "/" route and get a valid response but upon accessing the "/generate-pdf" route the result is "502 - Bad Gateway".
Does my instance require some additional configuration that I haven't done?
Does App Services can not run Puppeteer? Perhaps there is a different service on Azure that I need to use?
Is there a way to automate the process via the Azure DevOps pipeline or release?
Any questions/thoughts/FAQs are more than welcomed. Thanks =)
I'm answering my own question: as was mentioned here https://stackoverflow.com... the Azure App Services does not allow the use of GDI (which is required by Chrome) regardless if you're using Linux or Windows based system. The solution was to put the NodeJs application into a Docker container and manually install Chrome. Once you have a container - just upload it to the Azure App Services and viola!
By default App Servies exposes 80 and 443 ports, so if your application listens on a different port be sure to specify it via the WEBSITES_PORT environment variable.
In my case, I had to upload the Docker image to the Docker hub but you can also set up a pipeline to automate the process.
I've built the Docker image on my M1 Pro and it led to some arch issues when the container was uploaded to Azure. Be sure to add the --platform linux/amd64 in the image-building step if you're building for Linux.
I am working on an supply chain management application. I developed frontend of the application in ReactJS and backed in docker and nodeJS. My question is if i deploy my backend i.e NodeJS sdk on docker swarm. Can i access the deployed API's in different computer?
You can achieve service (backend) is reachable from the outside in primarily two ways:
eighter you expose the port of the service directly, and you can then connect straight to it (it is not recommended to do so on any actual deployments) by using ports configuration. By doing so the exposed port will be available to access the service from the outside world.
or you deploy another service which will act as a reverse proxy / API gateway. So the proxy (nginx, traefik, ...) will listen for all incoming requests, check SSL, ..., and then it will forward the request to the right service. This is the recommended way because you hide your actual service behind a proxy, and also put all of the auth/ssl details on the proxy itself, so you free your service from needing to know anything about that technical details.
I have built a docker image using Spring Native. The Spring Boot application inside the container listens on port 80 but crashes on Azure Functions on startup because of missing access rights (it seems docker doesn't allow usage of ports bellow 1024). How can I change the port Azure Functions uses for accessing the application inside the docker image?
If you are using 80 or 8080, azure will auto-detect the used port.
Every other port can be configured using WEBSITES_PORT environment variable "Function App -> Settings -> Configuration -> New application settings" to something like 8081 (or that one, which the app listens on).
I have a requirement where I need to fetch the docker conatiner names, versions and their status whether running or stopped and display it in my web application. Is the docker provides APIs which I can utilize in web app to display all the above details?
My web application is running in a docker container and in the Linux environment.
Yes, you can use Docker Engine API to communicate with the Docker Engine, just like the Docker CLI does.
You can use dockernode to control and query the engine via node.
I have a custom built docker image which purpose is to process files that are loaded into a storage account or service bus. The container has no exposed ports.
I can deploy this image and start the container on the Azure Web App but after 240 seconds the container seems to terminate. The logs indicate that the container did not start within the time limit.
Am I correct in assuming that if no ports are exposed in my container that the webapp thinks that the container was not started correctly?
What is the best alternative for deploying my container if this is the case? (ACI, ACS, AKS,.. ?)
Azure Load Balancer has a default idle timeout setting of four minutes. This is generally a reasonable response time limit for a web request. If your webapp requires background processing, it is recommended to use Azure WebJobs. The Azure web app can call WebJobs and be notified when background processing is finished. You can choose from multiple methods for using WebJobs, including queues and triggers, see https://learn.microsoft.com/en-us/azure/app-service/web-sites-create-web-jobs
Checkout the FAQs here: https://learn.microsoft.com/en-gb/azure/app-service/containers/app-service-linux-faq
Can I expose more than one port on my custom container image?
We do not currently support exposing more than one port.
My custom container listens to a port other than port 80. How can I configure my app to route requests to that port?
We have automatic port detection. You can also specify an app setting called WEBSITES_PORT and give it the value of the expected port number. Previously, the platform used the PORT app setting. We are planning to deprecate this app setting and to use WEBSITES_PORT exclusively.