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.
Related
We are running our application using Azure App Service. It is based in .NET FW 4.7 with Webforms and API Rest. We are using PC3 App Service Plan (16GB RAM). The application is stateless and it supports the Application Service scale out without a problem.
In a first step to modernize our infrastructure, the application was packaged in a Windows Container and it is executed in an App Service. The image is based on mcr.microsoft.com/dotnet/framework/aspnet:4.8 and uploaded to ACR. The problem occurs when trying to scale out the application. At the time of scale-out, the new container is added to the balancer and some requests are answered with "The Web App's container is starting up!"
Is there a way to add the new container to the balancer only when it is fully functional?
Note: I don't know if this is related to the problem but it appears in the log:
CONTAINER_HEALTH_CHECK_MODE app setting is set to ReportOnly. Container will not be recycled. For container to be recycled when it becomes unhealthy set it to Repair
I am wondering, what is the reason for Azure Container instances not to have an HTTPS address?
In comparison, Web Apps do have HTTPS endpoint by default, while Container Instances have just HTTP endpoint assigned.
Why is that?
When you deploy an application to Azure Web Apps, you are basically running your application behind IIS. You can configure the Web Apps platform to terminate SSL connections and all incoming requests received by your application will be via HTTP.
On Azure Container Instances, you container is directly connected to the network. If you want to terminate SSL before it reaches your application, you would need to have a service which provides SSL termination. The typical way to do this without creating any more infrastructure is to run nginx as a sidecar to your application container.
When I deployed my app to Azure App Service I got quite awesome telemetry out of the box.
Some of the telemetry data is generated by the App Service itself, some of it by my ASP.NET Core app that is using Application Insights logging.
As a result I could find out slow http requests, all application and IIS logs related to the request and see a nice chart showing where the time was spent, e.g. waiting for a SQL query or some http call.
I wonder how much of this telemetry can I get if I decide to go with Azure Container Instances.
The telemetry collected from the application itself using Microsoft.ApplicationInsights.AspNetCore SDK- you'd pretty much everything of that irrespective of where app is runnning - vm or container or app service.
from https://learn.microsoft.com/en-us/azure/azure-monitor/app/docker
When you run the Application Insights image on your Docker host, you get these benefits:
Lifecycle telemetry about all the containers running on the host - start, stop, and so on.
Performance counters for all the containers. CPU, memory, network usage, and more.
If you installed Application Insights SDK for Java in the apps running in the containers, all the telemetry of those apps will have additional properties identifying the container and host machine. So for example, if you have instances of an app running in more than one host, you can easily filter your app telemetry by host.
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).
In our organization, we are currently trying out the Azure Container Service with Docker Swarm. We have developed a Web API project based on .NET Core and created containers out of it. We have exposed the web api on Container’s Private Port (3000). We want to scale this to say 15 containers on three agent nodes while still accessing the web api through one single Azure load balancer url on public port 8080.
I believe we would need an Internal Load Balancer to do this but there is no documentation around it. I have seen this article on DC\OS but we are using Docker Swarm here. Any help?
Azure Container Service use vanilla Docker Swarm so any load balancing solution for Swarm will work in ACS, e.g. https://botleg.com/stories/load-balancing-with-docker-swarm
Same is true for DC/OS, but in this case it is documented in "Load balance containers in an Azure Container Service cluster" - https://azure.microsoft.com/en-us/documentation/articles/container-service-load-balancing/