部署 on Cloudside

在阿里云 ECS 上最小化部署 Marinara Engine：不在服务器上跑本地模型

Mon, 29 Jun 2026 17:15:00 +0800

Marinara Engine 的官方介绍里把它称为一个本地 AI 聊天、角色扮演和游戏引擎。听起来很容易让人以为：既然是“本地”，是不是服务器上还要准备 GPU、下载模型、跑 llama.cpp 或者 embedding 服务？

如果只是想把 Marinara 当成一个 Web 应用来用，答案是不需要。我的阿里云 ECS 现在跑的就是这种最小化部署：Docker 里只跑 Marinara Engine 本体，模型能力走外部 API，容器端口只绑定到 127.0.0.1，再由反向代理对外提供访问。

本文记录的是这个部署方式。版本核对时间是 2026-06-29：官方最新稳定版是 v2.0.6，我当前服务器上实际运行的是 ghcr.nju.edu.cn/pasta-devs/marinara-engine:2.0.5-lite。新部署可以优先用最新稳定版的 *-lite tag；如果你想完全复刻本文环境，就固定到 2.0.5-lite。

先理解这个“最小化”是什么意思

最小化不是功能阉割到不能用，而是把不适合小云服务器承担的部分拿掉。

Marinara Engine 官方提供 lite 镜像。根据官方容器安装文档，lite 镜像去掉了三类较重的离线能力：

本地 sidecar 模型，也就是容器内直接跑本地 LLM 的那部分。
本地 embedding 模型。
依赖本地 embedding 的语义记忆检索。

保留下来的能力仍然包括聊天、角色、游戏模式、agent、lorebook、角色卡、远程 LLM API 连接等。也就是说，只要你本来就打算用 OpenAI、OpenRouter、Gemini、Anthropic 或者其他远程 OpenAI-compatible API，这种部署方式就够了。

我这里的结构是：

浏览器
 -> 阿里云安全组开放 80/443
 -> Pingap / Nginx / Caddy 这类反向代理
 -> 127.0.0.1:7860
 -> Docker 容器内的 Marinara Engine
 -> 远程 LLM / 图片 / TTS API

看到这里，问题就变成了：服务器上到底需要跑什么？答案很少：Docker、一个 compose 文件、一个 .env 文件、一个反向代理入口。

用 Pingap 部署反向代理，以及从 Pingora 迁移时容易踩的坑

Sun, 17 May 2026 16:20:00 +0800

如果你已经看过 Pingora 的最小反向代理示例，很容易产生一个后续问题：生产环境是不是也要自己继续写配置解析、证书加载、日志、热更新和管理界面？通常不需要。Pingap 就是基于 Pingora 做好的反向代理应用，它更接近一个可以直接部署的 Nginx 替代方案。

这篇文章只讲 Pingap：怎么安装，怎么写一个最小反代配置，怎么加 HTTPS，怎么用 Docker 或 systemd 部署，以及从裸 Pingora 或 Nginx 迁移过来时有哪些容易忽略的坑。

本文示例版本核对时间：2026-05-17。示例固定使用 Pingap v0.13.4。实际部署前建议再看一次官方 GitHub Releases 和文档，因为 Pingap 还在快速变化。

Pingap 和 Pingora 的关系

Pingora 是框架，你通过 Rust 代码实现代理逻辑。Pingap 是应用，它把常见反向代理能力包装成 TOML 配置和 Web 管理界面。

一个最小 Pingap 配置大概长这样：

[upstreams.app]
addrs = ["127.0.0.1:3000"]

[locations.app]
host = "app.example.com"
path = "/"
upstream = "app"
enable_reverse_proxy_headers = true

[servers.http]
addr = "0.0.0.0:6188"
locations = ["app"]

这段配置和一个最小 Pingora 代理做的是同一件事：监听 6188，把匹配 app.example.com 的请求转发到 127.0.0.1:3000。差别在于，你不用实现 ProxyHttp，也不用自己处理常见代理应用需要的周边能力。

用 Pingora 写一个最小反向代理，并把它部署起来

Sun, 17 May 2026 16:00:00 +0800

Cloudflare 开源 Pingora 之后，很多人会问：它能不能替代 Nginx？如果问题只是“能不能把请求转发到后端服务”，答案是能，而且几十行 Rust 就够了。但 Pingora 不是一个读取 nginx.conf 的服务器，它更像一套用来写代理、网关和网络服务的 Rust 框架。

这篇只做一件事：用 Pingora 写一个最小反向代理，让 http://127.0.0.1:6188/ 转发到本机的 127.0.0.1:3000，然后把这个二进制按服务方式部署起来。

本文示例版本核对时间：2026-05-17。示例使用 pingora = "0.8"。

先看等价的 Nginx 配置

如果用 Nginx，最小反代大概长这样：

server {
 listen 6188;

 location / {
 proxy_pass http://127.0.0.1:3000;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto http;
 }
}

Pingora 的思路不一样。你不是写配置块，而是实现 ProxyHttp trait：请求进来以后，代码决定它要转发到哪里，转发前要改哪些请求头，最后日志怎么记。

创建项目

cargo new mini-pingora-proxy
cd mini-pingora-proxy

Cargo.toml：

[package]
name = "mini-pingora-proxy"
version = "0.1.0"
edition = "2021"

[dependencies]
async-trait = "0.1"
env_logger = "0.11"
log = "0.4"
pingora = { version = "0.8", features = ["proxy"] }

这里用的是 pingora 聚合 crate，并启用 proxy feature。Pingora 没有默认打开所有能力；如果后面要做负载均衡，需要再启用 lb；如果要监听 HTTPS 或连接 HTTPS upstream，还要选择对应的 TLS feature，比如 openssl、boringssl、s2n 或实验性的 rustls。