Glance v0.8.7 Docker Compose 部署指南

目标：用 Docker Compose 在单台 Ubuntu 22.04 服务器上完成 Glance v0.8.7 的 0→1 部署，覆盖镜像标签选型、独立网络编排、glance.yml 配置挂载、内置用户名/口令认证的全链路验证（登录成功/失败/Cookie 会话）、docker-containers 组件接入与配置热重载等日常运维操作。本文全部命令与回显已在 Docker Engine 29.9.2（Compose 插件 v5.6.1）环境实测通过；Glance 的产品定位与选型分析见《Glance v0.8.7 介绍与选型指南》。

一、环境信息

操作系统：Ubuntu 22.04（x86_64）
Docker Engine：29.9.2，Docker Compose 插件 v5.6.1
Glance 版本：v0.8.7（2026-10-15 发布，官方镜像 glanceapp/glance，标签清单见第二章，实查日期 2026-10-25）
镜像体积：35MB（docker images 实测），单进程监听 8080 端口，无内置健康检查定义
端口规划：宿主端口 8133 → 应用端口 8080。生产环境可直接用 8080:8080 或由反向代理占用 80/443
编排目录：/opt/glance/（含 docker-compose.yml、.env 与 config/ 配置子目录）
独立网络：glance-net（bridge，网段 10.89.61.0/24）

二、镜像选型说明

Glance 官方只在 Docker Hub 的 glanceapp/glance 仓库发布镜像，选型要点集中在标签策略与应用内置约定两点。以下标签清单于 2026-10-25 通过 Docker Hub Registry API（/v2/repositories/glanceapp/glance/tags）实查：

标签	更新日期	含义	适用场景
`v0.8.7`	2026-10-15	精确版本标签，与 GitHub Release 一一对应	生产推荐，升级可控、回显可复现
`latest`	2026-10-15	滚动最新稳定版	想自动跟进新版本（行为可能变化）
`v0.8.7-amd64` / `v0.8.7-arm64` / `v0.8.7-armv7`	2026-10-15	按架构的精确标签	多架构集群中锁定单架构产物
`v0.8.6` / `v0.8.5` / …	2026-09-03 / 2026-05-30	历史版本标签	回滚到上一个稳定版

关键差异与选型建议：v0.8.7 与 latest 当前指向同一构建，但 Glance 仍处 0.x 版本线，小版本间偶有配置项废弃与行为变更（如 v0.8.7 起 Reddit 数据源要求配置应用认证才能使用 search 属性），生产环境锁定精确版本标签，升级节奏自己把控；latest 只建议测试环境使用。镜像为多架构清单（amd64/arm64/armv7），docker pull 会按宿主架构自动匹配。

镜像内置约定（docker inspect 实测）：

入口命令：/app/glance --config /app/config/glance.yml——配置文件路径硬编码为 /app/config/glance.yml，挂载时必须对准这个路径（见第八章）；
暴露端口：8080/tcp；
运行用户：root（官方镜像未做降权）；
健康检查：未内置 HEALTHCHECK 定义，docker compose ps 只能反映进程存活，不能反映应用可服务状态，需要健康检查时自行用 curl 探测登录页或加 healtcheck 配置。

三、前置条件

服务器已安装 Docker Engine 与 Compose 插件，验证：

docker version --format 'Engine {{.Server.Version}}'

实测输出：

Engine 29.9.2

docker compose version

实测输出：

Docker Compose version v5.6.1

编排目录已创建，配置子目录必须先建（这是本章实测踩过的第一个坑：挂载源目录不存在时，Docker 会自动创建一个空目录挂进去，Glance 读不到 glance.yml 直接报错进入重启循环，排障实录见第十一章常见问题 1）：

mkdir -p /opt/glance/config

对外访问入口确认：Glance 无内置 HTTPS，生产环境建议前置 Nginx/Caddy/Traefik 反向代理并启用 TLS；纯内网使用 服务器IP:8133 直连即可，无需域名。

四、部署步骤

本章按「创建独立网络 → 生成认证凭据 → 编写配置文件 → 编写编排文件 → 启动 → 验证」的顺序完成 0→1 部署。预期结果：服务启动后访问任意路径跳转登录页，用演示账号 admin 登录后看到仪表盘，docker-containers 组件列出服务器上启用了 glance.* 标签的容器。

4.1 创建独立网络

为整套栈创建独立 bridge 网络并显式指定网段，避免与其他业务网段冲突：

docker network create -d bridge --subnet 10.89.61.0/24 glance-net

实测输出：

8264751775e3c3e06ef30d061f6638692e80460d66e3da39c221c6a686d79ff1

💡 说明：显式 --subnet 便于后续把同网段内的服务统一接入。若网段与现有网络冲突，换一个空闲 /24 即可，同时同步修改编排文件。

4.2 生成认证凭据

Glance 的登录认证由三部分组成：会话签名密钥 secret-key、用户名清单与口令（明文 password 或 bcrypt 哈希 password-hash）。官方约定密钥必须用 secret:make 子命令生成、口令建议用 password:hash 生成 bcrypt 哈希，两者都可以用一次性运行的官方镜像完成，无需进入运行中的服务：

docker run --rm glanceapp/glance:v0.8.7 secret:make

实测输出：

OL3ETt4TxDNu+rEY6IICc368IQ2UtyxkYUpNmWIrSCzz3pmiuJDPTrRdky+0oq22XHF8T2d9LsyikeK4ZL5UUg==

docker run --rm glanceapp/glance:v0.8.7 password:hash q1w2e3r4

实测输出：

$2a$10$.OJnFEUkdJKUXCPIfDMQYeQaIndsZbnHaTI1I/UoaV5Wuawzx4E3W

💡 说明：password:hash 基于 bcrypt，每次运行都会生成带随机盐的不同哈希，这是正常现象——任意一次输出的哈希都能通过同一明文口令的校验。本文演示账号为 admin、口令 q1w2e3r4。

把密钥写入 .env 文件（属会话签名密钥，按敏感值规范从编排文件中剥离，通过 .env 注入而不是明文写进 docker-compose.yml）：

cd /opt/glance
echo "GLANCE_SECRET_KEY=OL3ETt4TxDNu+rEY6IICc368IQ2UtyxkYUpNmWIrSCzz3pmiuJDPTrRdky+0oq22XHF8T2d9LsyikeK4ZL5UUg==" >> .env

⚠️ .env 含密钥，权限应收紧：chmod 600 /opt/glance/.env，并确保该目录不进入任何版本库。

4.3 编写配置文件 glance.yml

在 /opt/glance/config/ 下创建 glance.yml。以下配置在官方预配置页基础上做了三处生产化调整：启用 auth 认证、把第 4.2 步生成的哈希落到 admin 用户、加入 monitor（服务自检）与 docker-containers（容器状态）两个运维向组件：

server:
  port: 8080

auth:
  secret-key: ${GLANCE_SECRET_KEY}
  users:
    admin:
      password-hash: $2a$10$.OJnFEUkdJKUXCPIfDMQYeQaIndsZbnHaTI1I/UoaV5Wuawzx4E3W

pages:
  - name: Home
    columns:
      - size: small
        widgets:
          - type: clock
            hour-format: 24h
          - type: calendar
            first-day-of-week: monday
          - type: monitor
            cache: 1m
            title: 服务监控
            sites:
              - title: Glance
                url: http://localhost:8080
                check-url: http://localhost:8080
      - size: full
        widgets:
          - type: group
            widgets:
              - type: hacker-news
              - type: lobsters
          - type: docker-containers
            hide-by-default: true
      - size: small
        widgets:
          - type: rss
            limit: 10
            collapse-after: 3
            cache: 12h
            feeds:
              - url: https://selfh.st/rss/
                title: selfh.st

逐项说明：

server.port: 8080：应用监听端口，与镜像暴露端口一致；对外改端口靠编排文件的 ports 映射，不需要动这里；
auth.secret-key: ${GLANCE_SECRET_KEY}：${VAR} 是 Glance 内置的环境变量注入语法，启动时从环境读取，变量不存在会拒绝启动——这正是把密钥隔离到 .env 的机制基础；
auth.users.admin.password-hash：第 4.2 步生成的 bcrypt 哈希，登录用户名 admin、口令 q1w2e3r4；
monitor.sites：对 http://localhost:8080 发 GET 探测（组件自身所在环境内回环），用于演示「服务在线状态」组件，生产环境把 url/check-url 换成你的其他业务服务地址；
docker-containers.hide-by-default: true：默认隐藏全部容器，只显示带 glance.hide: "false" 标签的容器（配合第 4.4 步的 labels），避免把服务器上无关容器全部暴露在面板上；
rss：示例数据源组件，cache: 12h 表示抓取结果缓存 12 小时。

4.4 编写编排文件

在 /opt/glance/ 下创建 docker-compose.yml：

name: glance-v0.8.7-stack

services:
  glance:
    image: glanceapp/glance:v0.8.7
    container_name: glance-v0.8.7-web
    restart: unless-stopped
    ports:
      - "8133:8080"
    volumes:
      - /opt/glance/config:/app/config
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      - GLANCE_SECRET_KEY=${GLANCE_SECRET_KEY}
    labels:
      glance.hide: "false"
      glance.name: Glance
      glance.icon: sh:glance
      glance.description: 自托管仪表盘
    networks:
      - glance-net

networks:
  glance-net:
    external: true

逐项说明：

name：Compose 项目名显式定为 glance-v0.8.7-stack，避免多套编排同目录名互相覆盖；
image：锁定 v0.8.7 精确标签（理由见第二章）；
ports：宿主 8133 → 应用 8080，生产可改 "8080:8080"；
volumes 第一项：配置目录持久化，/app/config 是镜像入口命令硬编码的配置路径；第二项：只读挂载 Docker socket，供 docker-containers 组件读取容器状态，不需要该组件可整行删掉（socket 等于宿主 root 级权限，安全敏感环境建议改用 docker-socket-proxy 代理接入）；
environment：把 .env 中的 GLANCE_SECRET_KEY 注入容器，供配置里的 ${GLANCE_SECRET_KEY} 读取；
labels：glance.* 标签系列是 docker-containers 组件的展示配置（名称/图标/描述），glance.hide: "false" 配合 hide-by-default: true 让本服务自己出现在面板上；
restart: unless-stopped：随守护进程自启，手动停止后不再自动拉起。

4.5 启动

cd /opt/glance
docker compose up -d

实测输出：

 Container glance-v0.8.7-web Creating 
 Container glance-v0.8.7-web Created 
 Container glance-v0.8.7-web Starting 
 Container glance-v0.8.7-web Started

启动后 3 秒内查看运行状态与启动日志：

docker compose ps

实测输出：

NAME                IMAGE                     COMMAND                  SERVICE   CREATED         STATUS         PORTS
glance-v0.8.7-web   glanceapp/glance:v0.8.7   "/app/glance --confi…"   glance    3 seconds ago   Up 3 seconds   0.0.0.0:8133->8080/tcp, [::]:8133->8080/tcp

docker compose logs glance

实测输出（节选）：

glance-v0.8.7-web  | 2026/10/25 03:20:02 Starting server on :8080 (base-url: "", assets-path: "")

💡 说明：Starting server on :8080 即启动成功标志。若配置有错，Glance 会启动即退出并打印 parsing config: ... 类错误，不会带病运行（见第十一章常见问题 1、3）。

4.6 验证：认证全链路实测

① 未登录访问被重定向到登录页：

curl -s -o /dev/null -w '%{http_code} -> %{redirect_url}\n' http://127.0.0.1:8133/

实测输出：

303 -> http://127.0.0.1:8133/login

② 正确口令登录成功（登录端点为 POST /api/authenticate，JSON 请求体，响应下发 session_token Cookie）：

curl -s -i -c /tmp/glance-cookies.txt -X POST http://127.0.0.1:8133/api/authenticate \
  -H 'Content-Type: application/json' \
  -d '{"username":"admin","password":"q1w2e3r4"}' | head -8

实测输出：

HTTP/1.1 200 OK
Set-Cookie: session_token=9fVN2YGyH5C5Wqofqf4/eD/cC85/ihSyYnvMELAyRdqi6u9qGIymTdRJX2XxKNiGTcFy9ZRbtA3yhL3uUqC7yZ3WZdw=; Path=/; Expires=Sun, 08 Nov 2026 03:21:06 GMT; HttpOnly; SameSite=Lax
Date: Sun, 25 Oct 2026 03:21:06 GMT
Content-Length: 0

③ 错误口令被拒绝：

curl -s -o /dev/null -w '%{http_code}\n' -X POST http://127.0.0.1:8133/api/authenticate \
  -H 'Content-Type: application/json' \
  -d '{"username":"admin","password":"wrong-pass"}'

实测输出：

同时服务端日志记录失败尝试（该日志也是防爆破封禁机制的依据，见第七章 proxied 说明）：

glance-v0.8.7-web  | 2026/10/25 03:21:0x Failed login attempt for user 'admin' from 10.89.61.1

④ 携带会话 Cookie 访问仪表盘：

curl -s -b /tmp/glance-cookies.txt -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8133/

实测输出：

⑤ 组件渲染验证（登录会话下取首页内容接口，确认 8 个组件全部渲染、docker-containers 按 hide-by-default 只列出带标签的 Glance 自身、monitor 自检 OK 且耗时 1ms）：

curl -s -b /tmp/glance-cookies.txt http://127.0.0.1:8133/api/pages/home/content/ \
  | grep -oE 'widget-type-[a-z-]+' | sort | uniq -c

实测输出：

      1 widget-type-calendar
      1 widget-type-clock
      1 widget-type-docker-containers
      1 widget-type-group
      1 widget-type-hacker-news
      1 widget-type-lobsters
      1 widget-type-monitor
      1 widget-type-rss

浏览器打开 http://服务器IP:8133，输入 admin / q1w2e3r4 登录即可看到完整仪表盘。

五、数据持久化说明

Glance 是零数据库设计，持久化面非常小，需要保管的只有一份配置：

数据	存放位置	持久化方式
全部配置（页面、组件、认证用户、主题预设）	`/app/config/glance.yml`（及 `$include` 引用的子文件）	bind mount 到宿主 `/opt/glance/config/`
数据源抓取缓存	内存	不持久化，重启/重载后重新抓取
待办清单（to-do 组件）数据	浏览器 localStorage	在用户浏览器侧，与服务端无关
登录会话	内存中的签名机制，Cookie 承载	重启后会话失效，需重新登录
主题选择	浏览器 Cookie	用户侧

因此备份策略 = 备份 /opt/glance/config/ 目录，一条命令即可：

tar -czf /opt/glance/backup/glance-config-$(date +%F).tar.gz -C /opt/glance config

恢复时解包回 config/ 目录，docker compose restart glance 生效。升级镜像、重建容器都不会丢失任何业务状态，这也是 Glance 这类单二进制仪表盘相对重型平台的运维优势。

六、环境变量表

Glance 本身不定义任何必需环境变量，环境变量的意义在于配合配置文件中的 ${VAR} 注入语法传递敏感值。本文用到与官方支持的注入方式如下：

环境变量	本文取值来源	作用	对应配置写法
`GLANCE_SECRET_KEY`	`.env` 文件（`secret:make` 生成）	登录会话签名密钥	`auth.secret-key: ${GLANCE_SECRET_KEY}`
任意自定义变量（如 `RSS_URL`）	`.env` 或 `environment:`	抽离任意配置值	`url: ${RSS_URL}`（可嵌在字符串中间）
Docker secret	swarm/compose secrets 挂载到 `/run/secrets/<名>`	免环境变量传密	`token: ${secret:github_token}`
文件路径型变量	环境变量指向密钥文件路径	文件内容注入	`token: ${readFileFromEnv:TOKEN_FILE}`

三点行为约定（官方文档明确，本文实测印证其一）：

变量不存在则拒绝启动：配置里写了 ${VAR} 而环境未提供时，Glance 启动直接报错退出；
改环境变量不触发热重载：配置文件变更会自动重载，环境变量变更必须 docker compose up -d（重建容器）才生效，实测中调整密钥后需重建；
需要原样输出 ${NAME} 字面量时用反斜杠转义：\${NOT_AN_ENV_VAR}。

七、配置参数说明

本章只覆盖编排层直接相关的服务端参数；glance.yml 全部顶层属性（server/auth/branding/theme/pages 等）与 28 类组件的逐参数说明属配置专题范畴，见专栏《Glance v0.8.7 配置参数详解（glance.yml）》篇。

server.port 与端口映射的关系：应用内部恒定监听 8080（或你在 server.port 里改的值），对外端口完全由编排文件 ports 决定。两者独立：

只改对外端口 → 只改 ports: - "8134:8080"；
改应用端口 → 改 server.port 并同步改 ports 右侧值（如 "8133:9090"），但镜像入口命令已带 --config /app/config/glance.yml，端口值读的就是这份配置，无需其他改动。

认证相关三参数（auth: 顶层属性）：

参数	说明
`secret-key`	会话签名密钥，`secret:make` 生成；轮换后所有已发会话失效
`users.<名>.password`	明文口令，简单但配置文件可见
`users.<名>.password-hash`	bcrypt 哈希（`password:hash` 生成），与 `password` 二选一，推荐

防爆破封禁：同一来源 IP 在 5 分钟内连续失败 5 次将被自动封禁。该机制依赖真实客户端 IP——若前面有 Nginx/Traefik 等反向代理，必须在配置中设置 server.proxied: true，让 Glance 从 X-Forwarded-For 头取真实 IP，否则封禁会把代理 IP 当成攻击者，全体用户连坐。

八、配置文件挂载

挂载路径必须对准 /app/config：镜像入口命令硬编码 /app/glance --config /app/config/glance.yml。两种挂载姿势：

推荐：挂载整个目录（本文用法）：/opt/glance/config:/app/config。好处是 $include 拆分的子配置文件、未来加入的 assets 都自然落进来，且文件监听（热重载）在目录内稳定生效；
挂载单个文件：/opt/glance/config/glance.yml:/app/config/glance.yml 可行，但编辑器原子替换（先写临时文件再 rename）会使 inode 变化，部分挂载场景下文件监听失效，需要重启服务才生效。

热重载实测：服务运行中把配置里 rss 的 limit: 10 改为 limit: 5，约 2 秒后日志出现：

glance-v0.8.7-web  | 2026/10/25 03:23:06 Config file changed, reloading...
glance-v0.8.7-web  | 2026/10/25 03:23:06 Starting server on :8080 (base-url: "", assets-path: "")

改回后再次触发重载。两点注意（官方文档约定）：

运行中改错配置不会导致服务退出：日志打印 Config has errors: ...，继续用旧配置运行，改正后自动恢复；
每次重载会清空内存缓存，数据源会被重新抓取——频繁保存配置可能触发上游 API 限流，编辑配置时别连续保存十几遍。

自定义静态资源：若组件引用本地图标（assets-path 场景），把资源目录也挂进来并保持路径一致，例如宿主 /opt/glance/assets 挂到 /app/assets，配置写 server.assets-path: /app/assets。

九、等价 docker run

不使用 Compose 时，以下单条 docker run 与第 4.4 节编排完全等价（密钥直接用环境变量传入，.env 步骤省略）：

docker run -d \
  --name glance-v0.8.7-web \
  --restart unless-stopped \
  -p 8133:8080 \
  -v /opt/glance/config:/app/config \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -e GLANCE_SECRET_KEY=OL3ETt4TxDNu+rEY6IICc368IQ2UtyxkYUpNmWIrSCzz3pmiuJDPTrRdky+0oq22XHF8T2d9LsyikeK4ZL5UUg== \
  --network glance-net \
  glanceapp/glance:v0.8.7

本文在验证环境以 8135 端口实测该命令（避免与 Compose 栈的 8133 冲突）：容器正常启动，日志同样输出 Starting server on :8080 (base-url: "", assets-path: "")，未登录访问返回 303 -> http://127.0.0.1:8135/login，POST /api/authenticate 返回 200，行为与 Compose 部署完全一致。测试完用 docker rm -f glance-v0.8.7-web 清理。

选型建议：单实例长期运行用 Compose（配置即代码、升级/回滚/依赖网络声明都结构化）；临时验证或一次性跑子命令（secret:make/password:hash/config:validate）用 docker run --rm。

十、常用运维命令

以下命令均在 /opt/glance/ 目录下执行。

状态与日志：

docker compose ps                # 运行状态（STATUS 列看进程存活）
docker compose logs -f glance    # 跟踪日志（Ctrl+C 退出，服务不受影响）
docker stats --no-stream glance-v0.8.7-web   # 资源占用

docker stats 实测输出：

NAME                  CPU %     MEM USAGE / LIMIT
glance-v0.8.7-web     0.25%     10MiB / 23.42GiB

💡 说明：Glance 常驻内存约 10MiB、CPU 基本为 0，对低配小机（1C512M 级别的 VPS/NAS）非常友好。

重启与停止：

docker compose restart glance    # 重启（改了环境变量/挂载后用）
docker compose stop              # 停止（容器保留）
docker compose down              # 停止并删除容器与网络（config 目录不受影响）
docker compose up -d             # 再次拉起

restart 实测输出：

 Restarting glance-v0.8.7-stack-glance-1 ... done

配置热重载（免重启）：直接编辑宿主 /opt/glance/config/glance.yml 保存即可，约 2 秒生效，日志出现 Config file changed, reloading...（实测回显见第八章）。改环境变量则必须 docker compose up -d 重建。

升级版本：改镜像标签 → 拉取 → 重建，三步完成，配置数据无需迁移：

sed -i 's|glanceapp/glance:v0.8.7|glanceapp/glance:v0.8.8|' docker-compose.yml   # 以官方 Releases 实际最新版为准
docker compose pull
docker compose up -d

docker compose pull 拉取新层后 up -d 自动重建容器；回滚把标签改回旧版本重跑后两步即可。因 config/ 是 bind mount，升级不触碰任何持久化数据。

备份：见第五章，tar 打包 config/ 目录即可。

十一、常见问题

Q1：容器反复重启，日志报 parsing config: reading /app/config/glance.yml: no such file or directory

挂载源目录不存在。Docker 对不存在的 bind mount 源路径会自动创建空目录挂进去，Glance 读不到配置立即退出，restart: unless-stopped 又把它拉起，形成重启循环。本文实测现象：

NAME                IMAGE                     COMMAND                  SERVICE   CREATED         STATUS                                  PORTS
glance-v0.8.7-web   glanceapp/glance:v0.8.7   "/app/glance --confi…"   glance    5 seconds ago   Restarting (1) Less than a second ago

glance-v0.8.7-web  | parsing config: reading /app/config/glance.yml: no such file or directory

解决：确保宿主 config/ 目录已创建且里面有 glance.yml（mkdir -p /opt/glance/config 后先写好配置再 up -d），docker compose up -d 重建。

Q2：启动报 Bind for 0.0.0.0:8134 failed: port is already allocated

宿主端口已被其他进程或其他容器映射占用。先排查再换端口：ss -ltn | grep 8134 看宿主监听，docker ps --format '{{.Names}} {{.Ports}}' 看其他容器的端口映射。改编排文件 ports 左侧端口后 up -d。

Q3：配置写错导致服务无法启动 / 运行中改错配置

启动前就错：Glance 启动即退出（不缩写成警告），日志给出精确行号，如 parsing config: ...；
运行中改错：服务不退出，日志打印 Config has errors: line 6: unknown widget type: broken-widget 这类带行号的错误，继续用旧配置服务，改正保存后自动重载恢复。

提交前用一次性容器预检（不占用端口、不改任何状态）：

docker run --rm -v /opt/glance/config:/app/config glanceapp/glance:v0.8.7 config:validate

无输出且退出码 0 即通过；有错则输出 Config file is invalid: line N: ...。

Q4：docker-containers 组件空白或报错

该组件需要访问 Docker socket。未挂载 /var/run/docker.sock 时组件无法列出容器；挂载后默认显示全部容器，配置了 hide-by-default: true 则只显示带 glance.hide: "false" 标签的容器——如果面板空白，先检查对应容器是否漏打标签。安全提示：socket 等价宿主 root 权限，务必只读挂载（:ro），公网暴露的机器建议改用 docker-socket-proxy。

Q5：登录连续失败后被封

5 分钟内失败 5 次即触发 IP 封禁，等待即可解封（进程内存态，重启服务也会清空）。若部署在反向代理后面且未设置 server.proxied: true，封禁会错误地作用在代理 IP 上，按第七章说明补齐配置。

Q6：RSS/行情/视频等组件显示红色错误点

组件右上角红点表示该数据源抓取失败，查看日志可见具体原因。本文写作环境为出站受限网络，实测日志示例：

glance-v0.8.7-web  | 2026/10/25 03:22:41 ERROR Failed to get RSS feed url=https://selfh.st/rss/ error="context deadline exceeded (Client.Timeout or context cancellation while reading body)"

这类超时属于服务器出网策略问题，不是部署故障：给服务器配置可用的出网代理或放行对应域名后，组件会在下个抓取周期自动恢复。终端排障可直接跑诊断子命令逐项检查各数据源连通性：

docker run --rm glanceapp/glance:v0.8.7 diagnose

Q7：docker compose down 会删数据吗

不会。down 只删除容器与网络，config/ 是宿主 bind mount，原样保留；up -d 即恢复。唯一要养成习惯的是：改配置前先备份一份 glance.yml。

十二、参考链接

官方仓库：https://github.com/glanceapp/glance
官方 Docker 部署文档（README「Running with Docker」节）：https://github.com/glanceapp/glance#running-with-docker
官方编排模板仓库 docker-compose-template：https://github.com/glanceapp/docker-compose-template
官方配置文档（configuration.md）：https://github.com/glanceapp/glance/blob/main/docs/configuration.md
Docker Hub 镜像仓库：https://hub.docker.com/r/glanceapp/glance
本专栏相关文档：《Glance v0.8.7 介绍与选型指南》