0%

将博客部署到星际文件系统 IPFS

前文中,我介绍了如何通过 Netlify 实现持续集成地自动部署 Hexo 博客。使用这种方式部署静态博客比直接使用hexo deploy命令部署到 GitHub Pages 上更为方便,省去了本地的一些环境配置以及各种插件的安装。前段时间看到一些博主将自己的网站改为部署到星际文件系统 IPFS 上。作为一个爱折腾的人,当然也要尝试一下这种新鲜的操作。在这篇文章中,我将主要介绍如何将静态博客以持续集成和原生部署两种方式部署到 IPFS 上,以及总结我在操作中遇到的一些问题。

前言

星际文件系统( InterPlanetary File System,IPFS)是分布式互联网(Distributed Web),是点对点( Peer-to-Peer,P2P)的超媒体协议,去中心化,以构建更快、更安全、更开放的网络,将我们带向 Web 3.0 时代 。

在 IPFS 系统中,内容会分块存放(如果内容很小就会直接存在 DHT 中),并分散存储在 IPFS 网络中的节点上(不过目前的 IPFS 实现,一个节点会完整保存内容的所有区块)。系统会给内容的每一个块计算哈希值,然后把所有块的哈希值拼凑起来,再计算一次哈希值,从而得到最终的哈希值。同时每个节点会维护一张 DHT(分布式哈希表),包含数据块与目标节点的映射关系。

在 IPFS 中是通过哈希去请求文件的,它就会使用这个分布式哈希表找到文件所在的节点,取回文件根据哈希重新组合文件(同样也会验证文件)。

本文主要介绍的博客部署方式是借助于 Netlify 通过持续集成的方式部署,无需在你的计算机上安装 IPFS。另外,原生部署的方式也会在文章中介绍,但我自己并没有认真研究操作过。关于如何使用 Netlify 实现持续集成和自动部署,我在「博客通过 Netlify 实现持续集成」这篇文章中进行了详细的介绍,如有问题,可以直接参考这一篇文章。本文的内容适用于 Hexo 博客,在你的计算机中必须安装 GitNode.js。如果你使用的是其他的博客框架,部分内容可能需要自行修改,请查阅其他相关文章。

持续集成

准备环境

首先需要将你的博客所在文件夹初始化成一个 Git 仓库,如果已经实现了使用 Netlify 进行自动部署,则可以跳过这一步骤。 怎么确定是否已经是一个 Git 仓库呢?打开终端 / 命令行,然后进入你的博客文件夹,输入git status然后回车,如下:

1
2
git status
fatal: not a git repository (or any parent up to mount point /)

如果你得到的输出如上,那么你的博客文件夹就不是一个 Git 仓库,需要进行初始化。否则,请跳过此步。Git 的初始化也很简单,输入以下命令即可:

1
git init

接下来需要在博客文件夹根目录下的.gitignore文件中添加部分内容,告诉 Git 忽略一些无关的文件。Hexo 博客在安装的时候已经存在.gitignore文件,如果没有的话,新建一个即可。然后在该文件中添加:

1
2
3
4
5
6
7
8
.DS_Store
Thumbs.db
db.json
*.log
node_modules/
public/
.deploy*/
.env

文件中已经存在的内容无需重复添加,请根据自己的情况进行合理的修改,这里要重点关注一下.env文件,是必须要添加进去的,原因在后文中会讲到。

然后是 Node.js, 我们也要初始化一下博客所在的文件夹,即生成package.json文件。 当然,在 Hexo 博客安装的时候,已经存在该文件,你在安装一些博客插件的时候,插件的信息也会记录在这里,它的作用是告诉 Node.js 我们所需的模块。但在这里还需要对该文件的内容进行修改,因为 Hexo 的package.json文件内容信息并不完整。

Hexo 的package.json文件中缺少descriptionmainscriptsrepositorykeywordsbugshomepage这些信息。这里建议都添加进来,因为如果缺少部分信息,很可能在后面的操作中报错。

你也可以通过:

1
npm init

package.json文件进行初始化, 这样会出来一个交互界面,你需要填写相关的信息。如果你不需要这个交互界面,你可以直接npm init -y,这样会将默认设置写入,然后你可以直接打开package.json文件编辑相关内容。 当然,在这个操作之前,最好将原来的package.json文件进行备份。 如果你仍有不确定的地方,可以参考一下本博客的该文件

模块的安装与配置

接下来,我们要安装 ipfs-deploy 模块,它就是将博客部署到 IPFS 上的主角。输入以下命令安装:

1
npm install ipfs-deploy --save-dev

然后修改package.json文件,在scripts内添加两条命令:

1
2
3
4
"scripts": {
"build": "hexo clean && hexo generate && gulp build && gulp",
"ipfs-deploy": "ipfs-deploy -p infura public -p pinata public -u pinata -d cloudflare -C -O"
}

第一条build即构建命令, Hexo 的命令即为hexo clean && hexo generate。这里我还添加了gulp build && gulp是因为我使用了 Gulp 对博客进行了其他的一些操作( 静态资源的压缩以及实现 PWA 功能 ),如果你也使用了 Gulp 请将其命令添加到这里,如果没有的话可以忽略。 第二条ipfs-deploy就是将博客部署到 IPFS 的命令,里面的参数说明可通过以下命令查看:

1
ipfs-deploy --help

我们还需要添加一个.env文件,它是 ipfs-deploy 所需的环境变量,如下:

1
2
3
4
5
6
7
IPFS_DEPLOY_PINATA__API_KEY=
IPFS_DEPLOY_PINATA__SECRET_API_KEY=

IPFS_DEPLOY_CLOUDFLARE__API_EMAIL=
IPFS_DEPLOY_CLOUDFLARE__API_KEY=
IPFS_DEPLOY_CLOUDFLARE__ZONE=example.com
IPFS_DEPLOY_CLOUDFLARE__RECORD=_dnslink.example.com

特别注意:这个文件包含重要信息,千万不要把它上传到 GitHub 上!请务必将 .env 添加到 .gitignore 文件!

那么,这个文件怎样填写呢?前两项,先去 Pinata 注册,注册完成你应该就能看到你的 API KEY 和 SECRET API KEY,将之分别填入以上文件。中间两项,你要去 Cloudflare 注册,然后将你注册的邮箱填入上方,接下来去这里获取你的 API Key 并填入上方。最后两项,是有关域名的,如果你还没有一个域名,赶紧去购买( 个人推荐域名服务商 GoDaddyNameSilo)一个吧!怎么填写呢?将example.com替换为你的域名即可,如果你的博客使用的是子域名,那么只需设置最后一项为_dnslink.blog.example.com

你可能会好奇 Pinata 提供的是什么服务,以及为什么我们要使用它。Pinata 提供的是 Pinning 服务。简单来说,就是将你的文件上传到 IPFS 网络上,并且会同步到它建立的众多 IPFS 节点上(IPFS 集群,你也可以自建 IPFS 集群,ipfs-deploy 也提供了相应的部署功能,可以去看一下这篇详细教程)。如此,当 IPFS 上的任一个节点想要下载你的这个文件时,速度才有保证。我们之所以需要它,是因为 Cloudflare 的 IPFS Gateway 其实只是一种「缓存」服务,让我们能够利用 Cloudflare 的全球节点高速访问 IPFS 网络上的内容,但其服务器不会永久保存 IPFS 网络上的文件(技术上直白一点就是它不是ipfs add)。

在这里,你可能会问:Pinning 是什么意思?Pinning 是 IPFS 的一个术语,你可理解为「钉定」的意思。一个 IPFS 节点不是一块本地硬盘,节点的存储空间是有限的(默认是 10GB)。当节点存储的文件总大小超出了这个值后,节点就会自动删除一些文件(清「缓存」),而 Pinning 就告诉节点:该文件很重要,请不要清除它!如此,节点就会保留你的文件。你的文件没被清除,它就依然能够被其它节点访问到,你的文件在 IPFS 网络上的可访问性就得到了保证。

你可能又会问:为什么要使用 Pinning 服务提供商的服务,本地不是可以直接使用ipfs add(该命令会同时将添加的文件 Pinning 在本地节点)将文件添加到 IPFS 网络上吗?不不不,ipfs add只是将你的文件按照算法分割成一个个大小为 256KB 的 IPFS 对象(IPFS Object,你可以理解为区块,但在 IPFS 中这是两个不同的概念。另,ipfs add的详细细节可看这篇文章),然后添加到本地节点。也就是说,它并不会将你的文件上传到 IPFS 网络,甚至在你运行 IPFS 的守护进程(ipfs daemon)后,你的文件也不会被主动上传到 IPFS 网络。这样的做法是合理且很好理解的,换位思考一下就好了,比如:你的电脑作为一个节点,你肯定不会希望大量你不需要的数据同步到本地,你只会去同步你需要的数据(即你访问的 Hash 地址)。IPFS 是一个民主的世界,它不会强制要求每个节点必须同步其它节点的数据。如果一个节点需要某个文件,该节点就高举该文件的 Hash 并在 IPFS 网络中大喊一声:你们谁有这个文件啊?然后 IPFS 网络回应:我有!我有!……于是该节点就快速获取到该文件了。

但是,目前的 IPFS 节点数量虽已不少但还远远不够,且绝大部分人还是通过第三方提供的 IPFS Gateway 来访问你的博客的,而不是通过本地 IPFS 节点。这样的话,一旦提供 IPFS Gateway 服务的服务器清除了你的文件,你的博客就无法访问了。除非,你本地每周 7 天每天 24 小时一直运行着ipfs daemon。但是,即使这样其实也远远不够,举个例子:你的文件不幸被 Cloudflare 的 IPFS Gateway 的服务器清除,而正好此时有一个读者点开了你的博客,此时会发生什么呢?该服务器会重新去 IPFS 网络寻找,但此时的情况就如下图了:

这就意味着你的读者可能要等待很久很久才能打开你的博客,如此你的博客的用户体验将会极差。因此,为了保证博客的可访问性,你就需要使用 Pinata 或其它服务提供商提供的 Pinning 服务了,至少目前是如此。

你可能会说:你上面说得都很不错,但我为什么还要使用中心化的服务?IPFS 不是去中心化的分布式网络吗?

  1. IPFS 仍处于起步阶段,节点数量虽已不少但还远远不够;
  2. IPFS 的应用还在起步,浏览器还不支持直接访问 IPFS 网络;
  3. 博客读者目前是通过第三方提供的 IPFS Gateway 访问的,即读者未加入 IPFS 网络,这也就无法发挥 P2P 的优势,而必须依赖第三方提供的中心化的服务。

但是,IPFS 的前景不容置疑。如果你使用过 P2P 下载软件下载过电影,你就能理解,几乎你需要的每部电影都能以极高的速度下载完,且给你提供数据的节点遍布全球。需要注意的是,这还仅仅是在极客圈子内呢,而未来,当每个互联网用户都加入 P2P 的世界,那会是怎么样的呢?那就是 Web 3.0 的世界了,那就是 IPFS 取代 HTTP 的时候了。那时,人人的手机、电脑都是一个服务器;那时,没有中心化的组织掌控你的隐私信息;那时,世界不再有高墙,互联网真正实现了世界互联。

除了 Pinata,类似的 Pinning 服务提供商还有:

  1. https://infura.io/
  2. https://www.eternum.io/
  3. https://globalupload.io/

其中,第二个需要注册付费才能使用,第三个可以免注册免费上传,但是不会 Pinning,且单个文件的最大上传限制是 50MB。至于第一个,它就比较奇葩了,它虽然提供服务,但目前它连个上传的界面都没有提供,你怎么上传呢?直接通过它提供的 API。但是,它也最良心,它完全免费,它不用注册,它几乎没有任何限制,无论是请求数还是文件的大小,它不会 unpinning 你 add 的文件——甚至目前连一个 unpinning 的途径都没提供给你!但比较可惜的是,它的 API 经常请求失败,且虽然它是 ipfs-deploy 的默认支持的 pinner,但我在使用时它好像有个奇怪的 bug,这个 bug 会导致上传到 Infura 的文件与实际的不一致,故我在上面的package.json里面写的ipfs-deploy命令并没有将文件同时上传到 Infura,而只是把文件 add & pin 到了 Pinata 上,然后只将文件的 Hash 值 pin 到 Infura 上。但这样其实是完全可行的,甚至更完美,因为只要将文件的 Hash 值 pin 了,运行的 IPFS 程序会自动去 IPFS 网络中下载该文件,而我们本地就只需上传一遍。

回到正文,接下来你必须将你的域名移交给 Cloudflare 管理(即将域名服务器地址修改为 Cloudflare 提供的地址),为什么呢?因为我们是通过 DNSLink 来实现将域名「解析」到 IPFS 的,说白了就是添加一条包含了 SSG 生成的文件夹(即public)的 Hash 值——即 IPFS 上的「URL」,因为 IPFS 是内容寻址,即通过内容的 Hash 值寻址——的 DNS 记录。而 SSG 每构建一次,public文件夹的 Hash 值就会改变(如果博客有修改的话),因此如果你想保证读者能够及时获取到博客的最新版本,你就必须在每次发布博客的同时更新这条 DNS 记录。这种重复的无聊工作肯定不应该手动操作,而应该交给程序自动化处理,这就是 ipfs-deploy 的一个很重要的功能了,而它目前仅支持 Cloudflare。另外,Cloudflare 支持裸域名(即直接example.com)CNAME。综上,目前我们必须将域名移交给 Cloudflare 管理。操作的流程如下:

  1. 在 Cloudflare 注册后点击 Add a Site,输入你的域名后按流程走
  2. 去你的域名服务商修改域名服务器的地址,设置好后可以用 Google 提供的工具清空域名的 NS 缓存以加速
  3. 回到 Cloudflare,点击 Check 或 Re-check now,然后等待几分钟,刷新页面可以看到成功提示
  4. 设置 DNS,删除原有的一些没用的值(如 A 记录和 AAAA 记录),然后添加一条 CNAME:Add record > Type:CNAME,Name:example.com,Target:cloudflare-ipfs.com> Save
  5. SSL/TLS > Always Use HTTPS

我的域名之前使用的是 DNSPod 的 DNS 解析服务,将域名提交到 Cloudflare 之后,网站会提示更改你的 Nameserver:

这时候就需要回到域名服务商那里修改 Nameserver 到:

1
2
merlin.ns.cloudflare.com
vita.ns.cloudflare.com

在设置 DNS 的时候,如果你添加的是子域名,那么就需要添加子域名的 CNAME 记录,如blog.example.com而不是直接添加example.com的 CNAME 记录。

你可能会问:可以将cloudflare-ipfs.com替换为别的 IPFS Gateway 地址吗?可以,但是这会有一个 SSL 证书(即 HTTPS)的问题。我们是通过 IPFS Gateway 获取 IPFS 上的内容的,它的作用就是一个网关,连接了 HTTP 和 IPFS,让我们能够使用目前的浏览器方便地访问 IPFS 上的内容。其实,这就是我们添加的这条 CNAME 的作用,将你的域名重定向到安装了 IPFS Gateway 的服务器。以上面添加的这条 CNAME 为例,当一个读者通过浏览器点开example.com后,浏览器去问 DNS 服务器:这个域名的 IP 地址是什么啊?DNS 服务器找到一条 CNAME 记录,指向cloudflare-ipfs.com并且它的 IP 地址是104.18.253.167,于是 DNS 服务器告诉浏览器:IP 地址是104.18.253.167!于是浏览器向这个 IP 地址发起一个 HTTP 请求,这就成功地将你的域名重定向到安装了 IPFS Gateway 的服务器了。之后发生了什么呢?安装了 IPFS Gateway 的服务器会通过 HTTP 请求里的 Header 信息获取到访问的域名是example.com,然后它去查询该域名的 DNS 记录,读取到dnslink后,就会获取里面包含的 Hash 值(IPFS 地址),最后服务器去 IPFS 网络中获取到相应内容并通过 HTTP 返回给浏览器,浏览器将获取的内容渲染,该读者就能开始开心地阅读你的博客了~以上,可见如果你的博客想要实现 HTTPS,你 CNAME 指向的支持 IPFS Gateway 的服务器就必须要有属于你的域名的 SSL 证书,而目前好像只有 Cloudflare 的 IPFS Gateway 才会提供这项服务——为你的域名生成相应的 SSL 证书。

完成以上步骤后,我们可以先在本地测试一下,执行命令:

1
npm run build && npm run ipfs-deploy

稍等片刻,提示成功后,你可以先点开显示的 URL 地址预览。如果你发现画风完全不对,那是因为你的博客的使用的是绝对链接而不是相对链接。博客之前是https://example.com/而现在是https://a.com/ipfs/example.com/,这就会导致大量用绝对链接的文件 404,比如:绝对链接/css/main.css请求的地址其实是https://a.com/css/main.css,而实际上该文件的正确的有效的地址却是这样的https://a.com/ipfs/example.com/css/main.css。怎么解决呢?将它变成相对链接即可,如上面的链接如果是./css/main.css,那就没问题了。目前这个相对链接的问题我还没有解决,不过你可以参考下面的两个链接:

  1. https://developers.cloudflare.com/distributed-web/ipfs-gateway/updating-for-ipfs/
  2. https://medium.com/pinata/how-to-easily-host-a-website-on-ipfs-9d842b5d6a01

但是,如果你是直接通过自己的域名访问,以上这个问题是不会存在的。现在,浏览器打开一个新的标签页,按下 F12 再访问你的博客。恭喜你,你的博客已经成功部署到 IPFS 上了!你可以通过浏览器的控制台手动检查下 Header 信息,如下图:

接下来,配置下 Netlify 以实现持续集成。先去 Netlify 注册,推荐直接用 GitHub 的帐号,然后按照提示授权、选仓库……(如果遇到问题可以参考「博客通过 Netlify 实现持续集成」)好了后前往 Site settings > Build & deploy > Environment 添加 6 个环境变量,名字和值分别对应.env文件里的值(因为在将博客文件夹上传至 GitHub 仓库的时候,并没有上传.env文件,所以这一步十分重要)。然后需要新建一个netlify.toml文件,添加一些持续集成所需的设置:

1
2
3
4
5
6
7
8
9
[build]
publish = "public/"
command = "npm run build && npm run ipfs-deploy"

[[redirects]]
from = "https://guanqr.netlify.com/*"
to = "https://www.guanqr.com/:splat"
status = 301
force = true

这里解释一下,build即构建相关的设置,publish即我们要发布的文件夹(其实这个已经没必要了,因为我们现在是部署在 IPFS 上,而非 Netlify 的服务器上),command即要执行的命令,我们直接用 npm 执行写在package.json里的命令即可。

redirects中的内容是将 Netlify 给我们提供的子域名重定向到我们自己的域名,加上有利于 SEO,请将guanqrwww.guanqr.com替换为你自己的值。

如果你对这个文件还有疑问,可以参考 Netlify 的文档:

  1. https://www.netlify.com/docs/continuous-deployment/
  2. https://www.netlify.com/docs/netlify-toml-reference/

最后一步,将你的博客文件夹提交到 GitHub:

1
2
3
git add -A
git commit -m "Deploy to IPFS"
git push -u origin master

去 Netlify 上查看下部署日志,成功完成!

查看详细的部署信息,如图所示,就可以看到生成的链接地址。

原生部署

这里的原生部署是指直接通过本地安装的 IPFS 软件将博客部署到 IPFS 网络上,不使用任何中心化的服务,但目前也不适合生产环境。通过本节,你对 IPFS 的理解会更深,对上文内容的理解也会更深。如果你还不知道 IPFS 是什么,可以去官网或观看这个视频了解一下。

安装

各系统的安装方式,可以参考:https://docs.ipfs.io/introduction/usage/

开始

安装好后,先初始化自己的 IPFS 节点:

1
ipfs init

稍等片刻,会输出一些信息,第三行就是你的节点 ID 了,它是一段杂乱的 Hash 值,它是唯一的,但你无需记住它,通过ipfs id命令你可以随时查看它。如果你运行了ipfs id,你会发现输出的除了 ID,还个叫 Public Key 的东西,它是一段更长的 Hash 值,这是你的节点的公钥。此时,好奇的你可能会问:那么私钥在哪里呢?输出的信息中已经给出,比如我的:

1
initializing IPFS node at C:\Users\Thinkpad\.ipfs

在这个路径文件夹里的config文件内。

添加

需要特别注意,添加是指将你的文件或文件夹按照算法分割成一个个大小为 256KB 的 IPFS 对象,然后添加到本地 IPFS 节点,而不是指将你的文件上传到 IPFS 网络。

1
ipfs add -rQ public

你可以用以上命令将你的文件夹添加到 IPFS。其中,r参数的意思是递归添加(recursive),如果你添加的只是一个文件,则可以不要;Q参数的意思是安静输出(quiet),且只会返回最后生成的那个 Hash,即我们添加的文件夹的 Hash;public就是我们要添加的文件夹的名字了。稍等片刻后你应该就能看到一段 Hash 值,这就是我们添加的文件夹的 IPFS 地址。

发布

要想发布我们的文件,我们首先要将自己的电脑变成一个 IPFS 节点,即要在本地运行 IPFS 服务,输入以下命令:

1
ipfs daemon

稍等片刻,最终输出Daemon is ready时,就说明成功了。你可能会注意到以下输出:

1
2
3
API server listening on /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
  1. 本地的 API 服务,有一些ipfs命令需要该服务。
  2. 一个人性化的网页用户界面,会显示 IPFS 运行的一些信息,也可以编辑 IPFS 的一些配置。
  3. IPFS Gateway 服务,此时可以直接通过 http://127.0.0.1:8080/ipns/example.com/ 来访问部署在 IPFS 的博客网站。当然,初次访问可能要等待较长时间。

接下来,我们就来将我们的文件「发布」出去,访问https://cloudflare-ipfs.com/ipfs/Hash(用你的添加后得到的 Hash 值替换 Hash,你也可以将cloudflare-ipfs.com替换为任何 IPFS Gateway 地址。)。稍等片刻,你的文件就成功地「发布」到 Cloudflare 的 IPFS Gateway 的服务器上了。这时,你应该就能明白我为什么要在「发布」两字左右加上引号了,因为这是被动而不是主动的。什么意思呢?打个比方:你在街上发传单,你将传单一张一张递给路人,这叫做发布。而现在的情况呢,你在街上发传单,突然你发现一个路人老远老远就对着你大喊:给我一张传单啊!同时快速冲到你面前并直接抽一张就跑了,而你只是站在那,这当然不能叫发布了。

但是,细心的你可能会发现一个问题,你的博客每修改一次,SSG 生成的文件夹的 Hash 值(IPFS 地址)就会改变一次,我总不能每更新一次博客就去通知一遍读者我博客的最新 IPFS 地址吧!何况这也是完全不可能的啊!是的,IPFS 考虑到了这个问题,并提出了 IPNS 的解决方案(另一个解决方案就是 DNSLink,它目前可用于生产环境,但依赖于现有的中心化的域名系统)。运行以下命令:

1
ipfs name publish --lifetime 999999h --ttl 300s <hash>

lifetime参数的作用是指定该记录的有效时间,默认是24h即 24 小时,上面这个是测试得到的最大值;ttl即 Time To Live,解释见这里<hash>即你的博客最新版的 Hash 值。稍等片刻后,你会得到一个输出,比如:

1
Published to QmRRL6Zc8NTEC9kMD4pWiaszfrtiYrwMxCJL2Mm4SexgSq: /ipfs/<hash>

后面那个 Hash 即是你的输入值,而前面那个 Hash 呢,它其实就是你init时得到的 IPFS 节点 ID。这样,你每次更新博客时,只需先ipfs add最新版本的public文件夹,得到<hash>,然后ipfs name publish就行。而你也只需告诉朋友你的节点 ID 即可,不过注意提醒一下他:这是 IPNS 地址,而不是 IPFS 地址,所以你访问的时候要注意!

以上命令执行成功后,可以在本地打开http://127.0.0.1:8080/ipns/Hash测试一下。当然,前提是你的ipfs daemon正在本地运行。然后,你也可以打开https://ipfs.io/ipns/Hash测试一下。目前我的测试结果是,本地没问题,但其它 IPFS Gateway 没有成功过,应该是 IPNS 目前还有一些问题。

此时,你可能会想到一个问题:我有两个博客,而一台电脑只能有一个节点 ID,我总不能再买一台电脑吧?很对!但其实,ipfs name publish是可以指定 IPNS 地址的,只不过它的默认值是节点 ID。我们可以用以下命令生成一个新的 IPNS 地址:

1
ipfs key gen --type=rsa --size=2048 example.com

当然,将上面的example.com替换为你喜欢的名字(下同),然后使用时:

1
ipfs name publish --lifetime 999999h --ttl 300s --key example.com <hash>

更多使用参数和说明见:

  1. https://docs.ipfs.io/reference/api/cli/#ipfs-key
  2. https://docs.ipfs.io/reference/api/cli/#ipfs-name-publish

如果你使用了 IPNS,请务必备份节点的私钥和生成 IPNS 地址时生成的 Key!它们分别存储在你init时显示的目录下的config文件和keystore文件夹内,请务必备份!

清除

如果你有电脑洁癖,你可能会问:我要怎样清理本地 IPFS 节点的「垃圾」呢?

首先,IPFS 本地节点的默认最大存储空间是 10GB,如果超过这个值,IPFS 会自动将没有钉定(Pinning)的文件删除一部分,你可以将它理解为 IPFS 的清除机制。但是,如果你想手动将所有没有钉定的文件删除,你可以使用以下命令:

1
ipfs repo gc

然后,对于你添加(ipfs add)的文件,IPFS 会自动将它们钉定,所以以上命令并不能将它们清除,你需要执行:

1
2
3
ipfs add -rQn <文件>
ipfs pin rm <hash>
ipfs repo gc
  1. 如果你忘记了你添加的文件的 Hash,你可以通过该命令查看,但注意该命令必须在该文件的所在目录下执行。
  2. 取消该文件的钉定,默认是递归的,因此无需添加-r参数。
  3. 清空本地 IPFS 节点上所有没被钉定的文件。

如果你添加过该文件很多次,且期间你对这个文件进行了修改,导致该文件每次的 Hash 值都不一样,进而导致钉定的也不一样,那么你可以通过以下命令查看你钉定过的所有 Hash:

1
ipfs pin ls -t recursive

如果你添加过实在太多了,而你现在只想将它们全部清除,那么:

1
2
ipfs pin ls -t recursive | cut -d ' ' -f1 | xargs -n1 ipfs pin rm
ipfs repo gc

需要注意的是,执行清空命令会将 WebUI 的网页也删除,所以执行后你下一次打开 WebUI 时可能就要多等待一会儿了。

问题说明

目前我在将博客部署到 IPFS 时遇到一些问题。

首先是上文提到的相对链接的问题,尝试了很多方法都无法解决,只好放弃。其次就是域名的问题,按照官方的方法,就是将自己的域名添加一个 CNAME 记录到cloudflare-ipfs.com,但是在我成功添加 CNAME 记录后,国内的网络无法正常访问。Ping 的 IP 地址并不是 Cloudflare 的 CDN 节点,而是 Facebook 的 IP。有时候晚上使用校园网可以访问,其他时候则必须搭梯子才可访问。我查看了其他几位部署到 IPFS 的博客网站的 IP 地址,都没有出现这个问题,因此我也没有找到任何解决方法。

因为上述问题,目前我的博客停止部署在 IPFS 上了。除此之外,还有一些普遍存在的问题:

  1. 无法定制 404 页面
  2. Cloudflare 上看不到浏览统计信息
  3. Cloudflare 的 IPFS Gateway 会 403 视频

对于第三个问题,是只对你将视频直接存放在博客的仓库,且在博客中用相对链接作为视频的 URL 有影响的,解决方法就是在该视频链接前加上其它 IPFS Gateway 地址,比如https://gateway.pinata.cloud

参考

本文转载自「将博客部署到星际文件系统(IPFS)」这一篇文章,内容针对个人情况有部分修改和删减,对将博客部署到 IPFS 更详细的步骤请访问原文,在此特别感谢作者的技术分享。

IPFS:

  1. IPFS
  2. IPFS Demo | YouTube
  3. IPFS for Websites | IPFS Documentation
  4. The Complete Beginner’s Guide to Deploying Your First Static Website to IPFS | Interplanetary Gatsby
  5. Distributed Web: host your website with IPFS clusters, Cloudflare, and DevOps | With Blue Ink
  6. Connecting Your Website | Cloudflare
  7. Serve your FaunaDB Single Page App from IPFS | Fauna
  8. How to Easily Host a Website on IPFS | Pinata
  9. A Weekend With IPFS | A Weekend With
  10. Ten terrible attempts to make the Inter Planetary File System human-friendly | Hacker Noon
  11. IPFS: The Internet Democratised | Tony Willenberg
  12. IPFS:替代 HTTP 的分布式网络协议 | InfoQ
  13. IPFS:你上的可能是一个假的互联网

Web 3.0:

  1. 站在 Web3.0 理解 IPFS 是什么 | 深入浅出区块链
  2. Web3.0:能否开启未来 10 年创新创业创富大门?(上) | 碳链价值
  3. Web3.0:能否开启未来 10 年创新创业创富大门?(下) | 碳链价值

本文结束啦感谢您阅读