A perfectly working setup suddenly started failing after redeploying the Azure resources involved:
- Storage account with multiple file shares
- Azure AppService on a Linux ServicePlan, hosting a Linux Docker container
- Azure AppService, configured with Path Mappings to the various file shares on the storage account
After reprovisioning the resources (end of June 2021), we found out Apache (inside container) wasn't able to serve files from the mounted storage anymore: it returned a HTTP status 502.
It was still able to persist files to these same mounted file shares (excluding hypotheses that our mounted drives were somehow unreachable).
When accessing the container inside the AppService over SSH, basic curl commands to these same files returned "Received HTTP/0.9 when not allowed"
We escalated this issue to MS support.
The issue got fixed by applying a work-around: we had to identify an empty ResourceGroup.
That way MS could make sure internally that our AppService/ServicePlan deployment eventually landed on the proper hosting resources, resulting in proper behavior.
If we redeploy our resources as-is, without notice to MS support, we inevitably are confronted with the unwanted behavior.
We've been asking MS Support for a ETA on a structural fix ever since (last 3 months), but never got commitment from their end.
We continue to be amazed that a fairly trivial scenario, as this one, seemingly doesn't get any more priority. No doubt lots of other customers are impacted in the same way as we are.
Anybody experienced any similar behavior?
