部署 Azure CDN 的血泪经历

经过几个日夜的瞎折腾,终于把 1234.as 放在了 CDN上。起因是想要对外开放注册了,因此要对访问速度优化一下。

Cloudflare 的问题

想要使用 Cloudflare 必须要修改域名的 Name Server。Cloudflare 的 DNS 系统在界面和功能都堪称业界一流,就单说 CNAME Flattening 就非常的好用,支持这个功能的 DNS Provider 也没几家。还有就是解析速度快的飞起,修改解析记录后,本地网络几乎都是秒级响应。

最大的问题是在于中国境内复杂的网络环境下,Cloudflare 的优势荡然无存。无论从连接的稳定性还是速度都很差,往往不如直接访问源主机更快。

Cloudflare 适合以下的情况使用:

  1. 访客群体在中国大陆以外
  2. 网站经常经受高强度 DDos 攻击

满足以上任意一条,Cloudflare 都是很好的选择。其他情况下几乎都不是好的选择。

Google Cloud CDN 的问题

Google 的 CDN 只能给自己云上的实例使用,不支持外部源。这点让自己处于二线选手。

Windows Azure

Windows Azure 的优势和劣势也很明显。优势是他家的 CDN 部署后,在中国的访问速度非常快;劣势就是烦人的后台操作以及感人的价格。

就单 Azure 的操作界面来讲,功能和布局算是合理的。后台之所以烦人,是因为几乎所有的操作都需要等待时间。当你点击了任意的按钮,右上角的 Notifications 就开始转了起来。接下来你可以去上个厕所回来再喝个咖啡,然后它可能还在转。我一点也没有夸张。

想要在 Windows Azure CDN 中使用 APEX/ROOT 域名是一个高难度的操作。 我用了几天的时间才琢磨出来解决方法,期间一度想要放弃。

基本思路如下:

  1. 域名使用 Azure 的 DNS 服务
  2. @ 绑定 Azure resource,选择你的 CDN Endpoint
  3. 在 CDN Endpoint 中添加自定义域名,绑定 APEX
  4. 在 CDN Endpoint 中添加外部购买的自定义 SSL

以上是思路,而不是操作。如果你按照上边步骤去执行,会发现每一步操作可能都会遇到问题。

Endpoint 建立

关于 Endpoint,一定要选择 S1 Standard Verizon,而不是 S3。S1 是外部的 Verizon 供应商,S3 是微软自己的。在使用中发现,S1 功能比 S3 更多,对缓存规则能做更多的控制。使用 S3 后,Mastodon 系统出现了 401 Invalid Token 的错误。切换到 S1 则无此问题。考虑到两者目前是相同价格,强烈推荐不要使用 S1。

20897f5d30286770dbecddbc3a81c0d4.md.png]

在 CDN 的 Caching rules 中,必须要设定 Bypass caching for query strings,否则 mastodon 无法登录。对复杂交互的动态网站的缓存还是要尽可能的少,否则很容易遇到 WebSocket 和 token 方面的问题。

购买 SSL 时注意点

添加自定义 SSL,首先要去买一个 Azure 支持的 SSL 证书。虽然文档里有列出来支持哪些,但是坑爹的是对方写的是一些技术参数。当你去购买 SSL 证书的时候,你无法知道证书内部的细节,比如我们欣慰的看到了列表中包含了 Godaddy 的以下证书:

当你兴冲冲的去了 Godaddy 官网时,发现情况完全不对。几乎所有销售 SSL 的网站都不会列出来技术细节。你无法知道你选择的证书是否满足 Azure 变态的要求。

9faebd6a895bec7931c1290d6e58e1f5.md.png]

把证书导入到 Key vault 中

在 Key vault – Certificates 下,选择 Generate/Import,然后你可能悲哀地发现自己下载的 SSL 证书文件竟然无法导入。因为格式不对,Azure 只支持 .Pem 和 .Pfx 格式。只好再去复习一遍 SSL 证书各种格式的区别。

另外需要注意这里上传的证书文件,需要包含 Private Key 信息。

我购买的 Rapid SSL 供应商签发的证书文件中有 P7B 格式,使用了这个 SSL 格式转换网站 可以把 P7B 文件 + 证书链文件 + Private Key 文件转化为一个 Pfx 文件。

42e38a876ab92397241fbea148391da9.md.png

成功导入以后并没有万事大吉。你发现还需要为 CDN 添加刚才的 Key Valt 访问权限 。吃惊的是,这一切竟然无法在 Azure 界面完成,你需要下载 Powershell,然后敲一堆命令行(过程也并非一帆风顺会遇到隐含的设置)。如果不去搜索并翻看相关文档,你可能永远无法成功添加一个自定义 SSL。

我曾经想过去联系他们的客服,但是点击 Help 会引导你订购他们的 Basic Support。每月 29 刀会有 24 小时以内响应的 Email 支持。到这里我只能说 Azure 真的太高级了,设计之初就并不是给所有人使用的。

CDN 等待时间

当你验证 CNAME 记录时候,可能需要 30 分钟左右。当你上传并设置好 SSL 以后,部署到 CDN 最高要 30 个小时。总之,在 Azure 中进行某一操作以后,往往不会立即生效。给我隐隐的感觉就好像他们会把每一步操作拿去给领导签字一样,确认以后才放行。这还是云计算服务吗?每当页面转圈圈的时候,就非常怀念 AWS。

截至目前,SSL 状态依然是 Deploying certificate to CDN POPs。使用云计算尤其是 Azure CDN,真的要保持好心态不能急躁。

== 部署成功 5 个小时以后更新

本来以为成功部署了就没问题了。截至现在还是遇到 SSL 证书错误问题。Azure 并没有把我的自定义域名放到 CDN 上,目前证书还是 sni.msft.default.wpc.edgecastcdn.net 这里的。我看到了<<有同样的人遇到此问题>>,有的是部署成功后几小时内才成功的,有的是部署5天后还是错误。这里只能拼人品了……

99579fd7effb5c369343b26b1d80e26d.md.png

== 部署成功 15 个小时以后更新

大约昨日凌晨 4:00 am 左右提交证书,早上 10:00 ~12:00 am 点之间 Azure 后台显示部署成功。但是实际证书变得可用还得十多个小时。在晚上 8:00 pm 左右微软的 edge 浏览器开始认出来了自定义的证书,再往后到了 11:00 pm 查看的时候各浏览器中 SSL 证书已经完全正常了。

从提交证书到正常使用,前前后后需要将近 20 个小时!我推断这 20 个小时中必然会有一些人工审批的过程,否则按照计算机系统处理速度和国际互联网传输速度,不可能在同步到个节点的过程中花费如此长的时间。微软成功的把大公司的官僚作风带入了自家的云计算中。相比 AWS,部分新注册用户或者敏感服务比如 SES 会有明确的提示,告诉你需要填表申请并且人工审核,你自己可以对完成的时间做到心里有数。Azure 则不会告诉你哪些操作有隐形的审核步骤,只会告诉你一个大概时间,但是实际需要的时间往往比他们预估时间要更久。

这次的经历告诉我们:如果要在生产系统上部署 Azure CDN 并且使用 SSL,一定要慎重考虑如何做好过度,否则等待 SSL 生效的时候流量强行中断,老板可能已经把你炒鱿鱼了。

本博暂不支持评论,如果有问题,请到 1234.as 与我私信交流。