Cloud-Native | The .NET Blog

azd钩子支持Python、TypeScript和.NET：告别Shell脚本

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

本文已自动翻译。如需查看原始版本，请点击此处。

如果你曾经有一个完全用.NET构建的项目，却还需要为azd钩子编写Bash脚本，你一定懂那种痛苦。当项目其他部分都是C#时，为什么要在pre-provisioning步骤中切换到Shell语法呢？

这个问题现在有了官方解决方案。Azure Developer CLI 刚刚发布了钩子的多语言支持，效果正如预期的那么好。

什么是钩子

钩子是在azd生命周期关键节点运行的脚本——预置配置之前、部署之后等。它们在azure.yaml中定义，无需修改CLI即可注入自定义逻辑。

此前只支持Bash和PowerShell。现在可以使用Python、JavaScript、TypeScript或.NET——azd会自动处理其余的一切。

检测机制

只需将钩子指向一个文件，azd就会从文件扩展名推断语言：

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

无需额外配置。如果扩展名不明确，可以添加kind: python（或相应语言）来明确指定。

各语言的重要细节

Python

在脚本旁边（或任意父目录中）放置requirements.txt或pyproject.toml，azd会自动创建虚拟环境、安装依赖并运行脚本。

JavaScript和TypeScript

同样的模式——在脚本附近放置package.json，azd会先运行npm install。对于TypeScript，使用npx tsx，无需编译步骤，也不需要tsconfig.json。

.NET

提供两种模式：

项目模式：如果脚本旁边有.csproj文件，azd会自动运行dotnet restore和dotnet build。
单文件模式：在.NET 10+上，独立的.cs文件可通过dotnet run script.cs直接运行，无需项目文件。

执行器特定配置

每种语言都支持可选的config块：

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

对.NET开发者的意义

钩子曾是基于azd的项目中最后一个强制语言切换的地方。现在，整个部署流水线——从应用代码到基础设施脚本再到生命周期钩子——都可以使用同一种语言。你可以在钩子中复用现有的.NET工具，引用共享类库，不再需要维护Shell脚本。

总结

这看起来是个小改动，但它切实减少了日常azd工作流程中的摩擦。钩子的多语言支持现已可用——查阅官方文章获取完整文档。

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 于 2026年4月18日 在马德里 Alcobendas 的 Kinépolis Diversia 举办。这是西班牙最大的社区驱动 Azure 活动，38位演讲者在3个平行分场分享 AI 代理、Azure 网络、Cosmos DB、Fabric、IoT、安全等主题。

活动时间为 08:30 至 18:30，包括主题演讲、茶歇、午餐和闭幕问答环节。

议程亮点

Domando Agentes de IA：使用 Azure AI Foundry 和 Azure API Management 的治理、工具和 API
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!：多代理系统实战
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

门票

注册为象征性捐赠 — 门票全部收入直接捐赠给 Plan International，支持全球儿童权利和平等。名额有限，请尽早报名。

Azure Tour 2026

除马德里外，Global Azure Tour 2026 还将在 萨拉戈萨、特内里费 和 塞维利亚 举办。

Aspire 13.2 新增 MongoDB EF Core 和 Azure Data Lake — 两个值得尝试的集成

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

Aspire 13.2 刚刚发布，带来了两个新的数据库集成，值得关注：MongoDB Entity Framework Core 和 Azure Data Lake Storage。如果你一直想在 Aspire 应用中使用 EF Core 操作 MongoDB，或者需要将 Data Lake 工作负载与服务发现连接起来，这个版本同时满足了这两个需求。

MongoDB 在 Aspire 中遇见 EF Core

这是让我最兴奋的一个。Aspire 支持 MongoDB 已经有一段时间了，但一直是原始驱动程序——没有 EF Core，没有 DbContext，没有对文档的 LINQ 查询。现在你可以获得完整的 EF Core 体验配合 MongoDB，加上 Aspire 的自动健康检查和服务发现。

配置遵循典型的 Aspire 模式。在你的 AppHost 中：

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

然后在消费项目中，添加 EF Core 集成：

dotnet add package Aspire.MongoDB.EntityFrameworkCore

注册你的 DbContext：

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

接下来就是标准的 EF Core 了。定义你的实体，像使用其他任何提供程序一样使用 DbContext。集成会在后台处理连接池、OpenTelemetry 跟踪和健康检查。

对于那些一直使用原始驱动程序操作 MongoDB 并手动配置连接字符串的 .NET 开发者来说，这是一个很好的体验提升。你可以获得完整的 EF Core 抽象，同时不会失去 Aspire 的服务发现。

Azure Data Lake Storage 加入阵营

第二个重大新增是 Azure Data Lake Storage (ADLS) 集成。如果你正在构建数据管道、ETL 流程或分析平台，现在可以像连接其他 Aspire 依赖项一样连接 Data Lake 资源。

在 AppHost 中：

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

在消费项目中：

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

不需要手动管理连接字符串，不需要四处寻找凭据。Aspire 负责资源的预配和注入。对于我们这些构建同时涉及运营数据和分析工作负载的云原生 .NET 应用的人来说，这让 Data Lake 在 Aspire 模型中真正成为了一等公民。

值得关注的小修复

除了主要功能之外，还有一些值得一提的改进：

MongoDB 连接字符串修复 — 数据库名称前的斜杠现在可以正确处理了。如果你之前有临时解决方案，现在可以移除了
SQL Server 导出 — Aspire.Hosting.SqlServer 现在导出额外的服务器配置选项，提供更精细的控制
模拟器更新 — ServiceBus 模拟器 2.0.0、App Configuration 模拟器 1.0.2，CosmosDB 的预览模拟器现在包含就绪检查
Azure Managed Redis — 现在默认使用 rediss://（Redis Secure），连接开箱即加密

最后一点虽然不起眼但很重要——默认加密的 Redis 意味着生产环境中少了一项需要配置的东西。

总结

Aspire 13.2 是一个增量版本，但 MongoDB EF Core 和 Data Lake 集成填补了真实的空白。如果你一直在等待 Aspire 中 MongoDB 的正式 EF Core 支持，或者需要 Data Lake 成为一等依赖项，升级到 13.2 试试看吧。aspire add 命令会为你生成所需的一切。

阅读完整的发行说明了解更多详情，查看集成库获取完整列表。

Azure Smart Tier 正式发布 — 无需生命周期规则即可自动优化 Blob Storage 成本

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

如果你曾经花时间调整 Azure Blob Storage 的生命周期策略，然后看着它们在访问模式变化时土崩瓦解，那这篇文章就是为你准备的。微软刚刚宣布了 Azure Blob 和 Data Lake Storage 的 smart tier 正式发布 — 这是一项完全托管的分层功能，根据实际使用情况自动在 hot、cool 和 cold 层之间移动对象。

Smart tier 实际做了什么

概念很简单：smart tier 持续评估存储账户中每个对象的最后访问时间。频繁访问的数据保持在 hot 层，不活跃的数据在 30 天后移到 cool 层，再过 60 天移到 cold 层。当数据被再次访问时，立即提升回 hot 层。循环重新开始。

无需配置生命周期规则。无需预测访问模式。无需手动调优。

在预览期间，微软报告称 超过 50% 的 smart tier 管理容量根据实际访问模式自动转移到了更冷的层级。对于大型存储账户来说，这是一笔可观的成本节省。

为什么这对 .NET 开发者很重要

如果你正在构建生成日志、遥测数据、分析数据或任何类型的不断增长的数据资产的应用 — 说实话，谁不是呢 — 存储成本会很快累积起来。传统的做法是编写生命周期管理策略，测试它们，然后在应用的访问模式变化时重新调整。Smart tier 完全消除了这个工作流。

一些实用的场景：

应用遥测和日志 — 调试时是 hot，几周后几乎不再访问
数据管道和 ETL 输出 — 处理期间频繁访问，之后大多处于 cold 状态
用户生成内容 — 最近上传的是 hot，较老的内容逐渐变冷
备份和归档数据 — 偶尔因合规需要访问，大部分时间处于闲置状态

如何设置

启用 smart tier 是一次性配置：

新账户：在创建存储账户时选择 smart tier 作为默认访问层（需要区域冗余）
现有账户：将 blob 访问层从当前默认值切换到 smart tier

小于 128 KiB 的对象保持在 hot 层，不产生监控费用。其他所有对象按照标准 hot/cool/cold 容量费率计费，没有层级转换费用，没有提前删除罚金，没有数据检索成本。每个对象的月度监控费用涵盖编排服务。

需要了解的权衡

Smart tier 的分层规则是固定的（30 天 → cool，90 天 → cold）。如果你需要自定义阈值 — 比如某个特定工作负载在 7 天后移到 cool — 生命周期规则仍然是正确的选择。而且不要混用：避免对 smart tier 管理的对象使用生命周期规则，因为它们可能会产生冲突。

总结

这算不上革命性的改变，但它解决了一个实实在在的运维痛点。如果你管理着不断增长的 blob storage 账户，并且厌倦了维护生命周期策略，启用 smart tier 让 Azure 来处理吧。目前在几乎所有区域公有云区域都可以使用。

Azure上のAIエージェントはどこにホストすべき？実践的な判断ガイド

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

如果你现在正在用.NET构建AI代理，你可能已经注意到一件事：在Azure上托管它们的方式太多了。Container Apps、AKS、Functions、App Service、Foundry Agents、Foundry Hosted Agents——在你真正需要选择之前，每个都听起来合理。Microsoft刚刚发布了一份Azure AI代理托管综合指南来澄清这个问题，我想从.NET开发者的实践角度来拆解它。

六种选项速览

以下是我对这个版图的总结：

选项	最适合	你需要管理
Container Apps	无需K8s复杂性的完整容器控制	可观测性、状态、生命周期
AKS	企业合规、多集群、自定义网络	所有东西（这就是重点）
Azure Functions	事件驱动的短时代理任务	几乎不需要——真正的无服务器
App Service	简单的HTTP代理、可预测的流量	部署、扩展配置
Foundry Agents	通过门户/SDK的无代码代理	几乎不需要
Foundry Hosted Agents	托管基础设施上的自定义框架代理	仅你的代理代码

前四个是通用计算——你可以在上面运行代理，但它们不是为此设计的。最后两个是代理原生的：它们将对话、工具调用和代理生命周期理解为一等概念。

Foundry Hosted Agents——.NET代理开发者的最佳选择

这是引起我注意的地方。Foundry Hosted Agents正好处于中间位置：你获得运行自己代码的灵活性（Semantic Kernel、Agent Framework、LangGraph——随便什么），但平台处理基础设施、可观测性和对话管理。

关键部分是Hosting Adapter——一个将你的代理框架连接到Foundry平台的薄抽象层。对于Microsoft Agent Framework，看起来是这样的：

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

这就是你的整个托管方案。适配器自动处理协议转换、通过server-sent events的流式传输、对话历史和OpenTelemetry追踪。不需要自定义中间件，不需要手动配置。

部署真的很简单

我以前在Container Apps上部署过代理，虽然可以工作，但最后你会写很多胶水代码来处理状态管理和可观测性。使用Hosted Agents和azd，部署是：

# 安装AI代理扩展
azd ext install azure.ai.agents

# 从模板初始化
azd ai agent init

# 构建、推送、部署——完成
azd up

这个单独的azd up会构建你的容器、推送到ACR、配置Foundry项目、部署模型端点并启动你的代理。五个步骤压缩成一个命令。

内置对话管理

这是在生产中节省最多时间的部分。不需要构建自己的对话状态存储，Hosted Agents原生处理：

# 创建持久对话
conversation = openai_client.conversations.create()

# 第一轮
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# 第二轮——上下文被保留
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

不需要Redis。不需要Cosmos DB会话存储。不需要自定义中间件来序列化消息。平台直接处理了。

我的决策框架

在审查了所有六个选项之后，这是我的快速心智模型：

需要零基础设施？ → Foundry Agents（门户/SDK，无容器）
有自定义代理代码但想要托管主机？ → Foundry Hosted Agents
需要事件驱动的短期代理任务？ → Azure Functions
需要不用K8s的最大容器控制？ → Container Apps
需要严格合规和多集群？ → AKS
有流量可预测的简单HTTP代理？ → App Service

对于大多数使用Semantic Kernel或Microsoft Agent Framework构建的.NET开发者来说，Hosted Agents可能是正确的起点。你能获得scale-to-zero、内置OpenTelemetry、对话管理和框架灵活性——无需管理Kubernetes或搭建自己的可观测性栈。

总结

Azure上的代理托管格局正在快速成熟。如果你今天要开始一个新的AI代理项目，我会在习惯性地使用Container Apps或AKS之前认真考虑Foundry Hosted Agents。托管基础设施节省实际时间，而hosting adapter模式让你保留框架选择。

查看Microsoft的完整指南和Foundry Samples仓库获取可运行的示例。

KubeCon Europe 2026：.NET 开发者真正需要关注的内容

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

你知道那种感觉吗？一个巨大的公告文章出来了，你一边滚动一边想"不错，但这对我到底有什么改变"？这就是我每个 KubeCon 季的状态。

微软刚刚发布了他们的 KubeCon Europe 2026 完整总结——出自 Brendan Burns 本人之手——说实话？这次有真正的干货。不只是功能清单，而是真正改变你在生产环境中运维方式的运营改进。

让我来梳理一下对我们 .NET 开发者真正重要的内容。

不用付服务网格税的 mTLS

服务网格的问题在于：每个人都想要安全保障，没人想要运营负担。AKS 终于在弥补这个差距了。

Azure Kubernetes Application Network 给你提供了双向 TLS、应用感知授权和流量遥测——不需要部署一个带 sidecar 的重型 mesh。结合 Advanced Container Networking Services 中的 Cilium mTLS，你可以获得使用 X.509 证书和 SPIRE 身份管理的加密 pod 间通信。

这在实践中意味着什么：你的 ASP.NET Core API 与后台 worker 通信，你的 gRPC 服务互相调用——全部在网络层加密和身份验证，零应用代码更改。这意义重大。

对于从 ingress-nginx 迁移的团队，还有 Meshless Istio 的 Application Routing 全面支持 Kubernetes Gateway API。无 sidecar。基于标准。并且发布了 ingress2gateway 工具用于增量迁移。

不再是事后想到的 GPU 可观测性

如果你在 .NET 服务旁运行 AI 推理（说实话，谁现在还没开始？），你可能遇到过 GPU 监控盲区。CPU/内存仪表板很棒，然后 GPU 部分…没有手动配置导出器就什么都没有。

AKS 现在原生暴露 GPU 指标到托管的 Prometheus 和 Grafana。同样的技术栈，同样的仪表板，同样的告警管道。无需自定义导出器，无需第三方代理。

在网络方面，增加了 HTTP、gRPC 和 Kafka 流量的逐流可见性，配合一键 Azure Monitor 体验。IP、端口、工作负载、流方向、策略决策——全部在内置仪表板中。

让我看了两遍的是：agentic container networking 添加了一个 Web UI，你可以用自然语言询问集群的网络状态。“为什么 pod X 无法到达服务 Y？"→ 从实时遥测获取只读诊断。凌晨两点真的很有用。

不需要博士学位的跨集群网络

多集群 Kubernetes 历来是"自带网络胶水"的体验。Azure Kubernetes Fleet Manager 现在通过托管 Cilium 集群网格提供跨集群网络：

AKS 集群间的统一连接
用于跨集群发现的全局服务注册表
集中管理配置，而不是每个集群重复

如果你为了弹性或合规在多个区域运行 .NET 微服务，这替代了很多脆弱的自定义胶水。West Europe 的服务 A 可以通过网格发现和调用 East US 的服务 B，使用一致的路由和安全策略。

不需要勇气的升级

说实话——生产环境中的 Kubernetes 升级是有压力的。“升级然后祈祷"一直是太多团队的实际策略，也是集群版本落后的主要原因。

两个新功能改变了这一点：

Blue-green 代理池升级 用新配置创建一个并行节点池。验证行为，逐步转移流量，保持干净的回滚路径。不再在生产节点上进行就地变更。

代理池回滚 允许你在升级出问题后将节点池恢复到之前的 Kubernetes 版本和节点镜像——无需重建集群。

两者结合，终于给运维人员提供了对升级生命周期的真正控制。对于 .NET 团队来说很重要，因为平台速度直接控制你能多快采用新的运行时、安全补丁和网络能力。

AI 工作负载成为 Kubernetes 一等公民

上游开源工作同样重要。Dynamic Resource Allocation (DRA) 刚在 Kubernetes 1.36 中 GA，使 GPU 调度成为真正的一等功能而不是变通方案。

值得关注的项目：

项目	作用
AI Runway	推理的通用 Kubernetes API——不懂 K8s 也能部署模型，带 HuggingFace 发现和成本估算
HolmesGPT	云原生的智能体故障排除——现在是 CNCF Sandbox 项目
Dalec	带 SBOM 生成的声明式容器镜像构建——构建阶段减少 CVE

方向很明确：你的 .NET API、Semantic Kernel 编排层和推理工作负载应该都运行在一个一致的平台模型上。我们正在接近。

这周我会从哪里开始

如果你在为团队评估这些变化，这是我真诚的优先级列表：

先搞可观测性——在非生产集群中启用 GPU 指标和网络流日志。看看你一直错过了什么。
测试 blue-green 升级——在下次生产集群升级前测试回滚工作流。建立对流程的信心。
试点身份感知网络——选择一个内部服务路径并用 Cilium 启用 mTLS。测量开销（剧透：很小）。
评估 Fleet Manager——如果你运行超过两个集群，跨集群网络光减少自定义胶水就能回本。

小实验，快反馈。这永远是正确的做法。

总结

KubeCon 公告可能让人应接不暇，但这批更新确实为 AKS 上的 .NET 团队带来了实质性改变。更好的网络安全（无 mesh 开销）、真正的 GPU 可观测性、更安全的升级以及更强大的 AI 基础设施支撑。

如果你已经在用 AKS，现在是加强运营基准的好时机。如果你计划将 .NET 工作负载迁移到 Kubernetes——平台刚刚变得更加适合生产环境了。