kkFileView 基础镜像构建全解Dockerfile 分层设计、构建命令与跨平台 buildx 实战指南【免费下载链接】kkFileViewUniversal File Online Preview Project based on Spring-Boot项目地址: https://gitcode.com/GitHub_Trending/kk/kkFileView本文围绕 kkFileView 仓库中 docker/kkfileview-base/README.cn.md 所定义的构建说明展开讲清“基础镜像 应用镜像”两阶段构建策略的动机与做法逐行剖析 docker/kkfileview-base/Dockerfile 中 JDK 21、LibreOffice 无界面版、中文时区与字体缓存的实现细节并给出docker buildx在单机上同时产出 linux/amd64 与 linux/arm64 双架构镜像的完整前提条件与命令帮助你在没有对应架构物理机的情况下也能正确构建、发布 kkFileView 5.0 的 Docker 镜像。一、为什么要把镜像构建拆成“基础镜像 应用镜像”构建说明文档开宗明义地指出了拆分的理由由于 kkfileview 的基础运行环境很少变动且制作耗时较久而 kkfileview 本身代码开发会频繁改动因此把制作其 Docker 镜像的步骤拆分为两次首先制作 kkfileview 的基础镜像kkfileview-base。然后使用 kkfileview-base 作为基础镜像进行构建加快 kkfileview docker 镜像构建与发布。这条策略对应的就是标准的 Docker 分层缓存思想基础镜像里装的是openjdk-21-jre、libreoffice-nogui这一整套数百 MB 的运行环境编译一次即可长期复用而应用层每次只需重新打包 kkFileView 的 jar 并覆盖一层发布路径非常短。仓库中两处 Dockerfile 恰好构成了这条流水线文件角色构建产物docker/kkfileview-base/Dockerfile基础镜像固化运行环境keking/kkfileview-base:5.0.0根目录 Dockerfile应用镜像仅叠加发布包keking/kkfileview基于 base 镜像构建基础镜像的命令镜像 tag 以 5.0.0 为例与根 pom.xml 中的项目版本5.0.0保持一致docker build --tag keking/kkfileview-base:5.0.0 .注意该命令要在 docker/kkfileview-base/ 目录下执行末尾的.即该目录。文档同时说明本项目维护的 Dockerfile 考虑了跨平台兼容性如果你需要 arm64 架构镜像在 arm64 架构机器上执行同样的构建命令即可而更通用的方案是下文介绍的docker buildx。二、应用层如何消费基础镜像根目录 Dockerfile基础镜像不是终点它存在的意义是被应用层引用。根目录 Dockerfile 全文仅 4 行正好验证了“应用层极简”的设计FROM keking/kkfileview-base:5.0.0 ADD server/target/kkFileView-*.tar.gz /opt/ ENV KKFILEVIEW_BIN_FOLDER/opt/kkFileView-5.0.0/bin ENTRYPOINT [java,-Dfile.encodingUTF-8,-Dspring.config.location/opt/kkFileView-5.0.0/config/application.properties,-jar,/opt/kkFileView-5.0.0/bin/kkFileView-5.0.0.jar]从源码结构看这条链路可以拆解为三步FROM keking/kkfileview-base:5.0.0直接复用基础镜像JDK、LibreOffice、字体等全部来自缓存层不重复编译ADD server/target/kkFileView-*.tar.gz /opt/把 server/pom.xml 打包产出的发行包解压到/opt/。该 tar.gz 由 Maven assembly 插件按 server/src/main/assembly/dist-linux.xml 描述生成包含bin/shell 启动脚本 jar、config/配置文件、log/三个目录并统一使用 Unix 换行符、赋予脚本 755 权限保证 Linux 容器内可直接执行ENTRYPOINT以 UTF-8 编码启动 Spring Boot 应用并通过-Dspring.config.location显式指向发行包内config/application.properties——也就是 server/src/main/config/application.properties 中定义的端口默认 8012、office.homeOffice/LibreOffice 组件路径、office.plugin.server.portsOffice 服务端口等运行参数。也就是说基础镜像负责“环境正确”Java、LibreOffice、中文字体、时区、语言环境应用镜像只负责“代码最新”。两者解耦后日常发版只需执行应用层构建这正是 构建说明 中“加快 docker 镜像构建与发布”的工程落点。三、基础镜像 Dockerfile 逐段解析基础镜像的全部技术含量都浓缩在 docker/kkfileview-base/Dockerfile 里以下按语句顺序拆解说明每一段在解决 kkFileView 文件预览场景中的什么问题。3.1 基础系统与国内 apt 源替换FROM ubuntu:24.04 RUN sed -i s//.*archive.ubuntu.com//mirrors.aliyun.comg /etc/apt/sources.list.d/ubuntu.sources \ sed -i s//security.ubuntu.com//mirrors.aliyun.comg /etc/apt/sources.list.d/ubuntu.sources \ sed -i s//ports.ubuntu.com//mirrors.aliyun.comg /etc/apt/sources.list.d/ubuntu.sources \ apt-get update \ ...基础系统选择 Ubuntu 24.04 LTS。三条sed分别把archive.ubuntu.com、security.ubuntu.com、ports.ubuntu.com替换为阿里云镜像源——值得注意的是第三条针对ports.ubuntu.com这正是arm64 等非 x86 架构的包源域名这也解释了 构建说明 所说的“Dockerfile 考虑了跨平台兼容性”同一份 Dockerfile 在 amd64 与 arm64 上都能拉到对应的包。3.2 核心运行环境JDK 21 LibreOffice 无界面版export DEBIAN_FRONTENDnoninteractive \ apt-get install -y --no-install-recommends openjdk-21-jre tzdata locales xfonts-utils fontconfig libreoffice-nogui \这一行是基础镜像的“主菜”各包对应 kkFileView 的运行依赖包作用openjdk-21-jrekkFileView 5.0 运行所需 JRE 21与 doc/ci-auto-deploy.md 中线上部署使用的 JDK 21 一致libreoffice-noguiOffice 文档doc/xls/ppt 等转 PDF 的引擎无界面版去掉 GUI 依赖减小镜像体积。应用侧通过office.home默认default自动查找与office.plugin.server.ports 2001,2002调用它tzdata时区数据库locales生成中文语言环境xfonts-utilsfontconfig提供mkfontscale/mkfontdir/fc-cache等字体工具供后续字体缓存步骤使用--no-install-recommends与DEBIAN_FRONTENDnoninteractive是 Docker 镜像瘦身与无人值守安装的标准手段末尾的apt-get autoremove -y apt-get clean rm -rf /var/lib/apt/lists/*则清空包缓存避免 apt 索引进入最终镜像层。3.3 时区与中文语言环境echo Asia/Shanghai /etc/timezone \ ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \ localedef -i zh_CN -c -f UTF-8 -A /usr/share/locale/locale.alias zh_CN.UTF-8 \ locale-gen zh_CN.UTF-8将系统时区固定为Asia/Shanghai并用localedeflocale-gen生成zh_CN.UTF-8语言环境。对文件预览服务而言时区直接影响文档中日期类内容的转换结果而 UTF-8 中文 locale 是 LibreOffice 处理中文文档不乱码的底层前提之一。3.4 中文字体三件套与字体缓存apt-get install -y --no-install-recommends ttf-mscorefonts-installer \ apt-get install -y --no-install-recommends ttf-wqy-microhei ttf-wqy-zenhei xfonts-wqy \ ... # 内置一些常用的中文字体避免普遍性乱码 ADD fonts/* /usr/share/fonts/chinese/ RUN cd /usr/share/fonts/chinese \ # 安装字体 mkfontscale \ mkfontdir \ fc-cache -fv ENV LANGzh_CN.UTF-8 LC_ALLzh_CN.UTF-8字体部分是整个 Dockerfile 中唯一带中文注释的段落点明了它的目标内置常用中文字体避免普遍性乱码。它由三层组成系统字体包ttf-mscorefonts-installer微软核心字体覆盖 Word 文档中最常见的宋体/黑体替代场景 文泉驿系列ttf-wqy-microhei、ttf-wqy-zenhei、xfonts-wqy自定义字体目录ADD fonts/* /usr/share/fonts/chinese/允许维护者向 docker/kkfileview-base/fonts/ 目录追加自有字体后再构建当前仓库该目录仅含占位文件.gitkeep说明字体按需投放、构建时打包进镜像字体缓存刷新mkfontscale mkfontdir fc-cache -fv重新生成 fontconfig 缓存让 LibreOffice 渲染时能立刻识别新字体否则仅复制文件不会生效。最后一行ENV LANGzh_CN.UTF-8 LC_ALLzh_CN.UTF-8把 3.3 生成的语言环境设为全局默认确保容器内任何进程包括 soffice 转换任务都运行在 UTF-8 中文 locale 下。四、跨平台构建用 docker buildx 在一台机器上产出多架构镜像构建说明 的第二部分给出了仓库推荐的多架构构建方案。docker buildx支持在一台机器上构建出多种平台架构的镜像例如在 amd64 机器上执行docker buildx build并加上--platformlinux/arm64参数即可构建出 arm64 架构镜像——这极大方便了那些没有 arm64 机器却想构建 arm64 镜像的用户。文档明确了当前项目的支持边界当前本项目仅支持构建 linux/amd64 和 linux/arm64 两种平台架构的镜像。4.1 前提要求以当前机器为 amd64x86_64架构为例需要开启 docker 的 buildx 特性以及开启 Linux 的 QEMU 用户模式。使用 WSL2 的 Windows 用户如果安装了最新的 Docker Desktop则这些前提要求已满足无需额外设置。1. 安装 docker buildx 客户端插件Docker 版本要求 19.03若已安装则跳过docker version docker buildx version # 验证插件是否可用2. 开启 QEMU 用户模式并安装其它平台的模拟器Linux 内核要求 4.8。使用tonistiigi/binfmt镜像可快速开启并安装模拟器docker run --privileged --rm tonistiigi/binfmt --install all--privileged是为了让容器能向宿主内核注册 binfmt_misc 处理器--install all会注册 arm64 等各架构的 QEMU 用户态模拟器之后 Docker 就能在 amd64 机器上“执行” arm64 的构建指令以模拟性能运行。4.2 双架构构建命令前提就绪后一条命令同时构建并推送两种架构的 manifestdocker buildx build --platformlinux/amd64,linux/arm64 -t keking/kkfileview-base:5.0.0 --push .参数说明参数含义--platformlinux/amd64,linux/arm64声明本次构建产出的目标平台列表逗号分隔-t keking/kkfileview-base:5.0.0镜像名与 tag与单架构构建保持一致便于下游 Dockerfile 的FROM直接引用--push多平台构建要求输出为镜像 manifest list需推送到 registry 完成仅--load无法同时加载多平台.构建上下文指向 docker/kkfileview-base/ 目录4.3 关于 buildx 的 builder driver文档补充说明buildx 的 builder driver 可以使用默认的docker类型若使用docker-container类型则可以支持并行构建多种架构文档本身不再赘述并指引读者参考 Docker 官方 Buildx 文档自行了解。这里可以推断对于基础镜像这种“制作耗时较久”的场景docker-containerdriver 的并行构建能力会进一步压缩双架构总构建时间但这属于构建机层面的调优不改变上述命令本身。五、构建注意事项与版本一致性结合 构建说明 与两处 Dockerfile实际维护基础镜像时需注意以下几点tag 与项目版本对齐base 镜像 tag5.0.0与 pom.xml 中的项目版本、根 Dockerfile 中的FROM keking/kkfileview-base:5.0.0及KKFILEVIEW_BIN_FOLDER/opt/kkFileView-5.0.0/bin路径形成三处联动。升级大版本时这三处需要一起改否则应用镜像要么拉不到基础镜像要么 jar 路径不匹配基础镜像尽量不轻易重建它的设计目的就是“很少变动”。日常代码迭代只重建应用层只有当 JDK 版本、LibreOffice 版本或字体集发生变化时才重建 base 并推送新 tag追加字体后必须重建 base向 docker/kkfileview-base/fonts/ 投放字体文件后需重新执行 3.1 节构建命令或 4.2 节的双架构命令ADD fonts/*层的变更才会进入镜像并触发fc-cache刷新跨架构验证在 amd64 机器上以 QEMU 模拟构建的 arm64 镜像建议再在真实 arm64 环境或 arm64 CI runner上执行docker run做一次 LibreOffice 文档转换冒烟验证确认字体与libreoffice-nogui在该架构下的行为一致因为模拟构建只能保证“构建成功”不能替代目标架构上的运行验证。小结kkFileView 5.0 的 Docker 构建体系可以归纳为一句话用一个稳定的keking/kkfileview-base:5.0.0基础镜像锁定 Ubuntu 24.04 JRE 21 libreoffice-nogui 中文字体与中文 locale 的完整预览运行环境应用层仅叠加 Maven assembly 产出的发行包并通过docker buildx的 QEMU 用户模式在一台 amd64 机器上同时交付 linux/amd64 与 linux/arm64 双架构镜像。掌握 docker/kkfileview-base/README.cn.md 中的构建命令与 docker/kkfileview-base/Dockerfile 的各层职责后你就可以独立完成基础镜像的维护、字体扩展和多架构发布了。【免费下载链接】kkFileViewUniversal File Online Preview Project based on Spring-Boot项目地址: https://gitcode.com/GitHub_Trending/kk/kkFileView创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 kkFileView 基础镜像构建全解：Dockerfile 分层设计、构建命令与跨平台 buildx 实战指南
kkFileView 基础镜像构建全解Dockerfile 分层设计、构建命令与跨平台 buildx 实战指南【免费下载链接】kkFileViewUniversal File Online Preview Project based on Spring-Boot项目地址: https://gitcode.com/GitHub_Trending/kk/kkFileView本文围绕 kkFileView 仓库中 docker/kkfileview-base/README.cn.md 所定义的构建说明展开讲清“基础镜像 应用镜像”两阶段构建策略的动机与做法逐行剖析 docker/kkfileview-base/Dockerfile 中 JDK 21、LibreOffice 无界面版、中文时区与字体缓存的实现细节并给出docker buildx在单机上同时产出 linux/amd64 与 linux/arm64 双架构镜像的完整前提条件与命令帮助你在没有对应架构物理机的情况下也能正确构建、发布 kkFileView 5.0 的 Docker 镜像。一、为什么要把镜像构建拆成“基础镜像 应用镜像”构建说明文档开宗明义地指出了拆分的理由由于 kkfileview 的基础运行环境很少变动且制作耗时较久而 kkfileview 本身代码开发会频繁改动因此把制作其 Docker 镜像的步骤拆分为两次首先制作 kkfileview 的基础镜像kkfileview-base。然后使用 kkfileview-base 作为基础镜像进行构建加快 kkfileview docker 镜像构建与发布。这条策略对应的就是标准的 Docker 分层缓存思想基础镜像里装的是openjdk-21-jre、libreoffice-nogui这一整套数百 MB 的运行环境编译一次即可长期复用而应用层每次只需重新打包 kkFileView 的 jar 并覆盖一层发布路径非常短。仓库中两处 Dockerfile 恰好构成了这条流水线文件角色构建产物docker/kkfileview-base/Dockerfile基础镜像固化运行环境keking/kkfileview-base:5.0.0根目录 Dockerfile应用镜像仅叠加发布包keking/kkfileview基于 base 镜像构建基础镜像的命令镜像 tag 以 5.0.0 为例与根 pom.xml 中的项目版本5.0.0保持一致docker build --tag keking/kkfileview-base:5.0.0 .注意该命令要在 docker/kkfileview-base/ 目录下执行末尾的.即该目录。文档同时说明本项目维护的 Dockerfile 考虑了跨平台兼容性如果你需要 arm64 架构镜像在 arm64 架构机器上执行同样的构建命令即可而更通用的方案是下文介绍的docker buildx。二、应用层如何消费基础镜像根目录 Dockerfile基础镜像不是终点它存在的意义是被应用层引用。根目录 Dockerfile 全文仅 4 行正好验证了“应用层极简”的设计FROM keking/kkfileview-base:5.0.0 ADD server/target/kkFileView-*.tar.gz /opt/ ENV KKFILEVIEW_BIN_FOLDER/opt/kkFileView-5.0.0/bin ENTRYPOINT [java,-Dfile.encodingUTF-8,-Dspring.config.location/opt/kkFileView-5.0.0/config/application.properties,-jar,/opt/kkFileView-5.0.0/bin/kkFileView-5.0.0.jar]从源码结构看这条链路可以拆解为三步FROM keking/kkfileview-base:5.0.0直接复用基础镜像JDK、LibreOffice、字体等全部来自缓存层不重复编译ADD server/target/kkFileView-*.tar.gz /opt/把 server/pom.xml 打包产出的发行包解压到/opt/。该 tar.gz 由 Maven assembly 插件按 server/src/main/assembly/dist-linux.xml 描述生成包含bin/shell 启动脚本 jar、config/配置文件、log/三个目录并统一使用 Unix 换行符、赋予脚本 755 权限保证 Linux 容器内可直接执行ENTRYPOINT以 UTF-8 编码启动 Spring Boot 应用并通过-Dspring.config.location显式指向发行包内config/application.properties——也就是 server/src/main/config/application.properties 中定义的端口默认 8012、office.homeOffice/LibreOffice 组件路径、office.plugin.server.portsOffice 服务端口等运行参数。也就是说基础镜像负责“环境正确”Java、LibreOffice、中文字体、时区、语言环境应用镜像只负责“代码最新”。两者解耦后日常发版只需执行应用层构建这正是 构建说明 中“加快 docker 镜像构建与发布”的工程落点。三、基础镜像 Dockerfile 逐段解析基础镜像的全部技术含量都浓缩在 docker/kkfileview-base/Dockerfile 里以下按语句顺序拆解说明每一段在解决 kkFileView 文件预览场景中的什么问题。3.1 基础系统与国内 apt 源替换FROM ubuntu:24.04 RUN sed -i s//.*archive.ubuntu.com//mirrors.aliyun.comg /etc/apt/sources.list.d/ubuntu.sources \ sed -i s//security.ubuntu.com//mirrors.aliyun.comg /etc/apt/sources.list.d/ubuntu.sources \ sed -i s//ports.ubuntu.com//mirrors.aliyun.comg /etc/apt/sources.list.d/ubuntu.sources \ apt-get update \ ...基础系统选择 Ubuntu 24.04 LTS。三条sed分别把archive.ubuntu.com、security.ubuntu.com、ports.ubuntu.com替换为阿里云镜像源——值得注意的是第三条针对ports.ubuntu.com这正是arm64 等非 x86 架构的包源域名这也解释了 构建说明 所说的“Dockerfile 考虑了跨平台兼容性”同一份 Dockerfile 在 amd64 与 arm64 上都能拉到对应的包。3.2 核心运行环境JDK 21 LibreOffice 无界面版export DEBIAN_FRONTENDnoninteractive \ apt-get install -y --no-install-recommends openjdk-21-jre tzdata locales xfonts-utils fontconfig libreoffice-nogui \这一行是基础镜像的“主菜”各包对应 kkFileView 的运行依赖包作用openjdk-21-jrekkFileView 5.0 运行所需 JRE 21与 doc/ci-auto-deploy.md 中线上部署使用的 JDK 21 一致libreoffice-noguiOffice 文档doc/xls/ppt 等转 PDF 的引擎无界面版去掉 GUI 依赖减小镜像体积。应用侧通过office.home默认default自动查找与office.plugin.server.ports 2001,2002调用它tzdata时区数据库locales生成中文语言环境xfonts-utilsfontconfig提供mkfontscale/mkfontdir/fc-cache等字体工具供后续字体缓存步骤使用--no-install-recommends与DEBIAN_FRONTENDnoninteractive是 Docker 镜像瘦身与无人值守安装的标准手段末尾的apt-get autoremove -y apt-get clean rm -rf /var/lib/apt/lists/*则清空包缓存避免 apt 索引进入最终镜像层。3.3 时区与中文语言环境echo Asia/Shanghai /etc/timezone \ ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \ localedef -i zh_CN -c -f UTF-8 -A /usr/share/locale/locale.alias zh_CN.UTF-8 \ locale-gen zh_CN.UTF-8将系统时区固定为Asia/Shanghai并用localedeflocale-gen生成zh_CN.UTF-8语言环境。对文件预览服务而言时区直接影响文档中日期类内容的转换结果而 UTF-8 中文 locale 是 LibreOffice 处理中文文档不乱码的底层前提之一。3.4 中文字体三件套与字体缓存apt-get install -y --no-install-recommends ttf-mscorefonts-installer \ apt-get install -y --no-install-recommends ttf-wqy-microhei ttf-wqy-zenhei xfonts-wqy \ ... # 内置一些常用的中文字体避免普遍性乱码 ADD fonts/* /usr/share/fonts/chinese/ RUN cd /usr/share/fonts/chinese \ # 安装字体 mkfontscale \ mkfontdir \ fc-cache -fv ENV LANGzh_CN.UTF-8 LC_ALLzh_CN.UTF-8字体部分是整个 Dockerfile 中唯一带中文注释的段落点明了它的目标内置常用中文字体避免普遍性乱码。它由三层组成系统字体包ttf-mscorefonts-installer微软核心字体覆盖 Word 文档中最常见的宋体/黑体替代场景 文泉驿系列ttf-wqy-microhei、ttf-wqy-zenhei、xfonts-wqy自定义字体目录ADD fonts/* /usr/share/fonts/chinese/允许维护者向 docker/kkfileview-base/fonts/ 目录追加自有字体后再构建当前仓库该目录仅含占位文件.gitkeep说明字体按需投放、构建时打包进镜像字体缓存刷新mkfontscale mkfontdir fc-cache -fv重新生成 fontconfig 缓存让 LibreOffice 渲染时能立刻识别新字体否则仅复制文件不会生效。最后一行ENV LANGzh_CN.UTF-8 LC_ALLzh_CN.UTF-8把 3.3 生成的语言环境设为全局默认确保容器内任何进程包括 soffice 转换任务都运行在 UTF-8 中文 locale 下。四、跨平台构建用 docker buildx 在一台机器上产出多架构镜像构建说明 的第二部分给出了仓库推荐的多架构构建方案。docker buildx支持在一台机器上构建出多种平台架构的镜像例如在 amd64 机器上执行docker buildx build并加上--platformlinux/arm64参数即可构建出 arm64 架构镜像——这极大方便了那些没有 arm64 机器却想构建 arm64 镜像的用户。文档明确了当前项目的支持边界当前本项目仅支持构建 linux/amd64 和 linux/arm64 两种平台架构的镜像。4.1 前提要求以当前机器为 amd64x86_64架构为例需要开启 docker 的 buildx 特性以及开启 Linux 的 QEMU 用户模式。使用 WSL2 的 Windows 用户如果安装了最新的 Docker Desktop则这些前提要求已满足无需额外设置。1. 安装 docker buildx 客户端插件Docker 版本要求 19.03若已安装则跳过docker version docker buildx version # 验证插件是否可用2. 开启 QEMU 用户模式并安装其它平台的模拟器Linux 内核要求 4.8。使用tonistiigi/binfmt镜像可快速开启并安装模拟器docker run --privileged --rm tonistiigi/binfmt --install all--privileged是为了让容器能向宿主内核注册 binfmt_misc 处理器--install all会注册 arm64 等各架构的 QEMU 用户态模拟器之后 Docker 就能在 amd64 机器上“执行” arm64 的构建指令以模拟性能运行。4.2 双架构构建命令前提就绪后一条命令同时构建并推送两种架构的 manifestdocker buildx build --platformlinux/amd64,linux/arm64 -t keking/kkfileview-base:5.0.0 --push .参数说明参数含义--platformlinux/amd64,linux/arm64声明本次构建产出的目标平台列表逗号分隔-t keking/kkfileview-base:5.0.0镜像名与 tag与单架构构建保持一致便于下游 Dockerfile 的FROM直接引用--push多平台构建要求输出为镜像 manifest list需推送到 registry 完成仅--load无法同时加载多平台.构建上下文指向 docker/kkfileview-base/ 目录4.3 关于 buildx 的 builder driver文档补充说明buildx 的 builder driver 可以使用默认的docker类型若使用docker-container类型则可以支持并行构建多种架构文档本身不再赘述并指引读者参考 Docker 官方 Buildx 文档自行了解。这里可以推断对于基础镜像这种“制作耗时较久”的场景docker-containerdriver 的并行构建能力会进一步压缩双架构总构建时间但这属于构建机层面的调优不改变上述命令本身。五、构建注意事项与版本一致性结合 构建说明 与两处 Dockerfile实际维护基础镜像时需注意以下几点tag 与项目版本对齐base 镜像 tag5.0.0与 pom.xml 中的项目版本、根 Dockerfile 中的FROM keking/kkfileview-base:5.0.0及KKFILEVIEW_BIN_FOLDER/opt/kkFileView-5.0.0/bin路径形成三处联动。升级大版本时这三处需要一起改否则应用镜像要么拉不到基础镜像要么 jar 路径不匹配基础镜像尽量不轻易重建它的设计目的就是“很少变动”。日常代码迭代只重建应用层只有当 JDK 版本、LibreOffice 版本或字体集发生变化时才重建 base 并推送新 tag追加字体后必须重建 base向 docker/kkfileview-base/fonts/ 投放字体文件后需重新执行 3.1 节构建命令或 4.2 节的双架构命令ADD fonts/*层的变更才会进入镜像并触发fc-cache刷新跨架构验证在 amd64 机器上以 QEMU 模拟构建的 arm64 镜像建议再在真实 arm64 环境或 arm64 CI runner上执行docker run做一次 LibreOffice 文档转换冒烟验证确认字体与libreoffice-nogui在该架构下的行为一致因为模拟构建只能保证“构建成功”不能替代目标架构上的运行验证。小结kkFileView 5.0 的 Docker 构建体系可以归纳为一句话用一个稳定的keking/kkfileview-base:5.0.0基础镜像锁定 Ubuntu 24.04 JRE 21 libreoffice-nogui 中文字体与中文 locale 的完整预览运行环境应用层仅叠加 Maven assembly 产出的发行包并通过docker buildx的 QEMU 用户模式在一台 amd64 机器上同时交付 linux/amd64 与 linux/arm64 双架构镜像。掌握 docker/kkfileview-base/README.cn.md 中的构建命令与 docker/kkfileview-base/Dockerfile 的各层职责后你就可以独立完成基础镜像的维护、字体扩展和多架构发布了。【免费下载链接】kkFileViewUniversal File Online Preview Project based on Spring-Boot项目地址: https://gitcode.com/GitHub_Trending/kk/kkFileView创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考