A question about Github Action Deploying Azure Function which is in VNet
I have:
- GitHub Repo + Action for deployment with Publish Profile
- Azure Function that is a part of the VNet/Subnet/NSG
—
Works: I am able to deploy the function only if I enable full public access for the function.
Need: I would like to restrict that so that I would not need to have public access for the deployment.
Problem: I am not able to allow Github Action on IP/Service whitelist or VNet
—
I do not really want a function to be publicly available all the time. Switching public access on and off for the deployment does not feel right.
Any suggestions?
5
Error: Failed to fetch Kudu App Settings. Ip Forbidden (CODE: 403)
To resolve this error, add the below application settings in the Function app=>Settings=>Environment Variables:
WEBSITE_VNET_ROUTE_ALL=1
WEBSITE_CONTENTOVERVNET=1
I have enabled access restrictions in the function app by selecting Enabled from selected virtual networks and ip addresses and add a rule to enable VNET access:
Able to deploy the function to Azure function app with access restrictions using GitHub actions:
Portal:
4
I went back and recreated the function by starting from the beginning with Public network access: Disabled and added the function to VNet/Subnet/NSG with the default (no changes) inbound and outbound rules. With these settings, the deployment would fail as it was mentioned in the original posting. That did not publish regardless of whether the CI/CD was set up from the function as the first step or getting the publish profile and doing everything from GitHub side. Note that since there was VNet integration, it was still possible to communicate with the Fuction from withing the VNet, but again, deployments were not possible.
As soon as I switched to Public network access: Enabled from selected virtual networks and IP addresses, without any changes to Site access and rules, the deployment went through. It still had the VNet/Subnet/NSG from earlier but now the deployment went through.
My findings:
- Public network access:
Disabled– blocks deployments - Public network access:
Enabled from selected virtual networks and IP addresses–
allows deployments.
2
After some writing back and forth with MS Azure Support we have got the answer:
the ASP density is unhealthy so once the HealthCheck has to check it
privately as opposed to publicly it’s also able to see the state of
the instances’ minor problems and display them. Overall the ASP
density isn’t something that would affect the health of an app unless
there’s a lot of heavy apps running on it. That’s why I recommended
splitting the 12 apps that are on the original ASP and moving half
under the new ASP which should help mitigate the occurrence you’re
seeing.As you’re running an ASP with small instances the maximum recommended
apps to run on it is 8 in order to keep a healthy environment and it
doubles with every instance size (16 for Medium and 32 for Large).
We are running 12 rather small Azure Function on the Flexible Premium Function service plan. Everything works as expected, it is only the health-checks that freak out because of the larger number of functions. I do not see us purchasing an additional ASP only to fix this issue, so we will be implementing our own health-check routine instead. Maybe we will merge some of the functions into 1 later on.