前言
近期购买了香橙派，简单体验了一下本地linux服务器的快感。
不过其实基本上就是把最近在服务器上面折腾的东西搬到本地而已，没有啥太那个的，而且其实从我的感觉来看可能一些二手的小家伙有可能会有更高的性价比……
然后对于博客的折腾也进入了一个新的阶段，因为隔壁站提过，虽然静态博客确实很快很方便，但是SEO效果极差，大量网站内容都没收录进去（即使是在sitemap里面已经写了地址），这就导致我再次觉得还是动态博客框架更适合我 折磨自己
下面对服务器，香橙派相关的折腾做一个简单盘点，因为怕被搞我就不细讲了。
服务器篇
首先必须感谢docker一键安装脚本：
curl -fsSL https://get.docker.com | bash -s docker
//使用阿里云镜像
curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun
sudo systemctl enable docker
sudo systemctl start dockerfrom：https://krau.top/posts/install-docker-one-key
我反正基本上全靠它直接无脑了。
因为服务器在海外所以没列docker镜像加速的内容，这一部分可以参考镜像加速器提到的使用镜像加速的方法。
业务1 博客docker化
这次服务器业务，包括typecho都是走的docker，然后想尝试一个数据库跑两个博客，就踩了巨多的坑，其中比较重要的参考文章是Typecho 用一个程序建多个网站。
这一部分各位就看自己是通过什么途径实现的一个程序多个站点来写相关的php文件即可。
docker配置部分
本业务涉及docker：
nginx，php，mysql
version: "3"
services:
nginx:
image: nginx
ports:
- "8111:80" # 左边可以改成任意没使用的端口
restart: always
environment:
- TZ=Asia/Shanghai
volumes:
- ./typecho:/var/www/html
- ./nginx:/etc/nginx/conf.d
- ./logs:/var/log/nginx
depends_on:
- php
networks:
- web
php:
build: php
restart: always
expose:
- "9000" # 不暴露公网，故没有写9000:9000
volumes:
- ./typecho:/var/www/html
environment:
- TZ=Asia/Shanghai
depends_on:
- mysql
networks:
- web
mysql:
image: mysql:5.7
restart: always
environment:
- TZ=Asia/Shanghai
expose:
- "3306" # 不暴露公网，故没有写3306:3306
volumes:
- ./mysql/data:/var/lib/mysql
- ./mysql/logs:/var/log/mysql
- ./mysql/conf:/etc/mysql/conf.d
env_file:
- mysql.env
networks:
- web
networks:
web:具体怎么操作就不说了（包括配置文件里面写的初始化文件），反正最后采用的是并不是参考文章里面提到的一个数据库两个博客，而是各自独立的一个数据库。通过修改数据表前缀的方法很容易导致后期修改表特别麻烦（而且有些插件和主题好像还会出bug），因此还是两个各一个表，然后通过同一个配置文件config.inc.php来切换访问网站时读取的对应数据库。
另外感觉这个操作也有很大的改进余地，比如实际上mysql的docker我并没有用上……等。
总之docker化以后感觉需要操心的东西大幅度减少，而且因为两个博客共享一个usr文件夹因此只需要“看客上菜”就行……嗯反正我也不好说到底算不算轻量了。
总之这一套操作下来的话只需要吃一个nginx和php服务就行。
主题与typecho版本的兼容性问题
因为博客搬过来的时候大部分图片都被我搬下来并且传到阿里云OSS了，原本服务器上的图片残留在备份数据库的表单里面，因此实际上需要在typecho里面搜一下附件部分的图片相关的关键词然后删掉，要不然很多插件和附件功能都打不开……嗯，反正当时没想到这么麻烦。
另外一个问题就是手上买的博客主题相互冲突。
我手上两个主题，Handsome是准备给project站使用的，这个使用开发版的typecho会在主题设置界面一片空白。（而且目前还没有修这个bug的迹象），因此只能用typecho的1.2.1版本；
另外一个主题Cuteen原本是要给笔记站用的，但是这个又只能用最新的开发版本才能在主题设置界面正常切换一些内容的开关。（1.2.1版本按照开发者说的修改了代码以后反而会报错，我猜想是不是因为共享一个php业务的原因……）
因此考虑到各种原因和主题的相互适应性，最后还是把Cuteen丢了。
不过也因此有幸碰到initial这个非常棒的主题，算是因祸得福。（不过还是有点bug，感觉还是typecho版本问题）
旧博客导出和新博客导入问题
其实不是大问题，主要是想保留博客的创建时间，而不是都是集中在搬运博文的那一天，反正基本上就是折腾。
再加上2023年我丢下动态博客的时候typecho还是1.1版本数据库，因此最后折腾数据库备份恢复这部分真的是……吐血了。
不说了，反正现在已经搞好一个站了。
通过静态函数部署hexo博客（旧博客学的技巧）
在静态博客时期我学习了一个小技巧：通过静态函数部署hexo博客
具体参考的哪篇文章我也不记得了……反正写一个静态函数的配置文件config_serverless.yml，然后稍微设置一下就好。
edition: 1.0.0
name: my-framework-app
access: default
services:
framework:
component: fc
actions: # 自定义执行逻辑
pre-deploy: # 在deploy之前运行
- plugin: website-fc
props:
region: your-region
service:
name: serverless-devs-application
function:
name: your-project
description: Initialize
runtime: nodejs14
memorySize: 128
cpu: 0.05
timeout: 60
codeUri: ./public
diskSize: 512
triggers:
- name: httpTrigger
type: http
config:
authType: anonymous
methods:
- GET
- POST
- PUT
- DELETE
- HEAD
- OPTIONS
customDomains:
- domainName: auto
protocol: HTTP
routeConfigs:
- path: /*注意，我的部署习惯是把public文件夹和上面这个yml文件放一块传到github仓库，不是通过hexo自带的deploy进行的部署，如果你学我的话可能要改一下yml的路径。
呃，扯这个实际上是铺垫下面这个内容。
通过DNSPOD分国内外解析加速全球访问
虽然我的所有域名都是托管在cloudflare上面的，但是通过单个域名的NS解析到DNSPOD的话就可以实现一个比较傻瓜式的分国内外解析。
静态博客通过境外解析到vercel，境内解析到阿里云静态函数，就能实现全球的快速访问。
同理，CDN部分其实也可以实现类似效果。CDN海外部分设置回源到图片和静态资源的存储桶里面，然后同样通过DNSPOD，国内解析到国内CDN分配的加速地址，国外解析到海外CDN提供商给的加速地址，就能实现类似的全球访问加速效果。
然后我现在的动态博客也做了类似的操作，就不细说了，道理一模一样。
图床迁移
发现backblaze还是太麻烦了，所以实际上目前迁移到了cloudflare的R2存储桶，实用性和易用性感觉都高了不少。目前学习图床这边的图片都是搬运过来的。（但是博文实际上我还没搬运完）
业务2 其他拓展娱乐性docker
音乐播放器Navidrome
在折腾navidrome之前首先弄了个教育邮箱。
这次购买的是波兰艺术大学的邮箱。随邮箱有一个1T大小的谷歌和一个Office 365的A1订阅（大概是这个等级），因为我有更稳定的家庭版Office365所以这边我就暂时不用了。
谷歌弄好以后，通过rclone挂载到我的linux服务器上，然后就可以实现通过SSH免那啥向谷歌云盘上传文件，至于拿来做什么，当然是作为音乐播放器的跳板。
在Navidrome的docker-compose.yml配置文件里面提前把谷歌盘路径挂上就完事。
因为Navidrome是支持很多第三方api播放器的，比如Feishin，所以算是个性价比很不错的播放器。
至于为什么要搞这个……其实算是Lostidols的企划的一个分支吧。
音乐信息刮削Music Tagger
另外挂一个可以刮削音乐信息的tagger的docker，可以灌一些歌词到音乐播放器里面。
这个没啥好讲的，很白痴，只要把谷歌盘路径挂到tagger里面就可以了。
Copilot搭建的CoGPT
Github首先申请了一下学生认证拿了Education的包。
因为有些时候poe一类的玩意还是觉得不好用所以用CoGPT搭了一个套用GPT4.0接口的玩意。另外用vercel做了一个可以接入cogpt的api端口的web-gui网页
基本上全程都是自用所以其实即使已经删库跑路了我能继续用（实际上我用的非常非常轻量）。
另外还有一个搭的是bing的只不过这个和服务器没关系是全程用的cf的worker所以就算了……
字幕组用SaaS to 聊天服务器
简单来说就是一开始用的是Nextcloud作为字幕组的SaaS，然后某次因为强制升级不会开相关的调用所以就直接丢了，后面换的是VoceChat。VoceChat用的是Discord风格的框架，可以在两个好友之间建私人聊天，所以我感觉和SaaS也没啥区别（而且试了一下VoceChat推荐的音视频聊天第三方业务源，效果也很好，感觉和群友开视频party也没啥问题）
如果说有啥毛病大概就是VoceChat整体看着内容还比较空，表情自定义啊图片粘贴上传啊这些比较基础的功能都没有。
到处都能看到的Alist
这个就没啥好说的了……最大优势就是因为是海外服务器所以谷歌盘可以直接挂。
但是以后服务器到期的话要好好考虑一下存储挂哪里了。
目前试了一下蓝奏云优享版，发现只能下文件不能播文件……血亏88。
可能世界上最实际最方便的还是挂本地存储。
Umami网页分析业务
这个也没啥好说的，说实话也就IP定位没那么精确这一个小问题了。
而且可以发现虽然我博客长期无人评论但是爬虫也好真的读者也好实际上流量还是有不少的。
香橙派篇
业务1 挂和服务器差不多的docker
这个我就简单说说了。
首先和服务器一样的是Navidrome、Music Tagger和Alist，然后通过Zerotier做内网穿透一部分，SakuraFrp穿透一部分。
另外挂了个qBittorrent和方便传文件到音乐盘的FileGator，以及一个GUI管理docker的Protainer，以及内网NAS用导航页Heimdall。
业务2 内网穿透（摸索中）
内网IP段分析
关于内网穿透，研究了一下，首先，武大本身有一个共享的以220/202开头的IPv4地址，大概是个不同网段的内网IPv4；另外还有个10开头的内网IPv4，DWZ暴露的时候是这个ip段（流量无法访问）。然后我这边的路由器用NAT6的话可以拿到一个20开头的IPv6地址（其他路由器内设备共享这个IPv6），从下面的文章来看好像是比较特殊的IPv6。
DDNS方案（研究&吃瘪中）
我在用DDNS-GO的时候是ping不到香橙派的，我推测是缺公网IPv6到内网IPv4的NAT转发，导致连接断在路由器端。
上文提到的环境和我的情况相似，但是稍有不同的是我这个IPv6是共享的，也就是说缺一个路由器转发到香橙派的转发（好像可以通过路由器自带的端口转发来解决，待摸索）。
我现在合理猜测DDNS-GO的地址很有可能是部分地方设错解析导致无法访问。
不过必须吐槽一点，SSL证书部署大概会是这个穿透方案里面最吐血的一部分。
Frp方案（目前方案）
这个方案其实最简单方便……之前博客说说里面提到了SakuraFrp，因为这个方案实现是最傻瓜的。（只需要写配置文件然后跑一个服务就可以了）
目前我的Alist就是通过SakuraFrp暴露在外网的。SSL也是自动部署的，非常省心……
当然用Conoha的ip来跑frp穿透也不是不行……但是毕竟是日本ip，怎么想感觉都会很卡。
Zerotier方案（目前方案2）
这个方案倒是没啥好说的，就是类似QQ群一样，“加群”了就能访问“群友”的全部业务端口，私密性比较强。
唯一问题同样是Zerotier的行星根服务器在海外，而自己做月球根服务器是需要有公网ip（IPv4）的，因此最大问题还是传输有的时候会顿卡。
目前这个方案用在一些只有我自己的设备才可以访问的服务，比如香橙派上面的Navidrome。
CloudFlare Tunnel方案
谁想不开用这个方案啊……其实就是CF上面有个Zerotrust，里面可以通过跑一个docker实现CF服务器到本地服务的内网穿透，其本质有点像拿海外ip来穿国内的frp的那种。