这篇文章上次修改于 815 天前，可能其部分内容已经发生变化，如有疑问可询问作者。

大概是周五的时候，不知道什么原因，我每次登录我的tiny tiny rss的时候总是会出现一条错误提示。由于我刚开始接触到这类网络服务的搭建，所以我很自然地就认为是我部署在服务器上的 tiny tiny rss设置除了一些问题，然后就去上面瞎折腾了一通，然而还是没有效果。。。虽然后来发现是我chrome浏览器的某一个插件和ttrss产生了冲突。

问题在于，在我瞎折腾的时候，因为看着用户目录下面乱七八糟的东西感觉不好，于是就把我不太认识的文件夹全部删掉了，其中就包括ttrss的数据库！由于对这些网络服务结构了解不深，当时并不知道出了什么问题。。。唯一想到的就是重装。毕竟重启解决90%的问题，重装解决99%的问题，当然重买解决100%的问题，哈哈。

当时又因为科研上需要几个大型的数据集，然而作者们分享的地址都是Google Drive，我直接用学校的网下载不了。又因为数据集的文件大小都是几十个G的大小，很显然不可能在我这里通过翻墙软件下载下来再转移到学校的电脑上去。于是我想到了通过服务器来下载，然后再用nextcloud转移到学校的电脑上去。这里就要赞一下BuyVM家的机器了，无限流量，而且还可以轻松附加存储盘，用来部署我的nextcloud网盘也是相当适合的。

但是一个问题就来了，我的nextcloud是通过Docker部署的，而且我当时还没有设置Docker的volumes挂载，于是我只能手动把下载下来的文件手动转移到Docker的对应目录下面，而这个目录的名称是很长一段编码。。。

在从服务器转移到学校的电脑上的过程中，网速一度从10M/s降低到了1M/s，于是我联系了BuyVM的工作人员，帮我换了个ip，最后成功传输了一个数据集。但是在其中，我又因为对docker的不熟悉把ttrss搞崩了。

于是终于在几经挫折的情况下，我决定把自己的所有服务都使用docker通过docker-compose文件部署，这样的好处是写好docker-compose文件之后只要一个命令docker-compose up -d就可以轻松完成所有的部署，进行修改也非常轻松，只要在docker-compose中修改对应的选项之后再重新部署即可。

然后我整理了一下我目前使用的服务。首先是miniflux和rsshub通过别人现成的docker-compose文件部署的，然后是caddy服务用于转发网络请求是直接部署在服务器上的，再然后是ttrss是通过另一个人的docker-compose文件部署的，之后是nextcloud，通过docker命令部署，最后是这个博客，也是直接部署在服务器上。还有其中的数据库，ttrss用的是docker-compose中部署的postgres,typecho也就是这个博客使用的是教程推荐的sqlite，nextcloud我使用的是抄的教程的mysql数据库。

整理下来发现还真是乱的可以，有直接部署的，有通过不同的docker-compose文件部署的，还有通过docker命令部署的，数据库有sqlite，有Mysql，还有postgres。这么乱不仅仅是看起来不舒服，使用起来也很令人难受，尤其是没有通过docker-compose部署，经过时间的推移，我很容易就记不清楚了安装时候的配置。虽然可以用书签保留我当时参考的教程，但是总的来说还是不如把所有的服务都通过同一个docker-compose文件来部署来的方便。除此之外，这些通过不同方式部署的服务之间的关系也不好理清楚。

于是周六开始进行部署，一直忙活到周日晚上十二点左右，才终于把自己所有的服务都重新部署完毕。话说我本来打算周末玩两天游戏的，结果这么一搞连游戏都只打开了一次，还没玩成。主要是取消了miniflux服务，根据个人体验感觉ttrss比miniflux好用。还有把nextcloud的目录映射了出来，这样就可以更方便地向nextcloud里面传文件了。我还把所有应用地数据库统一改成了postgresql。（PS：刚刚突然发现我docker-compose文件中还保留了一个sqlite，是中间进行调试的的时候遗留下来的，但是似乎因为后来删除了一部分代码，所以没有部署成功，docker ps命令也就看不到，算了，以后再说。）

其中遇到了不少困难，但是现在看来主要是我对于docker服务的理解不够导致的。问题主要发生在数据库postgres、caddy、php和nextcloud上面。

Postgres遇到的问题是其他的服务打开之后无法访问数据库，解决办法是手动在postgres容器中创建对应的数据库，对应的用户，并赋予该赋予的权限，因为我已经通过volums把postgres的数据库存储在了docker外部，所以这种修改会被保留下来。

Caddy遇到的问题是要么无法访问文件，要么显示File not found，要么出来的不是网页，而是原始的php文件。原因是，caddy服务会把网络的请求根据特定的规则转发到另一个服务上去。比如我访问https://www.bzjz.tk那么caddy就会根据我在caddyfile文件中设置的根目录root项的设置提取出对应位置的index.php文件，如果这个位置没有在docker-compose中映射对，并在caddyfile中写出来，就有可能找不到对应的文件，也就无法访问了。

除此之外，有一些服务需要对页面进行处理，比如这个网站，就需要php把原始的index.php文件转换成现在看到的网页，这里需要使用的就是caddy中的php_fastcgi服务了。但是这个服务经过我的尝试，目前版本似乎默认的是caddy的/var/www/html位置。所以我如果想要同时处理两个服务，比如这里的nextcloud和php中的typecho，那么就只有/var/www/html只有一个程序可以使用。所以这里应该使用caddy的reverse_proxy而不是直接使用php_fastcgi，这样才能自定义对应的处理目录。（这里其实没说清楚，但是关键点我已经指出来了。）

还有php，官方的php:fpm-alpine镜像中没有包含对postgres的支持，为了解决这个问题我差点就要改用sqlite了，这也是为什么我的docker-compose文件中会有遗留的sqlite的原因。后来我决定自己构建一个镜像，毕竟代码在网上很容易就可以搜到，但是在服务器上构建的时候总是会出现there is no space on this device的错误。感觉原因是我的vps服务器的内存太小了，于是我注册了一个dockerhub的账号，然后在我现在使用的电脑上build了一个新的php镜像，上传到dockerhub。然后根据这个我自己部署的镜像我完成了php的配置。

还有nextcloud，第一次安装的时候没有选择那个可选的app，于是安装完成之后由于他的程序逻辑一定要访问那个不存在的app的位置，于是不停报错说在对应的位置找不到文件。最后删除所有的文件，重装并选择那些app之后程序正常运行。

本来准备昨天，也就是周一，忙完一些重要的事情之后就写这篇博客的，结果一不小心就打开了环世界这个游戏，然后一直玩到了半夜十二点，只能今天早上起来完成这篇博客了。