Open CAJTechnologyLimited opened 2 years ago
Experiencing the same issue here ... Deploying a container to a private container registry on Azure. The app service hosting the functions is connected to the deployed container via the linuxFxVersion setting on the app service. The docker logs via Kudu show that the container is pulled successfully. No functions shown in the portal after this, and a call to the HttpTrigger enabled function returns a 404.
Clearly this implies that the runtime is not picking up the functions. Does this have to do anything with the version of the functions runtime? I don't think so, because when I pull the deployed to my local machine, and call the HttpTrigger endpoint, then it runs just fine.
I found the culprit to be the persistent shared storage. If you are using WEBSITES_ENABLE_APP_SERVICE_STORAGE
set to true
, this will mount over the /home
directory of the container prior to execution. This effectively hides the app and files from the container runtime.
Additionally, any contents inside the /home directory of the container are overwritten by any existing files already present on the persistent storage when the container starts.
There appears to be no easy way to change this in Azure. The startup code specifically finds if the container is running in Azure (identifies if there is the environment variable WEBSITE_INSTANCE_ID), and then sets the path to /home/site/wwwroot
assuming that the environment variable HOME
is unset or set to /home
. Despite the property being called IsAppServiceEnvironment
, it's referring to Azure App Services as a whole and not just App Service Environment hosted applications.
The environment variable AzureWebJobsScriptRoot
is ignored in Azure App Services.
More information:
@nerddtvg @sergevm @CAJTechnologyLimited I'm facing the same issue with custom docker image on node platform. Did any of you find a fix or workaround for this?
I'm facing the same issue with custom docker image on node platform. Did any of you find a fix or workaround for this?
@prabhurajshell The only solution I have is from my comment above to not use WEBSITES_ENABLE_APP_SERVICE_STORAGE
.
@nerddtvg Thank you, setting WEBSITES_ENABLE_APP_SERVICE_STORAGE as false worked for me. Are there any downsides to performance if we are not using the persistent storage?
We were having a problem with the exact same symptoms but the fix turned out to be different than the WEBSITES_ENABLE_APP_SERVICE_STORAGE
. We were upgrading an existing functions 3 to run on the 4 framework and everything was working fine running the container locally but refused to recognize any functions in azure. Turns out the issue was the path we were using in the docker build command.
Previously the devops pipeline would run the equivalent of this command, within the project directory:
docker build -f Dockerfile .
and the build step within the dockerfile looked like:
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["myproject.csproj", "myproject/"]
RUN dotnet restore "myproject/myproject.csproj"
COPY . .
WORKDIR "/src/myproject"
RUN dotnet build "myproject.csproj" -c Release -o /app/build
The trick turns out to be running the build from one directory up at the solution level... Command updated to:
docker build -f myproject/Dockerfile .
and build step changed to:
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["myproject/myproject.csproj", "myproject/"]
RUN dotnet restore "myproject/myproject.csproj"
COPY . .
WORKDIR "/src/myproject"
RUN dotnet build "myproject.csproj" -c Release -o /app/build
Not sure why it was different between v3 and v4, or why it worked locally, but there it is.
Our team also ran into this issue. We resolved it by setting WEBSITES_ENABLE_APP_SERVICE_STORAGE to false.
This triggered a different issue related to the permissions for the following directory /home/LogFiles/Application/Functions/Host. If you run into this verify that this directory exists inside your container and that the access level for /home and subfolders is open to non-root users
Upgrading the function runtime worked for me, Dockerfile: FROM mcr.microsoft.com/azure-functions/node:4-nightly-node18 ENV AzureWebJobsScriptRoot=/home/site/wwwroot \ AzureFunctionsJobHostLoggingConsole__IsEnabled=true COPY . /home/site/wwwroot RUN cd /home/site/wwwroot && \ npm install && \ npm run build
Hoping someone can help me! Appreciate this is close to the following issue previous raised: https://github.com/Azure/azure-functions-docker/issues/128 Unfortunately the above link didnt solve my problem.
I added docker to an existing azure function that I had previously built. This was done via the docker support functionality within visual studio. The created dockerfile runs perfectly fine within visual studio. Having looked at what commands VS runs these are significantly different to what I am expecting to run. One to build the docker image and two to spin up the container.
Dockerfile:
Therefore I am looking to one run the following Build command:
docker build -f Dockerfile . -t newtest
This on face value looks like it has succeeded. Here is the output of the above:
After the build succeeds the next command I am running is:
Command
docker run -it --rm -p "5500:80" newtest
Output
As you can see the output above shows: info: Host.Startup[315] 0 functions loaded info: Host.Startup[0] Generating 0 job function(s) warn: Host.Startup[0] No job functions found. Try making your job classes and methods public. If you're using binding extensions (e.g. Azure Storage, ServiceBus, Timers, etc.) make sure you've called the registration method for the extension(s) in your startup code (e.g. builder.AddAzureStorage(), builder.AddServiceBus(), builder.AddTimers(), etc.).
I cant for the life of me figure out why no job functions are being found, considering running it via VS produces in successful build & run. I even tested via consuming the expected endpoints successfully.
Apologies if I havent produced every log available, im a newbie when it comes to docker and containerisation, hence trying to get it working with an existing application