iamwillsoto/azure-static-website-blob-frontdoor

# 通过 Front Door 在 Azure Blob Storage 上交付 Azure 静态网站 ## 概述 本项目在 Azure 上交付一个面向公众的静态网站，且无需依赖基于服务器的基础设施。Azure Blob Storage 静态网站托管作为源站，Azure Front Door 提供公共边缘层，基于 SAS 的验证演示了对私有存储对象的受控访问。 其结果是形成了一种精益的、云原生的交付模式，完全契合静态 Web 工作负载的实际需求：低运维开销、安全的公共访问，以及公共内容交付与受限对象访问之间的清晰分离。 ## 业务背景 对于静态营销网站而言，虚拟机、Web 服务器管理、补丁更新或持久计算的成本和运维负担是不合理的。将其托管在传统基础设施上，会为只需持久存储和可靠内容交付的工作负载增加不必要的复杂性。 本实现使用 Azure 托管服务取代了该模型。Blob Storage 托管站点，Front Door 负责安全的公共交付和边缘缓存，并使用 SAS 来验证对私有 blob 内容的临时访问，而不会将其广泛暴露。 ## 解决的问题 - 消除了在服务器基础设施上运行静态网站的需求 - 通过使用 Azure 托管服务降低了运维开销 - 通过 Azure Front Door 在边缘强制执行 HTTPS - 通过边缘缓存改善交付行为 - 演示了使用 SAS 访问私有存储对象的受控访问模式 ## 实现总结 该站点被部署到启用了静态网站托管的 Azure 存储账户中，并在 `$web` 容器中将 `index.html` 配置为默认文档。Azure Front Door Standard 被置于存储托管的站点之前，并配置为使用静态网站端点作为源站。公共流量通过 Front Door 路由，并将 HTTP 重定向到 HTTPS，同时通过更新站点内容和清除边缘缓存来验证缓存行为。 随后，使用一个单独的私有容器来验证受限的 blob 访问。直接匿名访问私有对象按预期失败，而基于 SAS 的 URL 则提供了对相同内容的临时、限定范围的访问。 ## 使用的服务 - Azure Resource Group - Azure 存储账户 - Azure Blob Storage 静态网站托管 - Azure Front Door Standard - 共享访问签名 (SAS) ## 架构概要 - Azure 存储账户通过 `$web` 容器托管静态站点 - Azure Front Door 提供公共端点和边缘路由层 - 在 Front Door 处强制执行 HTTPS 重定向 - 通过更新和清除测试验证缓存刷新行为 - 使用私有 blob 容器通过 SAS 验证受限访问 ## 验证总结 - Azure 静态网站端点成功提供了 Crestline Bank 站点服务 - Azure Front Door 在启用 HTTPS 重定向的情况下公开提供了该站点服务 - 内容更新在源站得到体现，并在缓存清除后通过 Front Door 得到验证 - 未经授权对私有 blob 的直接访问失败 - 通过 SAS 成功实现了对私有 blob 的临时访问 ## 关键说明 - 公共站点通过 `$web` 容器中的 Azure 静态网站托管提供服务 - Front Door 针对静态网站源站进行配置，而不是标准的 blob 服务端点 - 缓存传播延迟被视为符合预期的 CDN 行为，并通过清除测试进行了验证 - SAS 验证针对私有容器执行，以演示受控访问而无需将对象公开 - 文档中引用的任何 SAS token 都应在发布前予以脱敏处理 ## 成果 本项目演示了一种简洁的 Azure 模式，使用托管服务而非服务器基础设施来交付静态网站。它减轻了运维负担，改善了公共交付态势，并验证了针对私有存储内容的独立访问模型。该设计简单、合理，且完全契合静态 Web 工作负载的需求。

标签：Azure, Azure Front Door, Azure服务, Blob Storage, CDN, HTTPS重定向, IaT, SAS令牌, SEO优化, Streamlit, 云存储, 低运维, 内容分发网络, 前端托管, 后端开发, 基础设施自动化, 私有内容, 网络分发, 网络安全, 访问控制, 边缘缓存, 隐私保护, 静态网站, 静态网页托管, 面向公众