在 Azure Functions中访问应用程序设置

应用程序设置为何对 Azure Functions至关重要

Tim 首先指出，在构建最基本的 .NET 应用程序之外的其他应用程序时，应用程序设置是多么重要。鉴于 Azure Functions 运行时希望从环境变量、基于 JSON 的 local.settings.json 或 Azure 应用程序配置等托管存储中获取配置值，因此在 Azure Functions 环境中访问应用程序设置的需求更加明显。

"开发人员最终想要的一个常见功能是访问设置文件，"Tim 在 0:17 时解释道。

无论是 API 密钥、连接字符串还是功能标志，配置的灵活性和安全性都至关重要，尤其是在部署到 Microsoft Azure 等云平台时。

使用 Visual Studio 创建基础

1:24 时，Tim 使用 Visual Studio 建立了一个控制台项目，并将其命名为 SettingsDemoApp。Azure 开发人员通常会使用 Azure Functions 核心工具初始化 Functions 项目，而 Tim 搭建脚手架和组织代码的方法可以实现无缝翻译。 项目文件设置和代码结构是关键基础--无论您是在控制台环境中，还是使用隔离 Worker 模型构建隔离的 Azure Functions 应用程序。

安装所需的 NuGet 软件包

从 2:33 开始，Tim 将指导安装四个基本的 NuGet 软件包：

• 微软扩展配置

• 微软扩展配置.Json

• 微软扩展配置.Binder

• 微软扩展配置.UserSecrets

这反映了 Azure Functions 使用的应用程序配置系统，该系统在幕后依赖于相同的软件包。 Tim 强调了模块化的价值：

"这实际上与臃肿相反，"他指出，.NET Core 通过让开发人员通过 NuGet 进行选择，避免了不必要的有效载荷。

对于一个典型的功能应用程序，这些软件包要么是预先引用的，要么是可以轻松添加的，以支持配置设置、依赖注入或高级用例（如支持密钥库和 Azure 应用程序配置）的自定义逻辑。

添加和配置 JSON 设置文件

在 6:12 处，Tim 创建了一个名为 appsettings.json 的新文件，模仿在用于 Azure Functions 开发的 local.settings.json 中看到的结构。 他在其中填充了键值对，如

{
  用户{
    "名"："Tim"、
    "姓"：科里
 },
  "StarterCountValue": 5
}

在本地功能中，开发人员使用格式几乎相同的 local.settings.json，通过注入的 IConfiguration 将值读入应用程序逻辑。 Tim 还强调了一个关键步骤：将文件的 "复制到输出目录 "设置为 "如果较新则复制"--这对于确保您的配置在运行时可用至关重要。

手动构建配置管道

Tim 开始编写代码，手动使用配置管道：

var builder = new ConfigurationBuilder()
.SetBasePath(Directory.GetCurrentDirectory())
    .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)；

虽然 Azure Functions 运行时会自动处理此管道，但 Tim 的分解说明了函数项目如何从不同来源获取值。 他对 .AddJsonFile() 的使用反映了开发人员如何在 Azure 应用程序中配置 local.settings.json，而 reloadOnChange 则引入了在开发过程中动态刷新配置设置的概念。

使用类型安全读取值

Tim展示如何在11:00使用GetValue()方法读取设置：

int count = config.GetValue<int>("StarterCountValue")；

对于嵌套设置，他使用

string firstName = config.GetValue<string>("User:FirstName")；

在使用 Azure Functions 时，这些语法模式同样适用。 Tim 使用的冒号分隔键（"User:FirstName"）可以直接映射到使用双下划线 (__) 语法的环境变量中：

用户__FirstName=Tim

在部署到 Azure 应用服务或通过 Azure 门户进行配置时，这一点尤其有用，因为您可以在运行时使用应用程序设置或基于环境的覆盖来覆盖设置。

使用 UserSecrets 安全地处理机密

15:00 时，Tim 通过 User Secrets 介绍了 secrets.json 模式，该模式用于存储 API 密钥或连接字符串等敏感数据，而不会将其暴露在源控制中。 他展示了如何使用这一行将用户秘密存储附加到您的项目中：

builder.AddUserSecrets<Program>()；

他强调，排序很重要--用户秘密优先于早期的配置源，强化了 "后进者胜出 "的原则。 虽然 Azure Functions 并不直接使用 secrets.json，但在生产云环境中，您可以使用 Azure Key Vault（可选择使用托管身份验证）来实现相同的安全覆盖。

Tim 指出，本地开发中的秘密是您在生产中使用的任何安全系统的替身：

"这个 secrets.json 是您用来存储真实值的任何安全系统的替身--无论是 Key Vault 还是环境设置"。

运行和验证配置

在设置了 appsettings.json 和 secrets.json 后，Tim 运行了示例并验证了 secrets 是否覆盖了基本值。 这直接反映了 Azure Functions 如何处理来自多个来源的覆盖：local.settings.json、Azure 应用程序配置、环境变量或 Key Vault。

无论是通过命令行使用 Azure Functions 核心工具，还是通过 Visual Studio 进行部署，应用程序配置的加载顺序和分层都与 Tim 概述的完全一致。

配置管理的最佳实践

最后，Tim 建议在 JSON 文件中保留不经常变化的配置值，如功能标志、频率设置或 CORS 配置，并将连接字符串和机密等敏感数据放在安全的存储空间中。

这符合 Azure Functions 的现代最佳实践：

• 开发人员在本地使用 local.settings.json 实现功能

• 团队使用 Azure 门户进行应用程序设置

• 秘密转到密钥库

• Azure 应用配置商店中的值有助于将设置与代码分开

这些源代码通过依赖注入与运行时集成，无需接触应用程序二进制文件。

最后的想法

虽然 Tim 的视频是关于控制台应用程序的，但他教授的每项技术都可以无缝扩展到 Azure Functions 应用程序--从创建配置文件、读取密钥、使用托管身份到通过依赖注入加载配置。 无论是使用 Visual Studio 进行部署、管理您的 azure 账户，还是查找完整的代码示例，他的见解都能直接映射到现实世界的云实践中。