Removes Content Share when using private Storage Account connectivity #110
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nr-rkallempudi
requested changes
Sep 9, 2024
nr-rkallempudi
approved these changes
Sep 12, 2024
|
🎉 This PR is included in version 2.5.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Back in May 2023, we modified our EventHub and BlobStorage ARM templates to allow having private connectivity only between the Function App and the Storage Account they use to store the data required by these function to work. They have been working fine since then. However, the deployment of such functions started being faulty some time ago.
We engaged into an investigation with the Azure engineers, with whom we found out that some change was introduced in the Azure Platform that arises a race condition. This race condition causes the Function App to start before the VNET is fully configured. The function app then tries to reach the Storage Account through the Azure backbone network instead of the VNET (thus attempting to reach it via its public endpoint). Because the Storage Account has public connectivity disabled, this connection is refused and prevents the function from even being able to deploy its own code in the Content Share it used.
We determined this race condition is intermitent (sometimes the function just works, sometimes it just doesn't). Restarting the function sometimes resets the configuration so that the function starts using the VNET to access the storage account.
Nevertheless, given that this is totally random, the Azure engineers suggested we mitigate this by not using a content share in the Storage Account to deploy the function code into. Given that our function (when deployed with private connectivity only) runs on a dedicated plan, using a content share is not necessary since the functions end up using platform-provided built-in storage. That is, the function code gets deployed inside the VM that executes our function instead of using the Storage Account content share.
Changes