从 1Panel 到 Docker AI 服务编排：我的云服务器落地实践

项目概述#

---

起因#

手里有一台云服务器，之前一直只拿来跑点临时脚本。这次想认真把它用起来：把个人网站搬上去，再顺手把最近在用的一些 AI 服务也部署好，省得每次都依赖别人的转发地址。

目标说简单也简单——一台机器，稳定跑着网站和几个容器服务，自己以后维护起来不费劲。说难也难，因为”能跑”和”好维护”之间差着不少功夫。

---

服务器初始化#

拿到机器先做基础配置，这部分没什么花哨的，就是按部就班：

• 配好 SSH 密钥登录，禁用密码登录
• 更新系统软件包
• 规划目录结构：网站放哪、容器的数据卷放哪，一开始就分清楚
• 把要用的端口提前想好，避免后面部署时撞车

这一步里我做得比较克制的一件事是：没有一上来就装一堆东西。先把目录和端口规划好，再一个个服务往上加。之前吃过”装的时候很爽、迁移的时候想哭”的亏，这次学乖了。

---

为什么用 1Panel#

说实话，纯命令行我也能用，但一台机器上要同时管网站、容器、证书，全靠在终端里敲命令，时间久了很容易记不清哪个服务跑在哪、状态怎么样。

1Panel 就是解决这个问题的。它给我一个统一的面板，能看到所有容器在不在跑、网站证书什么时候到期、磁盘还剩多少。命令行负责干活，面板负责看状态，两个配合着用。

它不是替代命令行，而是让我在三个月后回来维护时，不用先花半小时回忆”当初我到底是怎么配的”。

---

网站部署#

这个网站（你现在看到的这个）就是部署在这台机器上的。流程是标准的一套：

1. 本地 astro build 出静态文件
2. 传到服务器
3. 1Panel 里建站点，配反向代理
4. 申请 HTTPS 证书，开启自动续期
5. 域名解析指过来，验证访问

中间卡过一次：反向代理配好了但页面打不开，排查了半天发现是安全组没放行 443 端口。云服务器的安全组和本机防火墙是两层东西，这个坑值得记一笔。

---

Docker 部署 OpenClaw 和 MetaAPI#

网站上线之后，继续用 Docker 把两个 AI 服务也跑起来。

OpenClaw 是一个独立的服务，用 Docker 部署主要是图省事——镜像拉下来，compose 文件写好端口映射和数据卷，docker compose up -d 就完事。比在宿主机上手动配环境干净得多，哪天想升级或者回滚，换个镜像版本就行。

MetaAPI 是这次部署里我觉得最有价值的一个。它的作用是把多个大模型站点的 API 统一收口：下游调用方只需要对着一个地址发请求，由 MetaAPI 转发到不同的上游模型。

为什么要多这一层？因为之前我直接对接过好几个模型站点，每个的鉴权方式、接口格式都不太一样，换一个就要改一遍调用代码。加了 MetaAPI 之后，切换模型源只需要在面板里改配置，调用方完全无感。

部署时主要注意这几点：

• 容器端口只映射到内网，不直接暴露公网
• 数据卷挂载好，配置和日志持久化
• 统一走反向代理对外，和网站共用一套入口

---

整体架构#

把这套东西画出来大概是这样：

flowchart TD
  U[用户访问] --> D[域名 / 统一入口]
  D --> R[反向代理 / HTTPS]
  R --> W[个人网站 Astro]
  R --> O[OpenClaw]
  R --> M[MetaAPI]
  M --> A1[模型 API A]
  M --> A2[模型 API B]
  M --> A3[模型 API C]

  P[1Panel] -.运维管理.-> R
  P -.运维管理.-> W
  P -.运维管理.-> O
  P -.运维管理.-> M

  V[Docker] -.容器承载.-> O
  V -.容器承载.-> M

一句话概括：所有对外访问收敛到一个入口，反向代理负责分发，Docker 负责隔离，1Panel 负责让我看得清全局。

---

踩坑与反思#

这次部署整体顺利，但有几个地方值得记下来：

安全组不等于防火墙。 这是上面提到的那个坑。本机 iptables 放行了，云平台安全组没放行，照样不通。以后排查网络问题，这两层都要查。

证书续期要趁早验证。 HTTPS 证书申请下来不代表万事大吉，自动续期任务有没有跑通，最好当场手动触发一次确认，别等三个月后网站挂了才发现。

compose 文件要留档。 第一版 compose 文件我随手写完就跑起来了，后来想加个环境变量才发现当时没保存最终版。现在所有 compose 文件都统一放在一个目录里，和代码一样对待。

---

后续打算#

这套环境目前够用，但还有几件事想做：

• 加监控和告警，服务挂了能第一时间知道
• 定期备份，至少把网站数据和 compose 配置备份到异地
• 用 CI/CD 简化网站发布流程，现在还是手动 build + 传文件，有点原始

---

总结#

这次把服务器从”吃灰”状态变成了真正在干活的基础设施：网站稳定跑着，AI 服务也接了进来，统一入口、容器隔离、面板运维，该有的都有了。

它不复杂，但完整。对我这种还在积累工程经验的人来说，把一台机器从头到尾管明白，比学十个新框架更实在。