英文:
KeyVault getSecret() takes 13 seconds in Azure Functions nodejs runtime
问题
我在从密钥保管库获取密钥时遇到了13秒的延迟。我的 Azure Functions 使用了一个 Consumption Plan。
Azure Functions 的 System Identity 在密钥保管库服务上的 RBAC 权限如下：
我已经为 KeyVault 创建了单例模式以提高性能，但第一次调用总是太慢了。这是我访问密钥的方式：
const credential = new DefaultAzureCredential();
client = new SecretClient(process.env.KeyVault, credential);
var secretValue = (await client.getSecret("SecretName")).value;
我在 .NET 中从未遇到过这种类型的延迟（因此我对实际库有疑虑）。我在互联网上搜索了有关 Node.js 的已知问题，例如 这个问题，但我的包版本更高，所以应该已经解决了。这是我的 package.json：
"@azure/identity": "^3.1.3",
"@azure/keyvault-secrets": "^4.7.0"
其他问题（如这个问题）提到不要使用 .Result 来访问值，但这不是我的情况。任何帮助和见解都将不胜感激！
更新：
延迟在本地环境中不会发生。
在 Azure 中的延迟为33毫秒：
再次更新：
我创建了一个 dotnet 函数来排除这是否是一个 Node.js 库的问题。延迟也在那里发生了。
它只是调用了这个密钥：
英文:
I am experiencing a 13 seconds delay when getting a secret from the key vault. I have a Consumption Plan for the functions.
The RBAC permissions the Azure Functions System Identity has on the Key Vault service are:
I have created a singleton pattern for the KeyVault to improve performance but the first call always takes too long. This is how I access the secret:
const credential = new DefaultAzureCredential();
client = new SecretClient(process.env.KeyVault, credential);
var secretValue = (await client.getSecret("SecretName")).value;
I have never experienced this type of delay in .NET (hence my doubt on the actual library). I have searched on the internet about known issues like this one for Nodejs but my package version is higher so it should have been resolved. This is my package.json:
"@azure/identity": "^3.1.3"
"@azure/keyvault-secrets": "^4.7.0"
Other issues like this one spoke about not using .Result to access the value but again, this is not my case. Any help and insight would be highly appreciated!
UPDATE:
The latency does not happen locally.
The latency in Azure is 33ms:
UPDATE AGAIN:
I created a function in dotnet to exlude that this is a nodejs library issue. The delay happens there as well.
Its only calling this secret:
答案1
得分: 0
我最终从按消耗计费方式更改为专用计划，其中应用服务不会关闭。
通过这种方式，我可以运行另一个函数，每天检查密钥并更新 process.env 变量。理论上，在专用计划下，环境变量的更新应该在应用服务启动时完成。
这样，长时间的调用只会执行一次，应用将继续使用环境变量。在非函数后端的情况下，可以在启动类中进行 process.env 的初始化，而不是使用函数。
英文:
I ended up changing from Consumption to a Dedicated plan where the app service doesn't shut down.
In this way, I can run another function which once a day checks the secrets and updates process.env variables. With a dedicated plan theoretically, the update of env variables should be done once on app service startup.
This way the long call will be done only once and the app will continue to use the env variables. Instead of a function, the initialization of process.env could be done on a startup class in case of a non-function backend.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论