为何Kaniko无法缓存Docker多阶段构建中的指定层？

Docker多阶段构建配置 #

ARG COMPOSER_VERSION=2.5
ARG PHP_VERSION=7.4-apache
FROM --platform=${TARGETPLATFORM} php:${PHP_VERSION} AS composer

COPY --from=composer:2.5 /usr/bin/composer /usr/local/bin/composer

RUN apt-get -yq update && \
    apt-get -yqq install ssh git zlib1g-dev libzip-dev zip unzip && \
    docker-php-ext-install zip && \
    mkdir -p -m 0600 /root/.ssh && \
    ssh-keyscan eae-git.eng.utah.edu >> /root/.ssh/known_hosts

COPY ./html .

ARG CACHE_BUST_COMPOSER

RUN COMPOSER_MEMORY_LIMIT=-1 composer install --prefer-dist --no-scripts --no-progress --no-interaction --no-dev -vvv --ignore-platform-req=ext-bcmath --ignore-platform-req=ext-gd --ignore-platform-req=ext-zip --ignore-platform-req=ext-ldap --ignore-platform-req=ext-exif --ignore-platform-req=ext-imagick --ignore-platform-req=ext-mongodb

FROM --platform=${TARGETPLATFORM} php:${PHP_VERSION} AS build

COPY --from=composer:2.5 /usr/bin/composer /usr/local/bin/composer

RUN apt-get update && \
    mkdir -p /var/run/slapd && \
    DEBIAN_FRONTEND=noninteractive apt-get install -yqq -f --no-install-recommends \
    git \
    supervisor \
    vim \
    slapd \
    ldap-utils \
    ldapscripts \
    libfreetype6-dev \
    libjpeg62-turbo-dev \
    libpng-dev \
    libwebp-dev \
    libgmp-dev \
    libldb-dev \
    libldap2-dev \
    libxml2-dev \
    imagemagick \
    libmagickwand-dev \
    libzip-dev \
    libmongoc-dev \
    libbson-dev \
    libicu-dev \
    libcap2-bin \
    zlib1g-dev \
    ghostscript \
    && docker-php-ext-configure bcmath \
    && docker-php-ext-configure gd --with-freetype --with-jpeg --with-webp \
    && docker-php-ext-configure gmp \
    && docker-php-ext-configure intl \
    && docker-php-ext-configure ldap \
    && docker-php-ext-configure pdo_mysql \
    && docker-php-ext-configure exif \
    && docker-php-ext-configure xmlrpc \
    && docker-php-ext-install -j$(nproc) bcmath gd gmp intl ldap pdo_mysql exif xmlrpc zip \
    && pecl install imagick mongodb \
    && docker-php-ext-enable imagick mongodb \
    && apt-get purge --auto-remove -y $PHPIZE_DEPS \
    && apt-get clean autoclean \
    && apt-get autoremove --yes \
    && rm -rf /var/lib/apt/lists/* \
    && rm -rf /usr/src \
    && a2enmod vhost_alias \
    && a2enmod rewrite headers \
    && setcap 'cap_net_bind_service=+ep' /usr/sbin/apache2

COPY --from=composer --chown=www-data /var/www/html /var/www/html

WORKDIR /var/www/html

RUN php artisan storage:link \
    && php artisan vendor:publish --all --no-interaction \
    && chown -R www-data:www-data /var/www \
    && chown -R www-data:www-data /var/log/apache2 \
    && find /var/www/html -type f -exec chmod 664 {} \; \
    && find /var/www/html -type d -exec chmod 775 {} \;

COPY ./build/docker/apache /etc/apache2/

ARG ENV

RUN if [ "$ENV" = "DEV" ] ; then \
        mv /etc/apache2/dev.conf /etc/apache2/sites-available/000-default.conf ; \
        rm /etc/apache2/prod.conf ; \
    else \
        mv /etc/apache2/prod.conf /etc/apache2/sites-available/000-default.conf ; \
        rm /etc/apache2/dev.conf ; \
    fi

ADD ./build/docker/supervisord.conf /etc/supervisor/supervisord.conf

ADD ./build/docker/php.ini-production "$PHP_INI_DIR/php.ini"

USER www-data

CMD ["/usr/bin/supervisord", "-c", "/etc/supervisor/supervisord.conf"]

GitLab CI Kaniko构建配置 #

Build a New Image:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:v1.18.0-debug
    entrypoint: [""]
  script:
    - CACHE_BUST_COMPOSER=$(date +%s)
    - /kaniko/executor
      --cache=true
      --cache-repo="${CI_REGISTRY_IMAGE}/cache"
      --snapshot-mode=redo
      --use-new-run
      --skip-unused-stages
      --context "${CI_PROJECT_DIR}"
      --dockerfile "${CI_PROJECT_DIR}/build/docker/Dockerfile"
      --destination "${CI_REGISTRY_IMAGE}${DIR}:${LATEST_VERSION}"
      --build-arg EAE_GITLAB_TOKEN=${EAE_GITLAB_TOKEN}
      --build-arg CACHE_BUST_COMPOSER=${CACHE_BUST_COMPOSER}
      --build-arg ENV=PROD

问题描述 #

本地Docker可正常缓存构建过程中的某大型依赖安装/扩展编译层，但使用GitLab CI运行Kaniko时，该大型层始终无法命中缓存。已知composer install层会通过CACHE_BUST_COMPOSER主动失效，且Kaniko缓存仓库可正常命中其他层，仅该大型层无法缓存。

排查分析与解决方案 #

可能原因 #

1. 快照模式差异：Kaniko使用的--snapshot-mode=redo会严格校验文件的元数据（权限、时间戳等），而本地Docker默认的快照模式对元数据差异容忍度更高，导致缓存键计算不一致，无法命中。
2. 平台参数不确定性：Dockerfile中使用--platform=${TARGETPLATFORM}，若GitLab CI Runner的平台与本地不一致，或Kaniko对平台参数的处理逻辑与本地Docker不同，会导致基础镜像哈希变化，进而影响后续层的缓存匹配。
3. 并发数变量差异：docker-php-ext-install -j$(nproc)中的nproc在本地和CI环境返回的数值可能不同，导致RUN指令的命令行参数不一致，缓存键计算时判定为不同层。
4. APT源/包版本差异：本地与CI环境的APT源可能不同，导致安装的依赖包版本存在细微差异，即使命令一致，生成的层内容也会不同，无法命中缓存。

对应解决方案 #

• 调整快照模式：将Kaniko的--snapshot-mode=redo改为默认的full或time模式，缩小与本地Docker快照逻辑的差异，减少不必要的哈希变化。
• 固定平台参数：显式指定TARGETPLATFORM为固定值（如linux/amd64），在Dockerfile或Kaniko构建参数中设置，避免平台变量波动影响缓存。
• 固定并发数：将$(nproc)替换为固定数值（如-j4），确保CI与本地环境的命令行参数完全一致。
• 统一APT源与包版本：在Dockerfile的RUN指令中指定固定的APT源（如使用国内镜像源），并明确依赖包的版本号，确保本地与CI环境安装的包内容一致。
• 拆分大型RUN指令：将原本的大型依赖安装/扩展编译指令拆分为多个独立的RUN步骤，不仅能提升缓存命中率，还能更精准地定位缓存失败的环节。
• 检查缓存仓库权限：确认Kaniko拥有缓存仓库的读写权限，确保该大型层的缓存已被正确上传至缓存仓库。

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