cdn迁移需要作什么_现实世界中的云迁移：CDN是对旧版应用程序的轻松改进

cdn迁移需要作什么

I'm doing a quiet backend migration/update to my family of sites. If I do it right, there will be minimal disruption. Even though I'm a one person show (plus Mandy my podcast editor) the Cloud lets me manage digital assets like I'm a whole company with an IT department. Sure, I could FTP files directly into production, but why do that when I've got free/cheap stuff like Azure DevOps.

我正在对我的网站家族进行安静的后端迁移/更新。 如果我做对了，将不会造成太大的干扰。 即使我是一个人表演(加上播客编辑Mandy)，云还是可以让我像管理IT部门的整个公司一样管理数字资产。 当然，我可以将FTP文件直接输入生产环境，但是当我有了Azure DevOps之类的免费/廉价产品时，为什么要这样做呢？

As I'm one person, I do want to keep costs down whenever possible and I've said so in my "Penny Pinching in the Cloud" series. However, I do pay for value, so I'll try to keep costs down whenever possible, but I will pay for things I feel are useful or provide me with a quality product and/or save me time and hassle. For example, Azure Pipelines gives one free Microsoft-hosted CI/CD pipeline and 1 hosted job with 1800 minutes a month. This should be more than enough for my set up.

作为一个人，我确实想尽可能降低成本，我在“ Penny Pinching in the Cloud ”系列中已经说过。 但是，我确实为价值付出了代价，所以我会尽力降低成本，但是我将为我认为有用的事情或为我提供优质产品和/或节省时间和麻烦的事情付出代价。 例如， Azure Pipelines提供一个免费的Microsoft托管的CI / CD管道和一个托管的作业，每月1800分钟。 这对于我的设置来说已经足够了。

Additionally, sometimes I'll shift costs in order to both save money and improve performance as when I moved my Podcast's image hosting over to an Azure CDN in 2013. Fast forward 6 years and since I'm doing this larger migration, I wanted to see how easy it would be to migrate even more of my static assets to a CDN.

此外，有时我会转移成本以节省成本并提高性能，就像我在2013年将Podcast的图像托管移到Azure CDN上一样。 快进6年了，由于我正在进行较大的迁移，所以我想看看将更多的静态资产迁移到CDN会多么容易。

Make a Storage Account and ensure that its Access Level is Public if you intend folks to be able to read from it over HTTP GETs.

如果您希望人们能够通过HTTP GET从中读取存储帐户，请创建一个存储帐户并确保其访问级别为“公开”。

With in the Azure Portal you can make a CDN Profile that uses Microsoft, Akamai, or Verizon for the actual Content Distribution Network. I picked Microsoft's because I have experience with Akamai and Verizon (they were solid) and I wanted to see how the new Microsoft one does. It claims to put content within 50ms of 60 countries.

使用Azure门户，您可以制作一个将Microsoft，Akamai或Verizon用于实际内容分发网络的CDN配置文件。 我之所以选择Microsoft，是因为我在Akamai和Verizon(他们很扎实)方面有丰富的经验，我想看看新的Microsoft如何做。 它声称将内容放置在60个国家/地区的50ms之内。

You'll have a CDN endpoint host name that points to an Origin. That Origin is the Origin of your content. The Origin can be an existing place you have stuff so the CDN will basically check there first, cache things, then serve the content. Or it can be an existing WebApp or in my case, Storage.

您将拥有一个指向原点的CDN终结点主机名。 起源是您内容的起源。 Origin可以是您拥有东西的现有位置，因此CDN基本上会先检查那里，缓存内容，然后提供内容。 也可以是现有的WebApp，或者我可以是存储。

I didn't want to make things too complex, so I have a single Storage Account with a few containers. Then I mapped custom endpoints for both my blog AND my podcast, but they share the same storage. I also took advantage of the free SSL Certs so images.hanselman.com and images.hanselminutes.com are both SSL. Gotta get those "A" grades from https://securityheaders.com right?

我不想让事情变得太复杂，所以我只有一个存储帐户和几个容器。 然后，我为博客和播客映射了自定义端点，但是它们共享相同的存储。 我还利用了免费的SSL证书，因此images.hanselman.com和images.hanselminutes.com都是SSL。 要从https://securityheaders.com获得那些“ A”等级，对吗？

Then, just grab the Azure Storage Explorer. It's free and cross platform. In fact, you can get Storage Explorer as an app that runs locally, or you can check it out in the Azure  Portal/in-browser as well, here. I've uploaded all my main assets (images used in my CSS, blog, headers, etc).

然后，只需抓住Azure存储资源管理器。 它是免费的跨平台平台。 实际上，您可以将Storage Explorer作为在本地运行的应用程序获取，也可以在Azure门户/浏览器中将其检出。 我已经上传了所有主要资产(CSS，博客，标题等中使用的图像)。

I've settled on a basic scheme where anything that was "/images/foo.png" is now "https://images.hanselman.com/blog/foo.png" or /main/ or /podcast/ depending on who is using it. This made search and replaces reliable and easy.

我已经确定了一个基本方案，其中“ /images/foo.png”现在变为“ https://images.hanselman.com/blog/foo.png”或/ main /或/ podcast /，具体取决于谁正在使用它。 进行搜索并替换可靠且容易的方法。

It's truly a less-than-an-hour operation to enable a CDN on an existing site. While I've chose to use Azure Storage as my backing store, you can just use your existing site's /images folder and just change your markup to pull from the CDN's URL. I recommend you make a simple cdn.yourdomain.com or images.yourdomain.com. This can also easily be enabled with a CNAME in less than an hour. Having your images at another URL via a subdomain CNAME also allows for even more download parallelism from the browser.

在现有站点上启用CDN确实是少于一个小时的操作。 尽管我选择使用Azure存储作为我的后备存储，但是您可以只使用现有站点的/ images文件夹，也可以更改标记以从CDN的URL中提取。 我建议您制作一个简单的cdn.yourdomain.com或images.yourdomain.com。 您也可以在不到一个小时的时间内使用CNAME轻松启用此功能。 通过子域CNAME将图像放在另一个URL上，还可以从浏览器中获得更多的下载并行性。

This is all in my Staging so you won't see it quite yet until I flip the switch on the whole migration.

这一切都在我的暂存中，因此直到我在整个迁移过程中进行切换之前，您都不会看到它。

探索动态图像内容的未来可能性 (Exploring future possibilities for dynamic image content)

I haven't yet moved all my blog content images (a few gigs, but many thousands of images) to a CDN as I don't want to change my existing publishing workflow with Open Live Writer. I'm considering a flow that keeps the images uploading to the Web App but then using the Custom Origin Path options in the Azure CDN that will have images get picked up Web App then get served by the CDN. In order to manage 17 years of images though, I'd need to catch URLs like this:

我还没有将我所有的博客内容图像(几张演出，但数千张图像)都移到CDN上，因为我不想使用Open Live Writer更改现有的发布工作流程。 我正在考虑将图像上传到Web App的流程，但随后使用Azure CDN中的“自定义来源路径”选项，该操作将使图像被Web App接收，然后由CDN提供服务。 为了管理17年的图像，我需要捕获如下URL：

https://hanselmanblogcontent.azureedge.net/Windows-Live-Writer/0409a9d5fae6_F552/image_9.png

https://hanselmanblogcontent.azureedge.net/Windows-Live-Writer/0409a9d5fae6_F552/image_9.png

and redirect them to

并将其重定向到

https://images.hanselman.com/blog/content/binary/Windows-Live-Writer/0409a9d5fae6_F552/image_9.png

https://images.hanselman.com/blog/content/binary/Windows-Live-Writer/0409a9d5fae6_F552/image_9.png

As I see it, there's a few options to get images from a GET of /blog/content/binary to be served by a CDN:

正如我所看到的，有一些选项可以从/ blog / content / binary的GET获取图像以由CDN提供服务：

• Dynamically Rewrite the URLs on the way OUT (as the HTML is generated)

  在OUT途中动态重写URL(生成HTML时)

  • CPU expensive, but ya it's cached in my WebApp
    CPU昂贵，但是它已缓存在我的WebApp中

• Rewriting Middleware to redirect (301?) requests to the new images location

  重写中间件以将请求重定向(301？)到新图像位置

  • Easiest option, but costs everyone a 301 on all image GETs
    最简单的选择，但在所有图像GET上花费每个人301

• Programmatically change the stored markup (basically forloop over my "database," search and replace, AND ensure future images use this new URL)

  以编程方式更改存储的标记(基本上是在“数据库”上进行forloop，搜索和替换，并确保以后的图像使用此新URL)

  • A hassle, but a one time hassle
    麻烦，但一次麻烦
  • Not sure about future images, I might have to change my publishing flow AND run the process on new posts occasionally.
    不确定将来的图片，我可能不得不更改发布流程并偶尔在新帖子上运行该过程。

What are your thoughts on if I should go all the way and manage EVERY blog image vs the low hanging fruit of shared static assets? Worth it, or overkill?

如果我应该一路去管理每个博客图像，而不是共享静态资产的空前成果，您对此有何想法？ 值得，还是过度杀伤？

The learning process continues!

学习过程继续！

Sponsor: Seq delivers the diagnostics, dashboarding, and alerting capabilities needed by modern development teams - all on your infrastructure. Download now.

赞助商： Seq在您的基础架构上提供现代开发团队所需的诊断，仪表板和警报功能。 立即下载。

翻译自: https://www.hanselman.com/blog/real-world-cloud-migrations-cdns-are-an-easy-improvement-to-legacy-apps

cdn迁移需要作什么