起因

使用浏览器保存密码，是我十年以来从使用傲游浏览器开始的习惯。得益于导出和导入的便捷，我换过很多浏览器，这些密码依然被完整的迁移到了我现在使用的 edge 浏览器上，且 edge 安卓版也支持作为密码管理器给应用填充密码，至此我都没有更换密码管理器的想法。

前阵子有博主给我推荐了 keepass，加上浏览器保存的四百多个密码中绝大多数使用的同一个密码，一旦泄露一个，被撞库的后果不堪设想，于是我有了更换密码管理器，且使用这玩意生成复杂密码的念头。

但是阴差阳错，keepass 太丑，我的服务器又可以一键部署 bitwarden，所以我最终选择了后者。

使用官方服务

一开始我并不是很愿意自己托管数据，一方面是 bitwarden 的官方服务够用，且一定程度够安全，自托管可能会面临更多的维护和容灾时间成本，所以我注册了官方的账户。

登陆后，我从 edge 导出了保存的密码——虽然需要输入系统密码，但是如柚子所言，浏览器保存的数据是很容易被导出或窃取的。导出完毕，我便删掉了浏览器保存的密码数据，决心使用 bitwarden 一条路走到黑。

起先体验还不错，但是没多久我就遇到了一个问题。在单位电脑上为某网站创建的账户使用了 bitwarden 生成的复杂密码，并且保存在了该应用中。而在家中的电脑上想自动填充时，却发现浏览器插件提示没有填充项目，即使我在本地一再点了同步密码库。

此时我意识到很可能是在单位时，该账户密码并未成功被同步到 bitwarden 的云端。

因此，我决心自部署该项目。

自部署和托管

在 1panel 中一键部署 bitwarden 是非常轻松的一件事，让我踩坑的点在于后续的配置中。

根据官方文档和碎月的建议，我决定使用域名的子目录来反向代理该服务，一定程度上减少它被恶意扫描和爆破的风险。理论上使用子目录反代很简单，只需要添加一条环境变量，在反代中添加该路径即可。

我的蠢问题

但问题来了：1.环境变量没有生效，2.反代只支持添加域名但不能包含路径。

针对问题2，我和碎月进行了较长的辩（嘴）论（硬）。我认为，一个域名都已经解析到目录 A 了，难道还能反代到目录 B 吗？

即，example.com对应网站的目录是 /opt/www/sites/，bitwarden 安装的路径是 opt/docker/bitwarden/，那么example.com/bit/是无法解析到后者的。还好碎月有耐心，让我明白了只需要在已解析域名的反向代理中添加前端请求路径和后端代理地址即可。

问题2解决了，问题1困扰了我好久。我添加的三个环境变量如下：

# 指定域名和子目录
DOMAIN=https://example.com/bit
# 禁用注册
SIGNUPS_ALLOWED=false
# 禁用邀请
INVITATIONS_ALLOWED=false

我首先在该服务目录下的 .env 中写入环境变量，重启服务，没生效；

在 docker-compose.yml 中硬写变量再重启，也没生效，碎月也不知道何故，为此，我还去 1panel 的项目中提了一个 issue （丢脸）。1panel 官方工作人员回复了我，并确认该情况不是 bug。在我多次尝试后发现了问题所在：修改 docker-compose.yml后我没有点重建！！！

不爱使用 docker 的我，最终为自己的无知感到了羞愧。

避坑

由于在应用商店更新应用会导致非持久化目录下的文件丢失（或覆写），所以我一直在考虑把 .env 添加到持久化目录中，在 docker-compose.yml里指定路径，还是把环境变量硬写在 docker-compose.yml里，最终我选择了后者。

为此，我和 deepseek 之间也有一段小小的插曲，因为允许它说脏话，所以我被它骂了，虽然后来它服软——因为我的环境变量里并不包含重要的敏感信息。

因为升级时可以勾选自定义docker-compose.yml，所以把环境变量写在这里要方便得多。

备份

虽然服务器已经稳定运行好几年了，我时不时会添加快照，但把鸡蛋放在同一个篮子里并非明智之举，所以我通过 1panle 的定时任务每天都会把 bitwarden 的数据同步到 onedrive 中，以免哪天需要恢复。如果你也选择自托管，我强烈建议使用脚本每天备份数据！

体验

自部署的服务无论是增删还是同步都超级方便快捷，除了保存网站或应用的登陆密码之外，我终于把此前明文写在 onenote 中的银行登录密码给迁移到了 bitwarden 的“备注”功能之中。

但是体验也有不那么好的点，在安卓端或浏览器插件中无法批量管理密码（可能是出于安全），只能在服务端的网页上批量操作。此外，在安卓端的自动填充有时会有延迟，比如在浏览器中点好几次都不会及时显示自动填充，在 APP 上创建密码也不会及时弹窗询问是否保存。但大体上使用没什么问题。

写在最后

自托管 bitwarden 让我尝到了甜头，于是最近这些天我在折腾另一件让我苦恼的事，甚至今天水这一篇文也是为了后面的记录做铺垫。

最近我的 onenote 频繁闪退（其实也不算闪退，有退出动画那样时不时自动关闭）。为此，我决定找一个平替，期间尝试了包括但不限于知名的 notion、obsidian、joplin，以及 google play 上的很多如 notesnook、anytype、standard notes、appflowy、silentnotes等等几十款笔记应用，没有一个近乎完美符合我的需求。

需求如下：免费或者开源，非国产，多端同步，支持自托管或加密同步到如 onedrive 或 webdav，支持单篇笔记加密，界面好看不臃肿，支持剪藏更好。下一篇再来详细谈谈我的简单评测。

由于众所周知的原因，使用 Docker 时可能会遇到诸多网络问题。然而，网络上关于此的文章充斥着杂乱无章的错误内容，而官方文档的描述也没有特别清楚。本文依据文档和亲身实践，整理 Docker 中各种代理配置方法，留供参考。

Docker daemon 代理

当执行 docker pull 拉取镜像，一般是从 DockerHub 等仓库拉取，此时容易遇到网络问题。

这一拉取过程实际上是 Docker daemon 在执行，而它是由 systemd 启动管理的，并不直接使用我们 shell 中配置的代理环境变量。为了让其走代理，需要编写其 systemd 配置。

文件位置：/etc/systemd/system/docker.service.d/http-proxy.conf。

内容示例：

[Service]
Environment="HTTP_PROXY=http://127.0.0.1:1080"
Environment="HTTPS_PROXY=http://127.0.0.1:1080"

保存配置后，需要重启 Docker daemon。注意：这会重启所有容器。

sudo systemctl daemon-reload
sudo systemctl restart docker

相关文档：Configure the daemon to use a proxy。

容器内代理

容器内的应用或许需要访问网络，我们也希望其流量通过代理。这需要在容器内配置环境变量。

可以在 Dockerfile 或者 docker run 的时候设定环境变量，但这要求对每个容器都写重复的配置。有一种更方便的方式：进行如下配置后，启动的容器都会自动设置 http_proxy 等环境变量。

文件位置：~/.docker/config.json

内容示例：

{
 "proxies": {
   "default": {
     "httpProxy": "http://example:1080",
     "httpsProxy": "http://example:1080",
     "noProxy": "*.test.example.com,.example.org,127.0.0.0/8,192.168.0.0/16"
   }
 }
}

指定 httpProxy 属性值，相当于在容器内同时设定 http_proxy 和 HTTP_PROXY 两个环境变量。

保存配置后，无需重启任何服务。在保存配置之后启动的 docker 容器，都会自动配置对应环境变量（之前的容器不会改变）。然而，应用是否读取该环境变量并使用代理设置，取决于应用的实现。这并不是一个标准。

⚠️ 注意：此处环境变量会在容器内被读取，所以地址 127.0.0.1 指的是容器自身，而非宿主机。

⚠️ 注意：如果容器是以 root 模式启动的（使用 sudo），上面所述的 ~/.docker/config.json 其实指的是 /root/.docker/config.json。

⚠️ 注意：curl 等工具并不支持 socks 代理，只支持 http。所以建议统一配置 http 代理。

相关文档：Use a proxy server with the Docker CLI。

Build 时代理

在运行 docker build 时，许多操作容易遇到网络问题。这个 build 过程其实也在一个 Docker 容器中进行，所以读取不到我们 shell 环境的代理环境变量，也访问不到我们的主机网络。

解决方案是，首先指定 build 时使用的网络环境为 host：

docker build --network=host

或者在 docker-compose.yml 中：

build:
  context: .
  network: host
  dockerfile: Dockerfile

接下来，在 Dockerfile 中，设置环境变量：

ENV http_proxy "http://127.0.0.1:1080"
ENV HTTP_PROXY "http://127.0.0.1:1080"
ENV https_proxy "http://127.0.0.1:1080"
ENV HTTPS_PROXY "http://127.0.0.1:1080"

我的终极代理解决方案

我们希望容器内外的网络都使用同样的代理。为了方便容器内的访问，更好的选择是将代理程序作为一个容器运行。

我的解决方案是：单独启动一个名为 proxy 的容器，专门负责进行网络代理；映射 1080 端口，为宿主机提供代理。

• 容器外：只要配置代理地址 http://127.0.0.1:1080。
• 容器内：只要加入 proxy 同一网络，并配置代理地址 http://proxy:1080。

⚠️ 注意：不要将此端口暴露在公网中，否则被 ISP 扫描到可能要写保证书。

Happy Self-hosting！

之前也想过将 django 项目打包成 docker 部署，但是由于之前的项目过于庞大，用到了系统的定时任务等各种系统服务，不知道打包成 docker 之后相关的服务是否依然能够启动，所以并未实施。

前几天做的我的足迹地图，项目相对来说比较独立，没有其他的依赖项，正好可以尝试一下。

首先在项目下创建 Dockerfile，写入以下内容：

# 使用官方Python运行时作为父镜像
FROM python:3.8.18-slim

# 设置工作目录
WORKDIR /app

# 将当前目录内容复制到位于/app中的容器中
COPY . /app


# 安装项目依赖
RUN pip install --no-cache-dir -r requirements.pip -i https://pypi.tuna.tsinghua.edu.cn/simple

# 暴露端口8000，与Django的默认运行端口一致
EXPOSE 10086

# 定义环境变量
ENV NAME=Django

# 在容器启动时运行Django的manage.py命令
CMD ["python", "manage.py", "runserver", "0.0.0.0:10086"]

网上代码来回抄，第二行都是FROM python:3.8-slim 如果这么写会导致下面的错误：

PS E:\Pycharm_Projects\BabyFootprintV2> docker build -t baby-footprint:1.0 .
[+] Building 21.2s (2/2) FINISHED docker:desktop-linux
 => [internal] load build definition from Dockerfile 0.0s
 => => transferring dockerfile: 568B 0.0s
 => ERROR [internal] load metadata for docker.io/library/python:3.8-slim 21.1s
------
 > [internal] load metadata for docker.io/library/python:3.8-slim:
------
Dockerfile:2
--------------------
   1 | # 使用官方Python运行时作为父镜像
   2 | >>> FROM python:3.8-slim
   3 |
   4 | # 设置工作目录
--------------------
ERROR: failed to solve: python:3.8-slim: failed to resolve source metadata for docker.io/library/python:3.8-slim: failed to do request: Head "https://registry-1.docker.io/v2/library/python/manifests/3.8-slim": dialing registry-1.docker.io:443 container via direct connection because has no HTTPS proxy: connecting to registry-1.docker.io:443: dial tcp 69.63.186.31:443: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

直接访问上面的网址docker.io/library/python:3.8-slim会发现根本没这么东西，所以要改成FROM python:3.8.18-slim

搜索一下，会有教程提示先下载 python3.8的 docker：

PS E:\Pycharm_Projects\BabyFootprintV2> docker pull python:3.8.18-slim
3.8.18-slim: Pulling from library/python
8a1e25ce7c4f: Pull complete
1103112ebfc4: Pull complete
b7d41b19b655: Pull complete
6a1ad0671ce8: Pull complete
de92c59aadaa: Pull complete
Digest: sha256:e796941013b10bb53a0924d8705485a1afe654bbbc6fe71d32509101e44b6414
Status: Downloaded newer image for python:3.8.18-slim
docker.io/library/python:3.8.18-slim

3.8.18是 ok 的，此时重新 build 即可：

PS E:\Pycharm_Projects\BabyFootprintV2> docker build -t baby-footprint:1.0 .
[+] Building 214.6s (9/9) FINISHED docker:desktop-linux
 => [internal] load build definition from Dockerfile 0.0s
 => => transferring dockerfile: 571B 0.0s
 => [internal] load metadata for docker.io/library/python:3.8.18-slim 0.0s
 => [internal] load .dockerignore 0.0s
 => => transferring context: 2B 0.0s
 => [1/4] FROM docker.io/library/python:3.8.18-slim 0.1s
 => [internal] load build context 0.9s
 => => transferring context: 43.30MB 0.8s
 => [2/4] WORKDIR /app 0.1s
 => [3/4] COPY . /app 0.2s
 => [4/4] RUN pip install --no-cache-dir -r requirements.pip -i https://pypi.tuna.tsinghua.edu.cn/simple 212.0s
 => exporting to image 1.4s
 => => exporting layers 1.4s
 => => writing image sha256:cba073b574f88f19be7487b29612e19b9826ab99e7b54ea748bd5df22e83e1a0 0.0s
 => => naming to docker.io/library/baby-footprint:1.0 0.0s

编译变成，就可以像 docker hub 推送镜像了，不过首先需要设置 tag,如果直接推送会提示下面的错误：

PS E:\Pycharm_Projects\BabyFootprintV2> docker push baby-footprint:1.0
The push refers to repository [docker.io/library/baby-footprint]
04013169f44d: Preparing
f7c443286fad: Retrying in 5 seconds
fd749af069d5: Retrying in 5 seconds
3482d4cd60de: Retrying in 5 seconds
370c0e78e3ea: Retrying in 5 seconds
a74bee0a48a5: Waiting
c8f253aef560: Waiting
a483da8ab3e9: Waiting
denied: requested access to the resource is denied

这个提示也比较坑人，由于 docker 被屏蔽，我一直以为是网络连接问题，直到后来才发现是路径问题。

通过下面的命令设置 tag 后 push：

docker tag baby-footprint:1.0 obaby/baby-footprint:1.0

PS E:\Pycharm_Projects\BabyFootprintV2> docker push obaby/baby-footprint:1.0
The push refers to repository [docker.io/obaby/baby-footprint]
04013169f44d: Pushed
f7c443286fad: Pushed
fd749af069d5: Pushed
3482d4cd60de: Pushed
370c0e78e3ea: Layer already exists
a74bee0a48a5: Pushed
c8f253aef560: Pushed
a483da8ab3e9: Layer already exists
1.0: digest: sha256:0d0c0989a64cc3f3e192e5c8e7bc4931676d49ab66d810061a1daec6b1a6af58 size: 2000

受限于网络问题，可能会 push 失败，多重试几次就 ok 了。

最后就可以直接 docker 安装运行啦:

docker push obaby/baby-footprint:tagname

我有 Mac 和 Windows，这些年折腾软件方面的环境 Linux 用得比较多，最近想安装一个 Kubernetes 的本地环境，本着 “生命不息，折腾不止” 的精神，打算在 Windows 上动手。了解到可以尝试 Minikube，在此简单记录一下。

首先得要安装 Docker，但是在 Windows 下跑 Docker 有两种方式，WSL（Windows Subsystem for Linux）或者 Hyper-V。我首先把这些 Windows 组件都勾上：

我两条路都去走了一下，为了使用 Hyper-V，我还去 BIOS 里面打开虚拟化支持的选项。不过，后来才知道，因为操作系统版本是 Windows 10 Home，虽说 Windows 上面跑 docker 有两种方式：

• 一种是使用 WSL
• 另一种是使用 Hyper-V

但在 Windows 10 Home 版本上只支持第一种。由于 Hyper-V 本质上是额外的虚拟机，而 WSL 更新，是虚拟化的 Linux 环境，是 Windows 操作系统原生支持的，性能要好一些。

其实，在 Docker 的设置里面也有说了：

可以列出所有 WSL（我使用的 WSL 2）目前支持的 Linux Distributions：

wsl --list --online

可以选一两个自己熟悉的安装了体验一下：

wsl --install Ubuntu
wsl --install Debian

整个 Windows 的文件系统都可以以 Linux 的方式访问。以往我一般在 Windows 上运行 Linux 命令都是使用 Cygwin 的，但是现在我了解到两者很不相同，WSL 是真正的虚拟化 Linux 环境，而 Cygwin 只不过把一些 Linux 命令编译成 Windows 的二进制版本。

安装 Minikube 和相关工具，配置环境变量。这次学到了可以用 Chocolatey，它是 Windows 下的软件安装工具。比如：

choco install kubernetes-cli

Minikube 可以以 VM、container，甚至 bare metal（Windows 下不支持）的方式来运行，通过 driver 参数指定。

我们使用 docker，这也是官方认定 preferred 的一种方式。这种方式下，Minikube 应用本身会作为 Docker container 跑在 Docker 里面（driver 的含义），同时，Minikube 也会使用 Docker 来跑其它的应用 container。

minikube config set driver docker
minikube delete
minikube start --driver=docker

看一下状态：

Done! kubectl is now configured to use “minikube” cluster and “default” namespace by default

看一下状态：

minikube status
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

此外，检查一下 WSL 已经安装的 Linux subsystem，能看到：

wsl -l
Windows Subsystem for Linux Distributions:
Ubuntu (Default)
docker-desktop
Debian

在 Docker 的 UI 上，也能看到：

跑起来以后，用 kubectl 验证一下：

kubectl cluster-info
Kubernetes control plane is running at https://127.0.0.1:57514

查看所有 namespace：

kubectl get pods –all-namespaces

启动 dashboard：

minikube dashboard

接着，创建和部署一个 hello minikube 的 service：

kubectl create deployment hello-minikube --image=kicbase/echo-server:1.0
kubectl expose deployment hello-minikube --type=NodePort --port=8080
kubectl get services hello-minikube

通过访问：

minikube addons list

可以列出一堆可以立即安装的 addon，有一些是 K8s 的，有一些是 minikube 的，比如：

minikube addons enable auto-pause

这个可以在一段时间没有使用的情况下，暂停 K8s。

还有一个 addon 能让 dashboard 的 metrics 显示更多信息：

minikube addons enable metrics-server

后来，一通折腾以后发现，原来 Docker 的 settings 里面已经有了一个 Kubernetes 选项：

原来新版本的 Docker 里面自带了一套 K8s，它是完全跑在 Docker instance 里面，并且无法配置的，主要用于本地测试。它的运行也是基于 WSL。

现在就试一下，停掉 Minikube：

minikube stop

UI 确认确实停了（或者 docker ps）：

然后把 Docker 的 Kubernetes tab 上面的两个选项都勾上，apply & restart。

不过等了好久，似乎卡在这一步了，我 reset 并且更新 Docker 以后，问题解决。打开以后我看到 Docker 启动了一堆 container。确认跑起来也没问题：

kubectl get nodes
NAME STATUS ROLES AGE VERSION
docker-desktop Ready control-plane 10m v1.30.2

文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》

其实这次是升级到v0.18.2版本，本着好记性不如烂笔头的原则，给大脑腾出空间，再次记录下VPS宝塔国际Docker安装Memos过程。

1、拉取镜像

进入宝塔国际aaPanel Docker – Image，点击Pull image，在Image中输入 neosmemo/memos:stable 。

Docker安装Memos

2、创建容器

拉取好镜像后，依次击 Container – Add Container。

Name里输入memos，Image就选择刚才拉取的镜像 neosmemo/memos:stable，容器端口Container port和服务器端口Host port都选择5230。

把Container directory容器目录 /var/opt/memos 挂载到Server directory服务器目录 /root/memos ，memos的数据库文件都在这个目录下。

最后 Restart rule 选择 Restart at the time of error (restart 5 times by default)。

Docker部署Memos

安装完毕。

宝塔国际aaPanel自带安装Docker，安装了几次都失败，最后仔细看了安装日志，才发现其中的问题。

--2023-11-28 13:42:13-- https://node.aapanel.com/install/0/docker_install_en.sh
Resolving node.aapanel.com (node.aapanel.com)... 104.21.79.196, 172.67.171.7, 2606:4700:3031::6815:4fc4, ...
Connecting to node.aapanel.com (node.aapanel.com)|104.21.79.196|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 16976 (17K) [application/octet-stream]
Saving to: ‘docker_install_en.sh’

0K .......... ...... 100% 34.6M=0s

2023-11-28 13:42:13 (34.6 MB/s) - ‘docker_install_en.sh’ saved [16976/16976]

selecting download node...
https://dg2.bt.cn
{"product": "Linux panel", "setup_path": "/www/server", "openlitespeed_path": "/usr/local", "language": "English", "title": "aaPanel Linux panel", "brand": "aaPanel", "root_path": "/www", "template": "default", "logs_path": "/www/wwwlogs", "home": "https://www.aapanel.com", "recycle_bin": true}
https://node.aapanel.com

cat: /etc/redhat-release: No such file or directory
cat: /etc/redhat-release: No such file or directory
Get:1 http://security.debian.org/debian-security bookworm-security InRelease [48.0 kB]
Hit:2 http://deb.debian.org/debian bookworm InRelease
Get:3 http://deb.debian.org/debian bookworm-updates InRelease [52.1 kB]
Get:4 http://security.debian.org/debian-security bookworm-security/main Sources [61.5 kB]
Get:5 http://security.debian.org/debian-security bookworm-security/main amd64 Packages [105 kB]
Get:6 http://security.debian.org/debian-security bookworm-security/main Translation-en [63.5 kB]
Ign:7 https://mirrors.aliyun.com/docker-ce/linux/debian 12 InRelease
Err:8 https://mirrors.aliyun.com/docker-ce/linux/debian 12 Release
404 Not Found [IP: 47.246.23.147 443]
Reading package lists...
E: The repository 'https://mirrors.aliyun.com/docker-ce/linux/debian 12 Release' does not have a Release file.
Reading package lists...
Building dependency tree...
Reading state information...
apt-transport-https is already the newest version (2.6.1).
ca-certificates is already the newest version (20230311).
curl is already the newest version (7.88.1-10+deb12u4).
0 upgraded, 0 newly installed, 0 to remove and 30 not upgraded.
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://security.debian.org/debian-security bookworm-security InRelease
Hit:3 http://deb.debian.org/debian bookworm-updates InRelease
Ign:4 https://mirrors.aliyun.com/docker-ce/linux/debian 12 InRelease
Err:5 https://mirrors.aliyun.com/docker-ce/linux/debian 12 Release
404 Not Found [IP: 8.48.85.2 443]
Reading package lists...
E: The repository 'https://mirrors.aliyun.com/docker-ce/linux/debian 12 Release' does not have a Release file.
Reading package lists...
Building dependency tree...
Reading state information...
Package docker-ce is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'docker-ce' has no installation candidate
curl: (23) Failure writing output to destination
chmod: cannot access '/usr/libexec/docker/cli-plugins/docker-compose': No such file or directory
Requirement already satisfied: pytz in ./pyenv/lib/python3.7/site-packages (2023.3)
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv

[notice] A new release of pip is available: 23.2.1 -> 23.3.1
[notice] To update, run: /www/server/panel/pyenv/bin/python3.7 -m pip install --upgrade pip
Requirement already satisfied: docker in ./pyenv/lib/python3.7/site-packages (6.0.1)
Requirement already satisfied: packaging>=14.0 in ./pyenv/lib/python3.7/site-packages (from docker) (23.1)
Requirement already satisfied: requests>=2.26.0 in ./pyenv/lib/python3.7/site-packages (from docker) (2.28.2)
Requirement already satisfied: urllib3>=1.26.0 in ./pyenv/lib/python3.7/site-packages (from docker) (1.26.15)
Requirement already satisfied: websocket-client>=0.32.0 in ./pyenv/lib/python3.7/site-packages (from docker) (1.5.1)
Requirement already satisfied: charset-normalizer=2 in ./pyenv/lib/python3.7/site-packages (from requests>=2.26.0->docker) (3.1.0)
Requirement already satisfied: idna=2.5 in ./pyenv/lib/python3.7/site-packages (from requests>=2.26.0->docker) (3.4)
Requirement already satisfied: certifi>=2017.4.17 in ./pyenv/lib/python3.7/site-packages (from requests>=2.26.0->docker) (2022.12.7)
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv

[notice] A new release of pip is available: 23.2.1 -> 23.3.1
[notice] To update, run: /www/server/panel/pyenv/bin/python3.7 -m pip install --upgrade pip
|-Successify --- Command executed! ---

阿里云镜像源的存储库中没有 Release 文件。

E: The repository 'https://mirrors.aliyun.com/docker-ce/linux/debian 12 Release' does not have a Release file.

那就使用官方源安装 Docker。
如果是新的系统，需要安装一些必要的软件包，而我安装了宝塔国际，且之前已经安装过，则跳过这一步。

apt update
apt upgrade -y
apt install curl vim wget gnupg dpkg apt-transport-https lsb-release ca-certificates

加入 Docker 的 GPG 公钥和 apt 源。

# 添加 GPG 公钥
curl -sSL https://download.docker.com/linux/debian/gpg | gpg --dearmor > /usr/share/keyrings/docker-ce.gpg
# 添加 apt docker 源
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-ce.gpg] https://download.docker.com/linux/debian $(lsb_release -sc) stable" > /etc/apt/sources.list.d/docker.list

然后更新源再安装 Docker。

# 更新软件包
apt update
# 安装 Docker
apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin

安装成功后，刷新 aaPanel 面板就可以正常运行 Docker，不再提示没有安装 Docker了。

宝塔国际aaPanel Docker

2020年前后，当华为海思被美国制裁时，国内安防芯片缺口很大（安防领域，当时海思IPC SoC大约占有70%市场，DVR/NVR SoC大约占有90%市场）。之后群雄逐鹿，瑞芯微也适时推出了两款面向IPC的SoC芯片，RV1126（4K800万IPC）及RV1109（500万IPC)。RV1126采用四核32位ARM Cortex A7架构，有2T算力的NPU，适合用来做视频编解码，跑与视频相关的算法模型。

手边有一块闲置很久的基于RV1126的嵌入式开发板，1G内存，自带8G eMMC硬盘。闲暇之余，想用来安装宝塔面板，搭建nginx等环境，然后跑web应用。厂家提供的固件是基于 buildroot的，如此，需要从源代码开始，编译和配置自己需要各种软件和库。对此我一窍不通，难度太大，只能作罢。

最近发现厂家更新了固件，提供了基于Ubuntu的底层固件，之前的想法又冒出来了，试了试，居然成功了，这里做些回顾记录。

刷机

刷机方法与刷安卓手机类似。电脑首先安装usb驱动，瑞芯微有提供驱动安装助手–DriverAssitant_v5.0（下载）。驱动安装好后，开发板通过USB与电脑连接，识别到设备。

瑞芯微的刷机工具–RKDevTool（下载），刷机过程中可能出现的问题与安卓刷机基本一样，包括不限于USB线，设备连接，识别，驱动等方面。

RV1126开发板厂商提供的基于Ubuntu的固件–RV1126-Ubuntu-20.04-firmware_20240227（下载）。

环境搭建配置

刷完机，插上网线，因为设备默认DHCP，搜索查询到设备的IP，然后SSH登录。

1panel面板

因为时常操作云服务器，此时第一想法是安装宝塔面板。却被提示在线安装的宝塔，不支持这个arm 32位设备。让去试试宝塔5.9。简单搜索了下，不知道去哪弄宝塔5.9的安装包，官方的离线安装服务里可能有旧版的，但要收费。（写此博文时，又在网络搜索一番，发现有好心人搜集整理了旧版本的宝塔，此处）

转念想到何不试试其他的面板程序，比如1panel。1panel面板官网写着支持armv7l服务器架构。试了下，果然安装成功。有宝塔的经验在先，1panel面板的安装，使用上手很快。终端SSH及文件管理，很直观，与宝塔的使用基本一致。

frp

为了方便SSH远程登录，及面板的远程管理以及后续web站点能外网访问，首先用上frp。用一台阿里云香港服务器（2C2G30M）做frp的服务端，配置好。虽然第一次使用frp，因工作原因，对p2p，nat穿透，端口映射，DDNS知识了解很多，所以对frp理解，上手，使用起来很容易。

frp的设计理念可能是要保持服务端配置的精简，统一（在客户端做各种区分），比如保持服务端唯一的对外http端口，https端口，ssh端口等。如果有多个对外服务（比如web应用），只需要在frp客户端做配置即可，通过绑定不同域名来区分不同web应用（而非常规的采用不同端口区分不同web应用），如此思路很清晰，就是有点费域名。:-)

持续将近半个月的frp使用下来，很稳定，速度也很好。当然，这可靠性多半要归我这台2C2G30M的阿里云香港服务器。看网上的讨论，这个系列的阿里云香港服务器很抢手，性价比很高。我比较看重的，回国内延时非常低，在广州ping值延时只有8-9ms，比广州服务器ping值还低。（对于我用来科学上网，非常完美）。

说个题外话，我曾持续（从一个月到一年时间不等）测试各种云的香港服务器（比如狗云，马云，鸡云，草云。当然还有大厂的，腾讯云，华为云，天翼云等），回大陆线路，表现最好最稳定，性价比最高的还是阿里云。

应用

解决了服务器远程管理，外网访问问题。剩下的就是搭建网站了。使用宝塔时，习惯一键安装NMP等环境。1panel也有类似功能，不过其提供的默认web环境是OpenResty，安装时却出了点状况，始终安装失败。

1panel的理念是一切皆docker。安装的所有应用均是基于docker的。安装OpenResty失败，起初以为是docker镜像源，网络问题。不过，这个很快排除了。

前段时间网络上讨论很多，docker hub及国内的众多加速服务在国内完全无法用，当然解决办法也很多。我比较喜欢的办法，对于个人用户，可以将常用的镜像通过GitHub action同步到阿里云容器镜像服务 ACR，然后选择公开或者私有，需要时从ACR拉取容器镜像。（见 docker_image_pusher）

这种方法，我使用多次，国内服务器上拉取容器镜像，速度很快，也稳定可靠。当然，更常规的做法是使用docker hub镜像加速，比如1panel提供的临时加速地址：https://docker.1panel.live 。目前大环境下，国内的docker hub镜像站几乎都关了。我上面提到的docker image pusher方法对于个人用户是非常实用的。

排除网络问题，查看日志，发现安装OpenResty失败的原因是因为1panel商店里上架的这个版本不支持我使用的armv7l处理器。此时恍然大悟，然后又有点忧心。相较于x86，armv7l算比较小众，很多docker应用可能没有适配。如果通过1panel自带的商店安装，估计很多安装不了。如此，对于这个开发版使用1panel面板作用不大了。当然1G内存，外加4核心处理器，本身有点鸡肋和尴尬。也只能用来跑些简单的web应用。

找到问题以后，手动安装了nginx/1.18.0，PHP 7.4.3-4ubuntu2.23 (cli)，这样能来跑静态及PHP站点了。

目前这个开发板上运行的web应用有：

• 1panel面板
• frp
• Pi Dashboard
• twikoo（实验）
• uptime-kuma
• blog（节点之一）

之前在网友小宋的博客看见介绍的用来监控树莓派状态的应用Pi Dashboard，UI比较好看，起初试了在云服务器上跑，但是x86的服务器获取不到CPU温度。如今这个是arm的开发版，安排上。

通过docker安装的twikoo，uptime-kuma可以成功运行。

作为我这个hexo博客节点之一（目前我这个博客节点有：阿里云广州，华为云北京，京东云北京，海外netlify以及此开发板的香港服务器frp反代）。通过Github action构建，然后分发到不同节点服务器上，方法参见我之前的博文：博客网站更新总结-2023–Github-action及通过GitHub Action将博客网站等静态文件同步到云服务器。

考虑停电，断网，设备重启等意外情况，给相关程序加上开机启动，进程守护。同时因为只有1G内存，加上定时任务，定时清理内存，缓存。此时1panel面板的价值作用体现了。

前面提到frp是通过不同域名区分不同网站的，最后各web网站的访问地址是域名+端口，比如one.jiangyu.org:8090，two.jiangyu.org:8090。给这些源站套上CDN，就能不带端口，直接用绑定的CDN域名访问对应的web站点。只是这样一来，就更费域名了。:-)

还有一个问题。绑定CDN以后，我习惯强制https，如此需要给CDN上传SSL证书。如今SSL证书有效期已缩短到90天（我曾在6个月前的博文 SSL证书，部署及相关知识中总结过与SSL证书相关的知识，彼时证书有效期还多是1年，半年不到普遍都是90天了），如果自己的VPS部署站点，开启https，申请SSL证书，然后绑定，不断更新，这都能自动化完成。可是在CDN应用里，需要自己上传SSL证书，如果过期，需要重新再上传新的证书。如果使用的是大厂CDN，这个问题比较好解决，厂家开放了各种api，基于此很多大神帮忙造好了轮子，SSL证书申请，上传到CDN，部署，更新都能通过脚本自动化完成。可是对于小厂CDN，一般没开放api或者没有现成的造好的轮子，需要自己频繁手动更新SSL证书，是个大问题。

最近看到有某CDN小厂提供了名为证书无忧的服务，能很好解决上述问题。在CDN配置里，第一次先上传自己的SSL证书，在证书到期前，会自动更新有效期为 90 天的免费证书。目前公测期间这个功能免费，以后可能每次成功更新证书收费1-2元。这是个很好的功能，不知道会不会有其他CDN厂家跟进。

其他

这个开发板尺寸100 x 60mm，比树莓派略大，买来一个树莓派的亚格力外壳（外壳整体尺寸与这个开发板相当），重新钻孔，保护起来。买外壳时，看见店家有与外壳配套的散热风扇，也买了一个。测试了一段时间，对比发现，这个5V 0.2A的小风扇能给CPU降温5-6℃。不过因为RV1126这颗SoC面向的是安防，消费类IPC领域，低功耗，温度控制这块做得比较好。即使不加散热风扇，在室温30℃时，一般负载下运行时的最高温度也只在50℃上下，离会降频的85℃还很远。

这个开发板有个40pin 的 gpio接口，厂家文档说兼容树莓派的接口，除此没有更多资料。本来想着如同树莓派一样，接几个诸如温度，湿度这样的传感器，调试一下，资料欠缺，需要补的课很多，只能暂时作罢。

在使用 CapRover 并配置域名为 HTTPs 域名时，在你访问管理后台时，可能会导致触发Chrome 自己的无限 Redirect 的问题。

之所以出现这个问题，是因为 CapRover 的架构导致的：CapRover 在最外层是一个 Nginx，SSL 证书也是在这一层完成的。而 CapRover 的默认配置，在将请求向后转发时，透传的域名会是不含 HTTPs 的协议标识的，导致 WordPress 认为发来的请求是非加密的。

而 WordPress 识别到你的请求未加密，就会返回 302 让你进入 HTTPS的链接。但新的请求并不会带上 HTTPs 的标识，导致进入无限循环。

解决这个问题的一个简单处理的方式是 — 在你的 wp-config.php 中加入如下代码，来告诉 WordPress，这个请求已经是 HTTPs 保护的了，你直接处理就好。

/* for ssl in docker */

define('FORCE_SSL_LOGIN',true);

define('FORCE_SSL_ADMIN',true);

$_SERVER['HTTPS'] = 'on';

在一开始使用 CapRover 时，我使用的是一个 10 GB 的数据盘，但在部署了诸多应用后，10GB 的数据盘已经无法满足我的需求，于是我就对其进行了扩容，扩容至 20GB。在完成扩容 & 重启后，仍需要执行 Linux 的扩容命令 resize2fs 来扩容硬盘。

但由于 CapRover 中运行的服务跑在这个数据盘上，并没有办法直接在这个数据盘上进行扩容（进程会持续读取文件），因此，需要先将 CapRover 上的服务暂停，暂停后进行扩容，并重新启动服务。

CapRover 底层是使用 Docker Swarm + Nginx 来进行的，因此，我们只需要使用 Docker Swarm 的命令，来停止服务运行即可。

1. 获取服务名称

首先，你需要先获取到当前所有在跑的服务，以便于稍后去暂停。执行 docker service ls 来获取到具体的服务名称。

2. 拼接所需的命令

在 Docker Swarm 当中，并没有直接的 Start or Stop 概念，而是通过将 Replica 设置为 0 来实现关闭的能力。这个命令可以通过 docker service scale 服务名=服务数 来实现。因此，你需要将对应的服务设置为 0 来解决这个问题。你可以先行把开启和停止的命令拼接好，从而实现快速的启动和关闭，尽可能的减少宕机时间。

如果是有多个服务，可以直接拼接在后面，从而实现一次关闭 / 开启多个服务。

# docker service scale service_name=1 service_name_2=0
# 停止命令
docker service scale srv-captain--blog-ixiqin-com=0 srv-captain--mysql-8-production-db=0 srv-captain--pgsql-16-production=0 srv-captain--redis-server-production=0
# 启动命令
docker service scale srv-captain--blog-ixiqin-com=1 srv-captain--mysql-8-production-db=1 srv-captain--pgsql-16-production=1 srv-captain--redis-server-production=1

3. 执行命令，扩容硬盘

你可以先执行停止命令，然后执行扩容命令。完成扩容后，重新启动，即可完成整体的扩容。

我在开发前端应用的时候，基本上使用的都是 Vercel ，究其原因，主要是以下几个点：

1. Vercel 可以方便的与 Github 整合，提供简单易用的部署方式：写完代码，测试完成后推送到 Github ，就会自动部署到线上。对于小型项目来说，可以简化部署的流程。
2. Vercel 提供了自定义域名和自动配置的 SSL，提供了简单的配置方式：在现在 SSL 成为标配的模式下，在 Vercel 你只需要把域名解析到 Vercel ，并在你的 Project 当中绑定域名，就会自动完成域名绑定和 SSL 申请和续期。
3. Vercel 提供了 FaaS 环境：写应用的时候，很多时候不只有前端的需求，这个时候， Vercel 自身的提供的 FaaS 环境可以帮助你完成基本逻辑的编写。

但 Vercel 毕竟是以前端为主，且函数运行时长也有限制，对于一些比较重的场景下，Vercel 还是不太够用。刚好最近我把服务部署从传统的 LAMP 换成了 Docker Based PaaS，我使用的 CapRover 提供了类似的体验。

使用 Cap Rover 你能获得的体验：

• 上传代码后，自动部署到 Production
• 绑定域名后，自动配置 SSL 证书，且可以配置其他域名转发到主域名

具体操作步骤见下：

安装 CapRover

CapRover 的安装我就不再赘述，跟随官方的说明安装即可。

绑定根域名

当你登录 CapRover 时，CapRover 会让你绑定一个泛域名解析，你可以根据自己的需要，绑定一个二级或者三级域名，然后在 DNS 解析一个 * 到这个服务器上。这样后续部署的服务就会自动解析一个 服务名.你的域名 ，用于服务的初步访问（类似于 xxx.vercel.app)。

上传代码至 GitHub

在 Github 上创建一个代码仓库，并把你自己的项目部署上去。如果你有已经写好的 Dockerfile，可以一并上传上去。如果没有的话，则可以选择参考 CapRover 提供的 Sample App ，里面提供了常见语言的部署参考。

创建容器并配置环境

完成代码上传后，你可以进入到 CapRover 后台，创建一个新的 App。这里可以输入你喜欢的名字，方便后续查找即可。

创建完成后，点击下方列表中的应用名称，进入应用的配置页面，并切换至 Deployment 页面。

在这个页面，可以找到 Method 3 ： Deploy From GitHub/ Bitbucket/Gitlab，填写你的仓库信息、分支名、用户名。密码你可以选择直接使用你的密码，也可以选择创建一个 Personal Access Token ，或者是在仓库里配置一个 Deploy SSH key 均可。

配置完成后，会自动给你生成一个 Webhook 地址，复制这个 Webhook 地址。

配置 Github 上的 WebHook

复制上方的 Webhook 地址，并进入到 Github 你的仓库 – Settings – webhooks 页面，新增一个 Webhook。

粘贴你刚刚复制的 URL，Content Type 选择 application JSON，并在下方选择触发部署的时机。

点击报错。

等待自动部署

接下来你就可以通过提交代码，来让其自动完成部署，从而享受类似于 Vercel 的推送即部署的体验～。

在开发应用的时候，我们会选择使用 PostgreSQL 作为数据库进行开发，但在 Github Actions 环境下，默认是没有 PostgreSQL 作为数据库后端的，这个时候如果你想要测试一些和数据库相关的逻辑，就不得不面临两个选择：

1. 使用一个和生产环境无关的数据库，比如 SQLite。
2. 在 Github Actions 当中添加一个 PostgreSQL。

前者是大多数常规的做法，大概率也不会出现什么问题（毕竟作为 CURD 仔，我们用的大部分时候都是一些 ORM，很少裸写 SQL），不过依然存在一些概率是你写了一些 PostgreSQL Only 的 Query 无法覆盖到测试。

另外就是本文的核心了：在你的 Github Actions 当中添加一个 PostgreSQL。

Github Actions Service

想要实现这个效果，我们依赖了 Github Actions Service Containers 这个能力。

服务容器是 Docker 容器，以简便、可携带的方式托管您可能需要在工作流程中测试或操作应用程序的服务。 例如，您的工作流程可能必须运行需要访问数据库和内存缓存的集成测试。

您可以为工作流程中的每个作业配置服务容器。 GitHub 为工作流中配置的每个服务创建一个新的 Docker 容器，并在作业完成后销毁该服务容器。 作业中的步骤可与属于同一作业的所有服务容器通信。 但是，你不能在组合操作中创建和使用服务容器。

GitHub

你可以选择你需要运行测试的环境中，找到对应的 Job，并在 Job 下新增一个 services ，即可为你的 job 设定一个依赖的服务容器，它可能是数据库 、 缓存之类的。比如我这里用的就是 PostgreSQL。

我的 Github Actions 完整参考：

• services 是我运行的服务容器。
• steps 是我的真正的测试流程。

name: Django CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

env:
  DEBUG: true
  SECRET_KEY: django-insecure-github-actions
  DB_NAME: postgres
  DB_USER: postgres
  DB_PASSWORD: postgres
  DB_HOST: localhost
  DB_PORT: 5432

jobs:
  build:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres
        env:
          POSTGRES_PASSWORD: postgres
        # Set health checks to wait until postgres has started
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
        ports:
          - 5432:5432

    strategy:
      max-parallel: 4
      matrix:
        python-version: [3.12]

    steps:
    - uses: actions/checkout@v3
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v3
      with:
        python-version: ${{ matrix.python-version }}
    - name: Install Dependencies
      run: |
        python -m pip install --upgrade pip
        pip install -r requirements.txt
    - name: Run Tests
      run: |
        python manage.py test

在 从 LAMP 到 Docker based PaaS 工具 当中，我提到我现在使用的是 Docker Based PaaS 产品来托管站点。本站目前其实就是跑在 Docker 上的。

使用默认的 WordPress 镜像时，我发现一个问题：没有支持 Redis 拓展！我使用 Redis 来缓存 Query，提升访问的性能。如果缺失了 Redis 拓展，就会减少一部分缓存的能力。于是开始研究如何在官方的 WordPress 镜像上加入 Redis 拓展。

根据 WordPress 镜像的官方说明，我们可以 docker-php-ext-* 命令来配置镜像，安装必要的拓展，来满足我们日常使用的需求，并给出了官方的参考。

不过，我在验证 Redis 拓展时，使用 docker-php-ext-* 命令没有配置成功，好在可以使用 pecl 来安装。于是，我便将 Dockerfile 修改成如下内容，来完成对于 Redis 拓展的安装。

FROM wordpress:latest
RUN pecl install -o -f redis && rm -rf /tmp/pear && docker-php-ext-enable redis

修改好 Dockerfile ，然后重新启动，一切都好了～

在 白宦成简史 当中，我写到过，我从 2013 年就开始写博客，至今已经 11 年有余。而我和互联网、编程的缘分，也从 2013 年开始。

在 2013 年的时候，我主要是使用 WordPress 建站（现在也还在用，比如本站）。所以，从哪个时候开始，我开始接触 LAMP、LNMP 这些个概念，并在过去的若干年里，使用了不少「一键安装包」来部署我的网站。

我用的一键安装包 / 控制面板不算少：LNMP.org 、OneInStack（从它还是 LinuxEye 的时候开始用），LAMP.sh等一键配置包，AMH、WDCP、AppNode、Webmin、BT、VestaCP 、Virtualmin等等一系列控制面板。

如果说这些工具有什么相同点，那便是都提供了十分方便的 LAMP / LNMP 的配置方式，让彼时不够专业的我、主要是用别人开发好的应用的我能够快速部署一个基于 MySQL + PHP 的应用，让它 Run 起来。

而随着时间的流逝，我已经不再是曾经的我了。我不再局限于使用别人写好的程序，我开始自己写；我不再局限于使用 PHP 来编写程序，我同样会使用 Python、Ruby、Golang 、Node.js 来编写应用程序；所有的这些，都告诉我，我需要在现有的框架和程序上去做很多额外的配置，比如，我需要在 LNMP 的基础之上，配置 NPM，以完成 Node.js 的构建；我需要在系统上配置 Docker ，以便于去运行某些需要复杂配置的环境。

曾经那些可以帮到我的程序已经不再能帮到我了，如今的他们，成了我的累赘。我开始需要为了他们去多做一些事情了。

如今的我，更需要的是一个能够基于 Docker 来运行的管理工具，能够帮助我完成不同环境的配置、管理的能力。我需要的是一个类似于 Heroku 的管理工具，能够让我把更多的精力放在把事做好上。

我试用了

• Dokku
• Coolify
• EasyPanel
• 1Panel
• CapRover

最终，选择了 CapRover ，主要原因有几个：

1. 支持基础的 Docker 管理功能：这样意味着我其实可以在网页端管理这些资源。
2. 使用 Nginx ，并集成了 Let’s Encrypt：我的应用都希望有 HTTPs 的能力，所以默认集成了 Let’s Encrypt 可以帮助我解决不少的问题。我也不需要自己去维护一个 Traefik 来解决请求转发的问题（我没有使用 Rancher / Kubesphere 之类的容器管理平台也是这个原因）
3. 提供了一些一键配置的 Sample：这意味着我把一些我常用的应用迁移过去的时候，可以抄袭一下其官方推荐的配置，可以降低我的使用门槛。
4. 足够久远：CapRover 作为一个从 2017 年就开始运作的工具，代表着有足够多的 issue 可以供我参考 / 使用，可以减少我踩坑的概率。
5. 提供了 CLI 来进行部署：对于一个经常需要部署的人来说，提供 CLI / Github Action 可以帮助我快速实现多种不同需求下的部署，帮助我来提升效率。

种种的这些，让我最终从过去的 LNMP，跳船到了 Docker Base PaaS 工具上。

在开发 RoR 的时候，经常需要配置本地的开发环境。但如果你需要在一些云端开发环境（比如 Github Codespaces）中配置你的开发环境时，就会变得比较麻烦。

但得益于 Docker，我们可以直接使用 Docker 镜像来完成我们的开发环境。

Ruby 官方提供了 Docked 来帮助我们完成这个环境的构建。

配置

假设你已经完成了 Docker 的安装，接下来你只需要做如下操作，来配置 Docked Rails Cli

docker volume create ruby-bundle-cache
alias docked='docker run --rm -it -v ${PWD}:/rails -v ruby-bundle-cache:/bundle -p 3000:3000 ghcr.io/rails/cli'

为了方便你的使用，你还可以将上述的输入放在 .bash_rc 或 .bash_profile 当中。

使用

接下来，你只需要使用 docked 你要执行的命令 来执行各种命令，比如官方给出的这样的 Sample。

docked rails new weblog
cd weblog
docked rails generate scaffold post title:string body:text
docked rails db:migrate
docked rails server

updates in 2023.12.19

由于官方默认的 docked 没有 PGSQL 的支持，所以我自己 Fork 了一个版本，做了一些更新。

具体可以见 https://github.com/bestony/runs

得益于***，目前需要代理的服务越来越多了，至于为什么需要代理，参考前面***部分。

昨天现在服务器上安装个 mqtt 的服务，这次不想直接装了，想通过 docker 来装一个，主要是服务器上跑的业务太多了，怕源码安装或者通过其他安装产生一些不必要的麻烦。

结果在服务器运行安装，直接芭比了，这倒是也在意料之内，毕竟这个东西被封已经说了很久了。

这的确棒棒哒。

既然如此，还是请赛博佛祖出手吧，自建镜像。

1.fork 代理仓库：https://github.com/obaby/CF-Workers-docker.io/

2.登录 cf，在 worker 和 pages 中添加 pages

选择连接到 git，后续是 gitbub的授权流程，按照提示操作即可。

2.选择 fork 的项目点击开始设置

3.一切设置完成后开始部署

4.部署完成之后就到了下面的页面，可以添加自定义域，主要是 cf 自带的域很可能****

5.自定义域建议直接托管到 cf，这样只需要添加个域名就 ok 了。完全自动。

6.修改 docker 默认源（针对 ubunt，其他系统路径我也不知道，哈哈哈）如果文件不存在直接创建即可：

vim /etc/docker/daemon.json

文件内容：

{
  "registry-mirrors": ["https://docker.obaby.blog"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

将https://docker.obaby.blog 替换为你的源，如果不想换，那就先用我的吧。

重启 docker 服务：

systemctl restart docker

7.再次通过 docker pull 镜像就一切都 ok 了。

整体感觉 cf 的代理速度还是蛮不错的，非常 nice，嘻嘻。

ps:

刚发现上面的 docker 启动失败了，直接运行：

root@opensips:~# docker run rabbitmq

会提示下面的错误：

Failed to create thread: Operation not permitted (1)
Aborted

直接加参数运行吧：

docker run --privileged rabbitmq

参考链接：https://www.zhaodede.com/news/content/23.html