Docker容器SQLite数据库拉新镜像后无法持久化的解决方法

可能的原因及对应解决方法 #

1. 手动更新容器时操作不当 #

如果手动拉取新镜像后，直接用docker run启动容器却没指定挂载参数，会导致宿主机的app.db未被挂载，新容器会使用镜像内置的默认数据库，自然看不到之前的数据。

解决方式：
拉取新镜像后，必须通过docker-compose重启容器，确保挂载配置生效：

docker-compose pull myservice
docker-compose up -d myservice

2. Watchtower未正确识别服务挂载配置 #

虽然Watchtower默认会继承原容器的挂载配置，但如果服务未明确启用Watchtower监控，可能出现识别异常。

解决方式：
给myservice添加明确的启用标签，修改后的配置如下：

services:
  myservice:
    image: myimage
    container_name: thecontainername
    volumes:
      - ./app.db:/prisma/app.db
    restart: always
    labels:
      - "com.centurylinklabs.watchtower.enable=true" # 明确让Watchtower监控该服务
  watchtower:
    image: containrrr/watchtower
    container_name: watchtower
    labels:
      - "com.centurylinklabs.watchtower.enable=false"
    environment:
      - REPO_USER=${DOCKERHUB_USER}
      - REPO_PASS=${DOCKERHUB_PASS}
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    command: --cleanup --interval 120 --debug
    restart: always

3. 权限问题导致容器无法读写宿主机数据库文件 #

如果宿主机的app.db权限设置不合理，新容器启动后进程无法读写该文件，会自动在容器内创建一个空的app.db，造成数据丢失的假象。

解决方式：
检查并调整宿主机app.db的权限，确保容器进程能正常读写：

# 查看当前文件权限
ls -l ./app.db
# 修改权限（假设容器内进程使用1000用户，可根据实际镜像调整UID）
chmod 664 ./app.db
chown 1000:1000 ./app.db

4. 改用Docker命名卷替代绑定挂载 #

直接挂载宿主机单个文件容易出现路径、权限等兼容性问题，改用Docker命名卷能更稳定地持久化数据。

解决方式：
修改docker-compose.yml配置，使用命名卷：

services:
  myservice:
    image: myimage
    container_name: thecontainername
    volumes:
      - db-volume:/prisma # 挂载目录到命名卷，数据库文件将保存在卷内
    restart: always
    # 其他配置保持不变
  watchtower:
    # 原watchtower配置不变
volumes:
  db-volume: # 定义命名卷，Docker会自动管理存储路径

如果已有数据需要迁移，可通过临时容器将宿主机的app.db复制到命名卷中：

docker run --rm -v ./app.db:/host/app.db -v db-volume:/container/prisma busybox cp /host/app.db /container/prisma/app.db

内容的提问来源于stack exchange，提问作者ill