[BUG] Startup problem with deployment on Azure Container App Service

[hgodwin648]

Describe the bug

When deploying on Azure Container App Service, the Container Apps service injects a default health probe on containers where ingress is enabled. On first startup of the misp-web container, the "Persisting app files..." takes longer than the health probe allows, resulting in the container restarting before the app files have been persisted. The startup health probe can be disabled, but only after the initial deployment, which is too late.

To Reproduce
Steps to reproduce the behavior:

1. Deploy on Azure Container Apps
2. Container gets restarted before "Persisting app files..." has a chance to complete.

Expected behavior
If possible:
Start the misp-web web server quickly and perform expensive initialisation in the background, alternatively provide a readiness endpoint that can respond with a HTTP status code greater than or equal to 200 and less than 400 while initialisation takes place.

Screenshots

Docker Host:

• OS: Azure Container Apps

Additional context
See the following documentation:
https://learn.microsoft.com/en-us/azure/container-apps/health-probes?tabs=arm-template

[JoePJisc]

Thanks for reporting this anomaly with how Microsoft has implemented their own health checks rather than using the container's built in health check.

Unfortunately, there is not a simple fix here and this will need further consideration on how to work around properly. Both proposed solutions would invalidate the health check - i.e. report it is healthy before it is, prevent container fault detection and allow containers to be added to load balancers before they are ready to serve requests.

As a workaround for now, you could add a Caddy/nginx container in front of misp-web and configure this as a reverse proxy to misp-web and add a static health endpoint. You could then use this proxy container as your ingest target so Azure leaves misp-web alone to do its initial start-up.

[hgodwin648]

Thanks for the response and appreciate it is an Azure specific issue. I like the nginx idea but I don't think it will work because for the reverse proxy to connect, it will still need the ingress option turned on, which automatically turns on the startup health check. I think for now the only option is to deploy it without the ingress option, wait for the container to start and then add the ingress option at the end.

[JoePJisc]

If disabling Azure's health check temporarily is an option, that may be simplest for now.

A Caddy container with this Caddyfile should also work if you point the startup and liveness endpoints to /health/startup and /health/liveness respectively and the readiness endpoint to /users/login:

:80 {
	respond /health/startup OK 200
	respond /health/liveness OK 200
	reverse_proxy https://misp-web {
		transport http {
			tls_insecure_skip_verify
		}
	}
}