记一次成功部署开源云剪贴板的经历
记一次成功部署开源云剪贴板的经历
Why
自从上大学以来，我一直都会使用云剪贴板，用来备份或者跨设备传输各种各样的文本。从某个开源的云剪贴板，到ubuntu的云剪贴板，到洛谷的云剪贴板，结果现在不得不一一舍弃。那个开源的云剪贴板，本来是能在国内正常使用的，估计有人用那个项目传播什么非法信息，被晶哥喝茶了，项目被整改了……自己体验一下，项目里README中的内容：
由于之前的永久存储具有传播性，被一些不法份子拿来传播一些不合规的内容，直接导致 PasteMe 被查水表了。（免责声明并没有用）
新版本的 PasteMe 被迫增加了一些限制，未登录的用户只能发布 自我销毁 且附带限制的一贴，登陆后才能发布永久存储的一贴。
而由于前端、后端开发资源的制约，目前是没有用户系统的
我的理解是：本来作者就懒得维护，项目也不是用来盈利的，还被别人拿来干坏事。作者还要被请去喝茶，那这项目自然完蛋草了。
ubuntu，那个没啥好说的，功能简陋，也就适合用来放代码。一些基本的安全控制都没有。最坑的是就这么点功能，使用还要登录。果断舍弃。
洛谷的云剪贴板。说实话和ubuntu的半斤八两，也没有安全控制，充其量多了个后台能让你删除已发布的链接。不过好在登录比起ubuntu的要方便一些。我就一直这么拼拼凑凑的用到了今年。结果有一次，我想把东西分享给我朋友的时候发现，这玩意已经被墙了……问了下群里洛谷的管理员kkksc03，人家这样回答：
洛谷那个云剪贴板，啥时候改成翻墙才能看的了。我记得之前没那么麻烦，能直接分享的
那没办法
你看博客园
国内搞ugc就是死路一条
故，舍弃。
再加上我老是手贱，图方便把一些隐私的东西放在微信的文件传输助手里。本来在大学里是没事的，但在单位里老是不经意间被同事看见文件传输助手里的东西。于是决定找个开源的云剪贴板项目，一并解决这些问题。思来想去，确定了以下需求：
- 要有精细完备的安全功能，阅后即焚（访问次数限制）、链接有效时长，这些最基本的东西一定要有。
- 要有权限控制系统。为了避免和那个开源作者一样的惨案，我必须确保所有用户和所有发布的文本都在我的可控范围内。
- 要能使用markdown语法编辑文本，并且在分享的时候能渲染markdown文本
- 要能把东西成功分享给我周围的人，也就是国内IP能直接访问，不需要机场
- 最好是Serverless的，就像我这个博客一样，除了域名的成本不需要我付出额外的资金和运维管理成本
- 数据的安全和隐私要得到保障，所以不能把代码和数据托管在国内的平台，要不然就像那个开源作者一样随时被查水表
- Web必须是响应式布局。因为我的使用场景涉及到跨设备传输，所以必须适配不同类型的终端
- 其他功能多多益善
Which
当我在Linux.do刷帖子时，发现了这么一个项目：
基于 Cloudflare 的在线文本 / 大文件分享平台，支持多种语法 Markdown 渲染、阅后即焚、R2~B2 等 S3 聚合存储、密码保护等功能，可作为 WebDav 挂载，支持 Docker 部署。。项目详情可以点开链接查看，链接里还有项目的GitHub地址，我就不赘述了。总之，看到这玩意，我就知道我找到要找的东西了！
How I made it
开工！而且还是在上班的时候，直接开干！一边摸鱼，一边能在部署的过程中接触和学习到当今较为流行的云原生和Serverless架构，一边能解决自己的需求和痛点，领导问起来还能说自己是在学习前沿技术。还能找到比这更完美更开心的事情吗？总之，干干干~
于是看着项目里的README，准备Cloudflare账号，准备b2账号，ForkGithub中的Repo，运行工作流一步一步做下去。说实话，部署教程写的非常详细易懂，而且我也提前看了帖子里中其他论坛成员部署中碰到的坑。当然不排除是我动手能力和学习能力强，总之部署过程基本都挺顺利的，没有碰到什么大坑。这里提几个印象比较深的点吧。
一是GitHub仓库需要Cloudflare的accountID作为环境变量不知道Cloudflare的accountID是什么，然后我google到了一个博客，发现这东西藏在Cloudflare提供的域名服务里。然后随便找了个域名，跟着那个服务指示一路next，到了那个换DNS的页面，把accountID给套了出来。
二是换自定义域名。因为项目的后端是部署在了Cloudflare的worker里面。而xxxx.cloudflare.xxxx.worker.dev这个域名在国内是被墙了的。为了解决这个问题，必须用自己的域名替换掉Cloudflare为我们提供的默认域名。这个文档里没有详细说明，我实际上是问Gemini问出来的。然后发现Cloudflare的可用性和指导做的还挺完善的，然后有些坑我也看了论坛里的帖子（换了后要更新环境变量，GitHub action的工作流要重新run一遍）全程没遇到任何问题。
三就是b2的跨域配置问题了。这个得用自定义方法，还得下他的那个exe工具通过命令行才能自定义配置。不过没啥大问题，都是跟着教程走的，就是花的时间多了点。
What is it now
这就是项目目前的架构图：
这个项目主要由三个核心部分组成：前端、后端和数据存储层。这个项目的整体架构可以被定义为一个基于Cloudflare生态的、前后端分离的现代化Serverless（无服务器)云应用。它的核心优势在于高可用、低成本和易于维护。
Frontend:
托管平台: Cloudflare Pages
- 功能: 这是用户直接与之交互的Web界面。它负责展示剪贴板内容、文件列表、提供编辑器，并将用户的操作（如上传、删除、创建分享链接等）请求发送给后端。
Backend:
运行环境: Cloudflare Workers
- 功能: 这是整个应用的大脑，以API接口的形式存在。它不处理网页的显示，而是负责所有的核心逻辑，包括：
处理前端发来的GET/POST等请求。 - 用户认证与权限管理（通过管理员账户或API密钥）。
- 与数据库（D1）交互，读写文本内容、文件元数据等信息。
- 与对象存储（B2）交互，生成用于文件上传/下载的预签名URL，管理文件。
- 提供WebDAV协议支持，允许外部应用通过/dav路径进行文件操作 。
Data Storage:
这是一个分层设计，将不同类型的数据存放在最适合它们的地方。
- 元数据存储:
Cloudflare D1数据库 。D1是一个基于SQLite的Serverless数据库，它主要用来存放轻量级的、结构化的数据，比如：剪贴板的文本内容、用户的设置、分享链接的密码和过期时间、文件的名称和大小等元数据。 - 文件对象存储:
Backblaze B2（或其他S3兼容服务）。这是我指定的、用来存放用户上传的实际文件的地方。例如，你上传的一张图片、一个文档，其文件本身是存放在B2的存储桶里的。
CI/CD
整个项目的部署流程高度自动化，核心是GitHub Actions 。
- 触发方式: 当代码推送到GitHub仓库的main或master分支时，会自动触发预设好的工作流 。
- 后端流程: GitHub Actions会自动构建后端代码，并将其部署到Cloudflare Workers。它甚至能自动创建和初始化D1数据库 。
- 前端流程: 同样，前端代码的更改也会触发GitHub Actions，将其构建并部署到Cloudflare Pages 。
Learned
部署这个CloudPaste项目，可以说让我完成了一次云原生应用构建演练，接触并了解了Cloudflare这个赛博活佛平台及其相关服务。还将Cloudflare的核心服务——用于前端的Pages、承载后端逻辑的Workers、以及存储元数据的D1数据库——成功整合，并对接了第三方的B2对象存储。也让我对后续在Cloudflare部署新的项目有了期待和兴趣。因为部署体验非常良好，整个过程指引易懂，页面清洗，不想国内那些传统的云厂商一样，控制面板繁琐难用非常反人类。