为什么基于rocker/shiny构建的Docker镜像体积达2GB？如何优化？

算力阿峰

2026-9-23

镜像体积过大的核心原因

未清理APT缓存：执行apt-get update和apt-get install后，系统会留下软件源索引、安装包缓存等冗余文件，默认不会自动删除，单次操作最多可占用数百MB空间。
Docker分层机制导致删除操作不生效：Docker每个RUN/COPY指令都会生成独立的只读层，你执行RUN sudo rm -r /srv/shiny-server/*只是在当前层添加了文件删除标记，基础镜像中自带的示例应用文件仍存在于底层镜像，不会减少整体体积。
R包安装残留未清理：renv::restore()执行时会下载包源码、留存编译临时文件，同时renv默认会在用户目录下生成全局缓存，这些文件你没有主动清理，会全部留在镜像层中。
安装了不必要的开发依赖：你安装的libmysqlclient-dev是开发版本包，包含头文件、静态库等编译用资源，体积是对应运行时库的数倍，如果仅运行应用不需要开发包。
指令拆分过多引入冗余层：多个独立的RUN、COPY指令会生成更多镜像层，每层的冗余数据都会累计到最终镜像体积中。

优化方案

合并APT操作并即时清理缓存：将APT更新、安装、缓存清理放在同一个RUN指令中，避免缓存文件留存到镜像层，同时可将开发依赖改为运行时依赖，如需编译可在R包安装完成后卸载开发依赖。
优化R包安装逻辑：将renv安装、依赖恢复、缓存清理放在同一个RUN中，执行完安装后删除renv缓存、临时文件、安装包源码。
采用多阶段构建：拆分编译阶段和运行阶段，第一阶段完成所有依赖编译、安装操作，第二阶段仅拷贝运行必需的二进制文件、依赖库、应用代码和配置，完全剔除编译阶段的冗余文件。
合并同类指令：将多个COPY、RUN操作合并，减少镜像层数。

优化后参考Dockerfile

# 第一阶段：编译依赖阶段
FROM rocker/shiny:latest AS builder

# 安装编译需要的依赖
RUN apt-get update && apt-get install -y \
    sudo \
    libmysqlclient-dev \
    && rm -rf /var/lib/apt/lists/* \
    && apt-get clean

# 拷贝renv配置
COPY /renv/profiles/prod/renv.lock ./renv.lock

# 安装R依赖并清理全部缓存
RUN Rscript -e 'install.packages("renv");renv::consent(provided = TRUE);renv::restore()' \
    && rm -rf /tmp/* \
    && rm -rf /root/.cache/R/renv \
    && rm ./renv.lock

# 第二阶段：运行阶段
FROM rocker/shiny:latest

# 仅安装运行必需的依赖，用运行时包替代开发包
RUN apt-get update && apt-get install -y --no-install-recommends \
    libmysqlclient21 \
    && rm -rf /var/lib/apt/lists/* \
    && apt-get clean \
    # 直接在同一层删除基础镜像自带的示例应用，避免额外层冗余
    && rm -rf /srv/shiny-server/*

# 从编译阶段拷贝已经安装好的R包
COPY --from=builder /usr/local/lib/R/site-library /usr/local/lib/R/site-library

# 拷贝应用相关文件，合并为一个COPY减少分层
COPY index.html shiny-server.conf /srv/shiny-server/
COPY app1 /srv/shiny-server/app1
COPY app2 /srv/shiny-server/app2
COPY ./run.sh /run.sh

RUN chmod +x /run.sh

CMD ["./run.sh"]

按照上述方案优化后，最终镜像体积通常可控制在700MB以内，符合预期范围。

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