解决better-sqlite3在Docker容器中运行时的libnode.so缺失问题

在使用better-sqlite3这个Node.js的SQLite3数据库驱动时，开发者经常会在Docker环境中遇到一个典型的依赖问题。当尝试在容器中运行应用时，可能会出现"libnode.so.72: cannot open shared object file"这样的错误。这个问题看似复杂，但其实有很简单的解决方案。

问题现象

当开发者使用Dockerfile构建Node.js应用镜像时，特别是那些依赖better-sqlite3的应用，容器启动后会立即退出，并报错提示找不到libnode.so.72共享库文件。错误信息表明Node.js无法加载better-sqlite3所需的本地绑定模块。

问题根源

这个问题的根本原因在于better-sqlite3是一个需要编译的本地模块(Node.js Addon)。当在主机上开发时，npm install会自动编译出与主机Node.js版本匹配的二进制文件。但如果直接将node_modules目录复制到Docker容器中，这些预编译的二进制文件可能与容器内的Node.js版本不兼容。

解决方案

正确的做法是确保在Docker容器内重新编译所有本地模块。这可以通过以下步骤实现：

1. 创建一个.dockerignore文件，排除node_modules目录
2. 在Dockerfile中确保npm install在容器内执行

具体实现如下：

.dockerignore文件内容：

node_modules

Dockerfile示例：

FROM node:18  # 使用稳定的Node.js版本

WORKDIR /app
COPY package*.json ./
RUN npm install --production

COPY . .

CMD ["node", "index.js"]

关键点说明

1. 使用.dockerignore排除node_modules可以防止主机上的预编译模块被复制到容器中
2. 在容器内执行npm install会基于容器内的Node.js版本重新编译所有本地模块
3. 推荐使用稳定的Node.js版本(如18.x)而非最新版本，以减少兼容性问题

额外建议

对于生产环境部署，还可以考虑以下优化：

1. 使用多阶段构建减少最终镜像大小
2. 添加适当的健康检查
3. 考虑使用--build-arg来参数化Node.js版本

通过遵循这些最佳实践，可以确保better-sqlite3在Docker环境中可靠运行，避免因版本不匹配导致的运行时错误。