最近了解到一个比较新的 Lade 云开发平台，Lade 是专为开发者设计的云端平台，可以帮助开发者在云端部署测试应用，并提供基础的免费应用额度，还有多处数据中心服务器可供选择，还默认直接支持 HTTPS 域名以方便连接访问容器应用。

Lade 开发平台默认支持以下编程语言：

• Go
• Node.js
• PHP
• Python
• Ruby

以及以下这些常用的数据库：

• MariaDB
• Memcached
• MongoDB
• MySQL
• PostgreSQL
• Redis

对于其它编程语言，Lade 还支持以 Dockerfile 形式运行测试应用容器。

首先可以在 Lade 官方网站注册账户，然后需要绑定并验证 GitHub 账号后才能创建部署容器应用。

Lade CLI 部署应用

Lade 网站目前没有提供任何容器应用的部署和管理的功能，容器应用的部署和管理都需要使用 Lade CLI 工具来完成。

这里以 Linux 系统为例进行简单的介绍，按照页面介绍来安装 Lade CLI：

~# curl -L https://github.com/lade-io/lade/releases/latest/download/lade-linux-amd64.tar.gz | tar xz
~# sudo mv lade /usr/local/bin

首先使用 CLI 登录 Lade 账户：

~# lade login
Enter your Lade credentials:
? Username or email: zohead
? Password: 
Logged in as zohead*

输入用户名和密码登录成功之后就可以进行创建部署容器应用了，这次我准备先部署一个 Miniflux 应用来试试效果。

Miniflux 是一个极简的 RSS 阅读器应用，基于 Go 语言开发，使用 Postgres 数据库保存数据，与其它 RSS 阅读器应用相比功能和界面都很简洁，不过关键还支持抓取 RSS 文章全文、全文检索等功能。

Lade 的收费方式可以参考官网 Pricing 页面，并有基础的免费额度，当然免费的额度也是随时有可能取消的：

• 应用：
  • 128 MB 内存；
  • 1 CPU；
• 数据库：
  • 128 MB 内存；
  • 1 GB 存储空间；
• 磁盘：
  • 1 GB 磁盘。

备注：

2025-06-07 开始 Lade 平台正式取消了免费额度，目前最便宜的 128 MB 内存 / 1 CPU 的应用价格为每月 $1.25，大家自行酌情选择合适的容器收费配置计划。

应用容器

我们首先使用 lade apps create 命令创建新的应用容器，按照提示输入应用容器名称，并选择容器配置和区域即可完成创建，这里就选择免费配置计划和日本东京区域：

提示：

• 容器名称非常关键，后面很多命令都需要用到，请谨慎输入；
• 请根据实际应用程序对内存和 CPU 的要求，选择合适的应用配置计划；
• 免费额度随时有可能取消，如果使用免费配置计划，请注意备份应用数据。

~# lade apps create
? App Name: miniflux
? Plan: 128mb
? Region: Tokyo

创建成功之后，可以运行 lade apps list 命令查看容器列表：

~# lade apps list
NAME        PLAN     CREATED           STATUS
miniflux    128mb    43 minutes ago    running

另外使用 lade apps show 命令可以查看具体某个应用容器的详细信息和状态，下方输出数据最后的 Web URL 就是 Lade 云开发平台为容器应用自动分配的 HTTPS 访问域名：

~# lade apps show miniflux
Owner:        XXX@XXX.com
Processes:    web: 0/1
Plan:         128mb
Region:       Tokyo
Status:       running
Web URL:      miniflux-zohead.ladeapp.com

接着我们就需要在容器上部署实际的应用了，对于 Miniflux 可以从 GitHub 检出最新 v2 版本的代码：

~# mkdir miniflux
~# cd miniflux
~/miniflux# git clone --depth 1 https://github.com/miniflux/v2.git

然后使用 lade deploy 命令进行容器应用部署：

~# lade deploy --app miniflux
time="2025-04-24T20:28:59+08:00" level=error msg="Can't add file internal/reader/readability/testdata to tar: archive/tar: unknown file mode ?rw-rw-rw-"
Sending build context to Docker daemon  4.563MB
Step 1/11 : FROM golang:1.23.0
1.23.0: Pulling from library/golang
Successfully built e7ae4ac3677b
Successfully tagged registry.lade.io/zohead/miniflux:build-1njzwaheu4
Pushing miniflux build to registry
Build finished use "lade logs -a miniflux -f" to view app logs

容器应用部署成功之后，我们可以使用 lade ps 命令确认容器内的进程是否运行正常，可以看到 Lade 部署生成的 miniflux.app 应用程序进程正在运行：

~# lade ps -a miniflux
NAME     PLAN     STARTED         COMMAND
web.1    128mb    14 hours ago    miniflux.app

我们还可以使用 lade run 命令实现在应用容器中运行需要的命令，这里就直接运行一个 Bash Shell，运行自定义命令也需要指定一个配置计划，这里还是使用免费配置计划：

~# lade run "bash" -a miniflux -p 128mb

容器内的 Bash Shell 启动成功之后，我们可以查看并确认 Miniflux 应用信息，对于 Miniflux 这种 Go 语言应用，Lade 默认部署生成的应用程序在 /go/bin 目录下：

~$ ls -l /go/bin/miniflux.app
-rwxr-xr-x 1 web web 19411204 Apr 24 12:30 /go/bin/miniflux.app
~$ miniflux.app -i
Version: dev
Commit: HEAD
Build Date: undefined
Go Version: go1.23.0
Compiler: gc
Arch: amd64
OS: linux

另外根据上面部署命令输出中的提示信息，使用 lade logs -a miniflux -f 命令可以跟踪显示容器应用的运行日志，实际上就是显示容器内应用程序的标准输出和错误输出：

~# lade logs -a miniflux -f
web.1 | level=INFO msg="The default value for DATABASE_URL is used"
web.1 | dial tcp [::1]:5432: connect: connection refused

由于还没有为 Miniflux 应用配置数据库，会出现类似上面的报错信息。

数据库扩展

接着我们需要使用 lade addons create 命令为容器应用配置数据库扩展，下面的 lade addons create postgres 命令即为创建 PostgreSQL 数据库，我仍然使用免费配置计划，并选择和应用相同位置的日本东京区域，以加快数据库访问速度：

~# lade addons create postgres
? Addon Name: miniflux-postgres
? Plan: 128mb
? Region: Tokyo
? Version: 17
? Public: No

简单说明一下命令参数：

• Addon Name 为数据库扩展名称，后续扩展管理相关命令也会用到；
• Version 为数据库版本，lade 命令会列出支持的数据库版本；
• Public 表示数据库是否允许外部公共访问，我只需要 PostgreSQL 数据库被 Miniflux 应用访问，并不需要公共访问，这里就选 No 了。

创建成功之后，就可以使用 lade addons show 命令查看数据库扩展的详细信息和状态了：

~# lade addons show miniflux-postgres
Owner:        XXX@XXX.com
Service:      PostgreSQL
Plan:         128mb
Region:       Tokyo
Version:      17
Public:       No
Status:       running
Addon URI:    postgresql://USERNAME:PASSWORD@tyo-sw1.lade.io:30066/XXXX?sslmode=require

最后的 Addon URI 就是最关键的数据库连接地址，我们需要为应用容器配置数据库连接地址，地址中包含数据库服务器地址、用户名、密码、数据库名称等数据。

确认数据库运行正常之后，就可以将 PostgreSQL 数据库扩展附加到 Miniflux 应用容器：

~# lade addons attach miniflux-postgres --app miniflux
? Env Name: POSTGRES_URL

然后使用 lade env list 命令检查应用容器的环境变量：

~# lade env list -a miniflux
DATABASE_URL=postgresql://USERNAME:PASSWORD@tyo-sw1.lade.io:30066/XXXX?sslmode=require
POSTGRES_URL=postgresql://USERNAME:PASSWORD@tyo-sw1.lade.io:30066/XXXX?sslmode=require

可以看到数据库扩展附加之后，会自动为应用容器配置数据库环境变量，包含通用的 DATABASE_URL 和 PostgreSQL 专用的 POSTGRES_URL 环境变量。

Miniflux 应用容器问题

我原以为按照上面的步骤为 Miniflux 应用容器配置好 PostgreSQL 数据库扩展之后，Miniflux 应用就可以正常运行了，而实际上容器仍然有报错：

~# lade logs -a miniflux -f
web.1 | the database schema is not up to date: current=v0 expected=v108

参考 Miniflux 项目 You must run the SQL migrations, the database schema is not up to date: current=v0 expected=v62 Issue 的说明，对于类似 Docker 容器的环境 Miniflux 需要开启 RUN_MIGRATIONS 环境变量。

我们可以使用 lade env set 命令为容器配置或修改环境变量：

~# lade env set RUN_MIGRATIONS=1 -a miniflux

稍等一会容器应用自动重启后，就可以看到 Miniflux 应用已经正常运行了：

~# lade logs -a miniflux -f
web.1 | level=INFO msg="Running database migrations" current_version=0 latest_version=108 driver=postgresql
web.1 | level=INFO msg="Starting HTTP server" listen_address=:3000

现在我们其实就已经可以通过 Lade 云平台为容器应用分配的域名访问 Miniflux Web 管理界面了，当然还是需要用 HTTPS 访问的：

不过由于我们还没有为 Miniflux 配置管理员账户，还不能直接登录。

这个时候就需要借助 lade run 命令在应用容器中运行命令创建管理员账户了，下面输出中的 miniflux.app 程序是在容器内运行的：

~$ miniflux.app -create-admin
Enter Username: admin
Enter Password:
level=INFO msg="Created new admin user" username=admin user_id=1

管理员账户创建成功之后，我们就可以通过容器域名访问 Miniflux Web 管理界面进行 RSS 源的配置和订阅管理了。

当然我们也可以开始就通过指定环境变量让 Miniflux 容器自动创建管理员账户，与上面的 RUN_MIGRATIONS 环境变量配合起来就类似：

~# lade env set RUN_MIGRATIONS=1 CREATE_ADMIN=1 ADMIN_USERNAME=admin ADMIN_PASSWORD=password -a miniflux

这样通过环境变量指定管理员账户名称和密码也很方便。

总结

本文简单介绍了如何使用 Lade 云开发平台的 lade CLI 命令部署配置容器应用，我部署的 Miniflux RSS 阅读器容器应用也运行了一段时间，Lade 云平台还是比较稳定的，只是没有国内的数据中心，访问速度倒是一般。

最后 Lade 云平台的开发者已经确认，目前提供的免费额度仅供开发人员测试使用，免费额度后续随时有可能取消，希望大家不要滥用，如果觉得 Lade 好用也可以考虑付费使用哦，祝大家玩的开心。

(mod_webdav.c.2182) sql-set failed: SQL logic error or missing database
(mod_webdav.c.2182) sql-set failed: not an error
(mod_webdav.c.2182) sql-set failed: not an error
(mod_webdav.c.2182) sql-set failed: not an error
(mod_webdav.c.2182) sql-set failed: not an error
(mod_webdav.c.2182) sql-set failed: not an error
(mod_webdav.c.2182) sql-set failed: not an error
(mod_webdav.c.2182) sql-set failed: not an error
(mod_webdav.c.2511) remove lock: bind or column index out of range
(mod_webdav.c.2511) remove lock: bind or column index out of range
(mod_webdav.c.2511) remove lock: bind or column index out of range

我们先看看 mod_webdav.c 中对应的 SQLite 处理代码：

sqlite3_stmt *stmt;

stmt = (0 == xmlStrcmp(cmd->name, BAD_CAST "remove")) ?
	p->conf.stmt_delete_prop : p->conf.stmt_update_prop;

for (props = cmd->children; props; props = props->next) {
	if (0 == xmlStrcmp(props->name, BAD_CAST "prop")) {
		xmlNode *prop;
		int r;

		prop = props->children;

		sqlite3_reset(stmt);

		/* bind the values to the insert */

		sqlite3_bind_text(stmt, 1,
				  con->uri.path->ptr,
				  con->uri.path->used - 1,
				  SQLITE_TRANSIENT);
		sqlite3_bind_text(stmt, 2,
				  (char *)prop->name,
				  strlen((char *)prop->name),
				  SQLITE_TRANSIENT);
		if (prop->ns) {
			sqlite3_bind_text(stmt, 3,
					  (char *)prop->ns->href,
					  strlen((char *)prop->ns->href),
					  SQLITE_TRANSIENT);
		} else {
			sqlite3_bind_text(stmt, 3,
					  "",
					  0,
					  SQLITE_TRANSIENT);
		}
		if (stmt == p->conf.stmt_update_prop) {
			sqlite3_bind_text(stmt, 4,
				  (char *)xmlNodeGetContent(prop),
				  strlen((char *)xmlNodeGetContent(prop)),
				  SQLITE_TRANSIENT);
		}

		if (SQLITE_DONE != (r = sqlite3_step(stmt))) {
			log_error_write(srv, __FILE__, __LINE__, "ss",
					"sql-set failed:", sqlite3_errmsg(p->conf.sql));
		}
	}
}

这里用到了 SQLite 的绑定数据 sqlite3_bind_text 和 sqlite3_step 执行函数。

同时我们可以看看 mod_webdav.c 中打开 SQLite 数据库以及 SQLite 变量绑定方式的 SQL 处理代码：

const char *next_stmt;
char *err;

if (SQLITE_OK != sqlite3_open(s->sqlite_db_name->ptr, &(s->sql))) {
	log_error_write(srv, __FILE__, __LINE__, "sbs", "sqlite3_open failed for",
			s->sqlite_db_name,
			sqlite3_errmsg(s->sql));
	return HANDLER_ERROR;
}

if (SQLITE_OK != sqlite3_exec(s->sql,
		"CREATE TABLE properties ("
		"  resource TEXT NOT NULL,"
		"  prop TEXT NOT NULL,"
		"  ns TEXT NOT NULL,"
		"  value TEXT NOT NULL,"
		"  PRIMARY KEY(resource, prop, ns))",
		NULL, NULL, &err)) {

	if (0 != strcmp(err, "table properties already exists")) {
		log_error_write(srv, __FILE__, __LINE__, "ss", "can't open transaction:", err);
		sqlite3_free(err);

		return HANDLER_ERROR;
	}
	sqlite3_free(err);
}

...

if (SQLITE_OK != sqlite3_prepare(s->sql,
	CONST_STR_LEN("REPLACE INTO properties (resource, prop, ns, value) VALUES (?, ?, ?, ?)"),
	&(s->stmt_update_prop), &next_stmt)) {
	/* prepare failed */

	log_error_write(srv, __FILE__, __LINE__, "ss", "sqlite3_prepare failed:", sqlite3_errmsg(s->sql));
	return HANDLER_ERROR;
}

...

/* LOCKS */

if (SQLITE_OK != sqlite3_exec(s->sql,
		"CREATE TABLE locks ("
		"  locktoken TEXT NOT NULL,"
		"  resource TEXT NOT NULL,"
		"  lockscope TEXT NOT NULL,"
		"  locktype TEXT NOT NULL,"
		"  owner TEXT NOT NULL,"
		"  depth INT NOT NULL,"
		"  timeout TIMESTAMP NOT NULL,"
		"  PRIMARY KEY(locktoken))",
		NULL, NULL, &err)) {

	if (0 != strcmp(err, "table locks already exists")) {
		log_error_write(srv, __FILE__, __LINE__, "ss", "can't open transaction:", err);
		sqlite3_free(err);

		return HANDLER_ERROR;
	}
	sqlite3_free(err);
}

if (SQLITE_OK != sqlite3_prepare(s->sql,
	CONST_STR_LEN("INSERT INTO locks (locktoken, resource, lockscope, locktype, owner, depth, timeout) VALUES (?,?,?,?,?,?, CURRENT_TIME + 600)"),
	&(s->stmt_create_lock), &next_stmt)) {
	/* prepare failed */
	log_error_write(srv, __FILE__, __LINE__, "ss", "sqlite3_prepare failed", sqlite3_errmsg(s->sql));

	return HANDLER_ERROR;
}

...

从上面的代码可以看出，lighttpd 打开 SQLite 数据库之后先创建 properties 表格，然后使用 sqlite3_prepare 函数进行 properties 表格的 SQL 语句预处理，接着创建 locks 表格，同时也使用 sqlite3_prepare 对 locks 表格进行预处理。

使用 sqlite3_prepare 函数而不直接使用 sqlite3_exec 函数的好处是可以直接将 SQL 语句转换为 SQLite 内部的字节码，后面使用时不需要再直接使用冗长的 SQL 语句，直接绑定数据就可以查询或者更新数据了。这里就比较奇怪了，stmt_update_prop 的 SQL 语句看起来也没有什么问题。首先把疑点放在 sqlite3_bind_text 上，怀疑是不是数据中有没有什么特殊字符导致 sqlite3_step 函数执行出错了，但我把 sqlite3_bind_text 的内容全部改成普通字符串还是一样的报错。

搜寻一番之后终于在 sqlite3.h 头文件中发现了端倪：

** The sqlite3_prepare_v2() and sqlite3_prepare16_v2() interfaces are
** recommended for all new programs. The two older interfaces are retained
** for backwards compatibility, but their use is discouraged.、
**
** In the "v2" interfaces, the prepared statement
** that is returned (the [sqlite3_stmt] object) contains a copy of the
** original SQL text. This causes the [sqlite3_step()] interface to
** behave differently in three ways:
**
** If the database schema changes, instead of returning [SQLITE_SCHEMA] as it
** always used to do, [sqlite3_step()] will automatically recompile the SQL
** statement and try to run it again. As many as [SQLITE_MAX_SCHEMA_RETRY]
** retries will occur before sqlite3_step() gives up and returns an error.
**
** When an error occurs, [sqlite3_step()] will return one of the detailed
** [error codes] or [extended error codes]. The legacy behavior was that
** [sqlite3_step()] would only return a generic [SQLITE_ERROR] result code
** and the application would have to make a second call to [sqlite3_reset()]
** in order to find the underlying cause of the problem. With the "v2" prepare
** interfaces, the underlying reason for the error is returned immediately.

sqlite3.h 中建议使用新的 sqlite3_prepare_v2 函数替代老的 sqlite3_prepare 函数，而且中间的注释中还提到使用 sqlite3_prepare 函数之后如果数据库的结构发生了变动，sqlite3_step 函数将会出错。这时我们看看 mod_webdav.c 中初始化数据库的代码可以发现 sqlite3_prepare 函数是在两个 sqlite3_exec 函数创建数据库之间运行的，这样 sqlite3_prepare 生成的字节码就不是正确的，才导致后续的 SQL 更新操作失败。

知道原因之后修改也比较简单了，我们可以修改 mod_webdav.c 中的数据库初始化代码，将两个 sqlite3_exec 创建数据库的操作放在最前面，将所有 sqlite3_prepare 替换为 sqlite3_prepare_v2 函数放在创建数据库之后，这样就不会出现 SQLite 数据库错误问题了。

本文为个人使用分析的结果，其中有任何问题欢迎提出指正，另外 lighttpd 最新版本库代码中这个问题似乎仍然没有修正。