8BTCCI: 11449.94 +0.03% 8BTCVI: 5309.94 -0.33% 24H成交额: ¥4014.68亿 +3.02% 总市值: ¥16126.36亿 -0.07%
Hugo和IPFS:这个博客是如何工作的(并且可以立即扩展到5000%的峰值!)

Hugo和IPFS:这个博客是如何工作的(并且可以立即扩展到5000%的峰值!)

IPFS星际大陆 发布在 海盗号 235509

有趣的事实:如果您正在阅读本文,那么您正在使用分布式网络。自2019年2月中旬以来,这个博客With Blue Ink已通过IPFS和Cloudflare分布式Web网关提供服务。

去年11月,我发表了关于如何从IPFS运行静态网站的博文。我已经以自己和家人使用的方式运行了几个应用程序,我觉得是时候迁移我的博客了。由于我处理了一些问题,其中一些问题在下面进行了解释,这比预期的要长一些,但是大约一个月前我翻转了(DNS)交换机并最终关闭了托管博客的单实例虚拟机。

这个决定让我焦虑不安,但一个月的事情看起来几乎完全不错。

 

黑客新闻+ Reddit效果

 

自从迁移到IPFS以来,发生了一些事情。

一个多星期前,我发布了一篇关于规范化Unicode字符串重要性的博客文章,这些字符串几乎是病毒式的,在Hacker News首页的第4位达到顶峰,并获得了r /编程的头把交椅,并被纳入一些热门时事通讯。(感谢您的热爱和精彩的讨论!

然后,在周一我发布了一个新的开源项目Hereditas,该项目在Reddit上也有很好的曝光率。

对于过去每月平均少于3,000次页面浏览量的博客,这种情况发生了:

3月13日星期三,交通量比一周前的同一天高出5,060%。在一天之内,使用Blue Ink的页面浏览量几乎是之前一个月的两倍。

尽管流量显着增加,但这是为网站提供服务的主要IPFS节点的CPU使用情况:

没有。

由于通过IPFS分发内容并通过Cloudflare CDN提供服务,With Blue Ink在5,000%的流量高峰后几乎没有对性能和可用性的影响。

不仅如此:测试表明,该网站对于全世界的用户来说一直非常快。

 

遇见Hugo

 

使用Blue Ink是一个静态网站。我在一堆Markdown文件中编写内容,然后使用Hugo生成HTML页面。整个网站(内容,主题,脚本)是开源的,它发布在GitHub的ItalyPaleAle / WithBlueInk上

三年前,当我开始使用这个博客时,我最初选择了另一个流行的静态网站生成器Jekyll。但是,当我正在努力迁移到IPFS时,我不得不用Hugo替换Jekyll,因为Jekyll不支持相对URL。使用Jekyll时,所有生成的URL都/以固定的基本URL 开头,当您通过基本URL是动态的IPFS浏览内容时,这不起作用(有关其重要性的详细信息,请参阅我之前的IPFS指南)。

迁移到Hugo带来了一些其他巨大的好处。Hugo是一个用Go编写的小应用程序,它比Jekyll快得多,它是一个Ruby宝石。不仅Hugo在构建网站方面更快(实际上,感觉几乎是即时的),但由于它是一个单独的,自包含的二进制文件,它在CI环境中的安装速度也更快。我的CI构建从五分钟到不到一分钟。此外,Hugo拥有许多强大而有趣的功能,并且它得到了积极的维护。

 

认识IPFS

 

星际文件系统,或IPFS,是分布在一个对等网络的方式不可改变的内容的协议和网络。

如果您不熟悉IPFS,请将其视为分布式CDN。启动IPFS节点后,您可以使用它在IPFS网络上发布文档,世界各地的其他人可以直接向您请求。最好的事情是,只要有人向您请求文件,他们就会立即开始将其播种给其他人。这意味着当使用IPFS时,文档越流行,它就越复制,因此其他人下载它的速度就越快。

通过IPFS分发文件可以非常快速且非常有弹性。由于分布式和点对点,IPFS网络可以抵御审查和DDoS攻击。

此外,IPFS上的所有文档都通过其内容的哈希来解决,因此它们也是防篡改的:如果有人要更改文件中的单个位,则整个哈希值会发生变化,因此地址会有所不同。

IPFS的问题在于它只是一种内容分发协议,而不是存储服务。它更类似于CDN而不是NAS。我仍然需要一些服务器,我目前有三台服务器,配置在具有IPFS集群的集群中。它们是Azure上小巧,便宜的B1ms VM(1个vCPU,2 GB RAM),运行于世界各地的三个不同地区。您可以在上一篇文章中阅读我如何设置它们。

由于使用IPFS,这种简单且相对便宜的解决方案能够提供“100%”正常运行时间并且具有DDoS抗性。这些网站会自动在群集中的所有节点上进行复制,这些节点会立即开始播种,并且随着地理位置分散的用户,虚拟机将在全球范围内获得极高的速度。

 

我们来看看这个架构

 

博客的架构相对简单:

将一些新代码推送到GitHub上的主分支会触发Azure管道中的自动构建,该管道克隆源代码并运行Hugo来构建网站(它都是免费的!)。您可以azure-pipelines.yaml在repo 中的文件中看到配置。

构建完成后,Azure管道将触发自动发布作业。该释放管道有两个阶段(你可以阅读我给其他IPFS文章中配置它们):

  1. 将文件复制到其中一个IPFS VM中,然后通过SSH调用该ipfs-cluster-ctl pin add命令将文档添加到群集并在所有节点上复制它们。
  2. 对Cloudflare API进行REST调用以更新DNSLink,这是一个_dnslink.withblue.ink包含网站IPFS哈希的TXT DNS记录。
当第一阶段自动发生时,在第二阶段可以运行之前,需要管理员(我!)进行手动批准。这让我可以测试并确保网站通过IPFS(使用其完整哈希)成功加载,然后将其提供给任何访问者withblue.ink。

发布管道完成后,运行IPFS守护程序的任何人都可以访问此IPFS地址的网站:

/ipns/withblue.ink
这很简单,也很容易记住。但它仅适用于那些运行IPFS守护程序或知道如何使用网关的人(例如,尝试使用gateway.ipfs.io)。

如果您想要尝试IPFS,Firefox和Chrome 的ipfs-companion扩展可让您轻松浏览IPFS网络,使用外部网关或内置网关。

大多数用户仍在使用HTTP和普通的网络浏览器,这就是Cloudflare提供帮助的时候。通过其(免费)分布式Web网关,Cloudflare网络中的边缘节点可以充当IPFS网关,并提供通过IPFS网络发布的文档。设置非常简单,如果Cloudflare管理您的DNS,由于CNAME扁平化,您也可以使用根域(例如withblue.ink without www)!

 

从真正的经验中学习

 

我已经通过IPFS服务网络应用程序六个月了,这个博客已经有一个多月了。总的来说,我有一个积极的经验,但如果您正在考虑自己使用IPFS,我已经学到了一些值得分享的东西。

 

什么进展顺利

 

总的来说,依靠IPFS已经带来了一些有趣的好处。

  • 通过IPFS网络获得文档的“100%”正常运行时间。只要至少有一个同伴提供内容,因为它最近浏览过该网站(任何类型的客户端),或者已将其固定(我的三台服务器),就可以通过IPFS访问该博客。
  • 速度:通过IPFS访问网站的用户越多,其他人就越快。
  • 该网站也应该以自然的方式抵抗DDoS。
但实际上,大多数用户不通过IPFS访问此博客,而是通过Cloudflare网关通过HTTP(S)访问它。这仍然运作得相当好:
  • 由于IPFS中的每个文档都是不可变的,因此Cloudflare会在全球各个边缘节点中广泛缓存网站。只要DNSLink相同,就不需要CDN连接到上游服务器来检查新内容。来自全球多个地点的延迟测试显示了一致,快速的页面加载时间。当您的博客的首页在大约3秒钟内完全加载(包括图像),并且从地球的每个角落或多或少地保持一致的新缓存,这是非常令人印象深刻的。
  • 设置非常简单。除了将CNAME指向Cloudflare网关并要求他们为我的域启用TLS证书之外,事情才有效。无需配置高可用性,负载平衡,跨多个服务器复制内容等。
  • Cloudflare CDN也为您做了惊人的事情,包括支持HTTPS和HTTP / 2.0(SPDY!),gzipping响应等。

我学到了什么/可能会更好

 

HTTP本月已经三十岁了,而IPFS仍然是一项新技术。使用IPFS,有些东西的工作方式与我们习惯的不同,而其他东西根本就不起作用。

  • IPFS不是无服务器的 ; 它也绝对不是免费的。您确实需要至少一台服务器为您的数据播种。好消息是你不需要大型服务器。一个可扩展的1核VM提供足够的CPU; 但是,如果您正在运行IPFS群集,则需要2 GB的内存。像我一样添加三个节点可能是一种矫枉过正(但这是一次很棒的学习经历 - 非常有趣)。
  • 您网站中的所有网址都必须是相对的。我在上一篇关于IPFS的文章中详细解释了这一点。简而言之,因为用户可以从多个基本URL(在我的情况下https://withblue.ink/,https://<gateway>/ipns/withblue.ink或https://<gateway>/ipfs/<ipfs-hash>)访问您的网站,所以您不能在HTML页面中使用绝对URL。这也是我不得不从杰基尔换到雨果的主要原因。
  • 正如我上面所写,大多数用户不直接通过IPFS浏览网站,而是通过Cloudflare浏览网站。这意味着我们的实际正常运行时间取决于他们的。虽然到目前为止Cloudflare对我来说工作得很好,但他们没有为他们的免费服务提供SLA,而且如果IPFS网关有SLA则更不清楚。可悲的是,我目前没有关于有多少访问者使用IPFS的数据,但我认为他们只是少数几个。
  • 使用Cloudflare IPFS网关时,某些内容不可用,包括:
    • 无法设置自定义HTTP标头。在两种情况下这可能是一个问题:当您想要启用HSTS(根本就没有办法)时,以及当您想手动设置Content-Type(IPFS网关从文件扩展名确定内容类型并使用一些启发式方法时,请参阅这个问题)。
    • 没有自定义404页面。
    • 没有服务器端分析,甚至没有通过Cloudflare。您唯一的选择是使用Google Analytics等托管解决方案。
  • 我注意到的另一个问题是,当您更改DNSLink的值时,Cloudflare IPFS网关并不总是可靠地清除缓存。每个人都需要几个小时才能看到最新的内容。这是迄今为止我遇到的最大问题。
  • 更新DNSLink值后,可能会出现一些冷启动时间问题,第一页需要额外的几秒才能加载,但根据我的经验,这并不算太糟糕。发生这种情况是因为Cloudflare网关中的IPFS客户端需要遍历DHT以查找为您的内容提供服务的节点。一旦内容被复制,这就变得越来越快,到目前为止它不再是一个问题。
  • 最后,我在运行IPFS节点时遇到的一个问题是它可以使用相当多的带宽,只是为了使网络工作(甚至不用于提供你的内容!)。IPFS 0.4.19已经大大减轻了这一点,但我的Azure虚拟机仍在测量大约160GB /月的出站流量(IPFS为0.4.18 时超过400 GB)。
上述许多问题,包括缓存,冷启动时间,服务器端分析,自定义HTTP标头和404页面,都可以通过实施自定义IPFS网关来缓解,而不是依赖于Cloudflare。官方ipfs.io网站也是这样做的 ; 如果在Cloudflare上缓存的问题没有改善的话,我正在考虑这个问题。

原文作者:Alessandro Segala

原文链接:https://withblue.ink/2019/03/20/hugo-and-ipfs-how-this-blog-works-and-scales.html

文章标签: IPFS
评论
登录 账号发表你的看法,还没有账号?立即免费 注册