本会动态

IPFS和HUGO:分布式存储应用于网站构建
发布时间:2019-07-12 15:25:55来源:天禧棋牌-棋牌游戏可以提现的-最火的棋牌手游排行榜点击:21

  以下内容由四块翻译实验室根据Alessandro Segala的文章《Hugo and IPFS: how this blog works》翻译并编辑

  学习IPFS的实际应用经验

  自2019年2月中旬以来,该网站博客With Blue Ink,已通过IPFS和Cloudflare分布式Web网关提供服务。

  

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

  自从迁移到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

  Hugo是最受欢迎的开源静态站点生成器之一。凭借其惊人的速度和灵活性,Hugo使建筑网站再次变得有趣。

  With 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 gem。Hugo不仅在构建网站方面更快(实际上,感觉几乎是即时的),而且由于它是一个单独的,自包含的二进制文件,它在CI环境中的安装速度也更快。我的CI构建从五分钟缩减到少于一分钟。此外,Hugo拥有许多强大而有趣的功能,并且得到了积极的维护。

  认识IPFS

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

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

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

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

  

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

  我们来看看这个架构

  博客的架构相对简单:

  

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

  构建完成后,AzurePipeline将触发自动发布任务。发布渠道有两个阶段(可以在其他IPFS文章中了解如何配置它们):

  1.将文件复制到其中一个IPFS 虚拟机中,然后通过SSH调用ipfs-cluster-ctl pin add命令将文档添加到集群并在所有节点上将其复制。

  2.对Cloudflare API进行REST调用以更新DNSLink,这是一个TXT DNS记录_dnslink.withblue.ink,其中包含网站的IPFS哈希值。

  当第一阶段自动开始时,在第二阶段可以运行之前,入口需要管理员(我!)进行手动批准。这让我可以测试并确保网站通过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核虚拟机提供足够的CPU;但是,如果您正在运行IPFS群集,则需要2 GB的内存。像我一样添加三个节点可能会有点超负荷(但这是一次很棒的学习经历 - 非常有趣)。

  网站中的所有网址都必须是相对的。我在上一篇关于IPFS的文章中详细解释了这一点。简而言之,因为用户可以从多个基本URL访问你的网站(例如,https://withblue.ink/,https:///ipns/withblue.ink或https:///ipfs/),不能在HTML页面中使用绝对URL。这也是我不得不从jekyll换到hugo的主要原因。

  正如我上面所写,大多数用户不直接通过IPFS浏览网站,而是通过Cloudflare浏览网站。这意味着我们的实际正常运行时间取决于Cloudflare。虽然到目前为止Cloudflare对我来说效果不错,但他们没有为他们的免费服务提供SLA,而且如果IPFS网关有SLA则会变得含糊不清。可悲的是,我目前没有关于使用IPFS的访问者数据,但我认为他们只占少数。

  使用Cloudflare IPFS网关时,某些内容不可用,包括:

  无法设置自定义HTTP标头。在两种情况下,这可能是个问题:当您想要启用HSTS(根本就没有办法)时,以及当您想手动设置内容类型时(IPFS网关从文件扩展名中确定内容类型并使用某些启发式内容类型,查看此问题)。

  没有自定义404页面。

  没有服务器端分析,甚至没有通过Cloudflare。您唯一的选择是使用Google分析等托管解决方案。

  我注意到的另一个问题是,当您更改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上缓存的问题没有改善,我正在想办法处理。