我发现了两种可能的解决方案，使用外部数据卷进行gem存储：one和two。
简单地说

• 指定一个仅用于存储gem的图像
• 在 app 镜像中，在docker-compose.yml中，您通过volumes_from指定BUNDLE_PATH的挂载点。
• 当你的应用容器启动时，它会执行bundle check || bundle install，一切就绪。

这是一个可能的解决方案，但对我来说，它似乎有点违背Docker的方式。具体来说，bundle install听起来应该是构建过程的一部分，而不应该是运行时的一部分。其他依赖于bundle install（如asset:precompile）的任务现在也是运行时任务。
这是一个可行的解决方案，但我期待着一些更强大的东西。

我将gem缓存到应用程序tmp目录中的tar文件中。然后，在安装bundle之前，我使用ADD命令将gem复制到一个层中。关于Dockerfile.yml：

WORKDIR /home/app

# restore the gem cache. This only runs when
# gemcache.tar.bz2 changes, so usually it takes
# no time
ADD tmp/gemcache.tar.bz2 /var/lib/gems/

COPY Gemfile /home/app/Gemfile
COPY Gemfile.lock /home/app/Gemfile.lock
RUN gem update --system && \
gem update bundler && \
bundle install --jobs 4 --retry 5

确保你正在将gem缓存发送到你的docker机器。我的gemcache是118MB，但由于我是在本地构建的，所以它复制得很快。我的.dockerignore：

tmp
!tmp/gemcache.tar.bz2

您需要缓存构建映像中的gem，但最初可能没有映像。像这样创建一个空缓存（我在一个rake任务中有这个）：

task :clear_cache do
  sh "tar -jcf tmp/gemcache.tar.bz2 -T /dev/null"
end

镜像构建完成后，将gem复制到gem缓存中。我的图片被标记为app。我从镜像创建了一个docker容器，使用docker cp命令将/var/lib/gems/2.2.0复制到我的gemcache中，然后删除容器。下面是我的rake任务：

task :cache_gems do
  id = `docker create app`.strip
  begin
    sh "docker cp #{id}:/var/lib/gems/2.2.0/ - | bzip2 > tmp/gemcache.tar.bz2"
  ensure
    sh "docker rm -v #{id}"
  end
end

在随后的图像构建中，gemcache被复制到调用bundle install之前的层。这需要一些时间，但它比从头开始的bundle install快。
之后的构建甚至更快，因为docker已经缓存了ADD tmp/gemcache.tar.bz2 /var/lib/gems/层。如果对Gemfile.lock有任何更改，则仅构建这些更改。
没有理由在每个Gemfile.lock更改时重建gem缓存。一旦该高速缓存和Gemfile.lock之间存在足够的差异，bundle install很慢，您就可以重建gem缓存。当我想重建gem缓存时，它是一个简单的rake cache_gems命令。

“复制本地依赖项”方法（接受的答案）是一个坏主意IMO。将你的环境对接的全部意义在于拥有一个隔离的、可复制的环境。
我们是这样做的。

# .docker/docker-compose.dev.yml
version: '3.7'
services:

  web:
    build: .
    command: 'bash -c "wait-for-it cache:1337 && bin/rails server"'
    depends_on:
      - cache
    volumes:
      - cache:/bundle
    environment:
      BUNDLE_PATH: '/bundle'

  cache:
    build:
      context: ../
      dockerfile: .docker/cache.Dockerfile
    volumes:
      - bundle:/bundle
    environment:
      BUNDLE_PATH: '/bundle'
    ports:
      - "1337:1337"

volumes:
  cache:

# .docker/cache.Dockerfile
FROM ruby:2.6.3
RUN apt-get update -qq && apt-get install -y netcat-openbsd
COPY Gemfile* ./
COPY .docker/cache-entrypoint.sh ./
RUN chmod +x cache-entrypoint.sh
ENTRYPOINT ./cache-entrypoint.sh

# .docker/cache-entrypoint.sh
#!/bin/bash

bundle check || bundle install
nc -l -k -p 1337

# web.dev.Dockerfile
FROM ruby:2.6.3
RUN apt-get update -qq && apt-get install -y nodejs wait-for-it
WORKDIR ${GITHUB_WORKSPACE:-/app}
# Note: bundle install step removed
COPY . ./

这与@EightyEight解释的概念类似，但它不会将bundle install放入主服务的启动中，而是由不同的服务管理更新。无论哪种方式，都不要在生产中使用这种方法。如果在构建步骤中没有安装依赖项的情况下运行服务，至少会导致不必要的停机时间。

这个问题很老了，但我最近遇到了这个问题。我正在做一个项目，它有几个依赖项和原生扩展，这使得每当Gemfile中发生更改时，构建一个新的docker镜像需要大约15分钟。
我并不是真的想用外部卷将依赖项安装推迟到运行步骤，所以我做了更多的研究，经过一些尝试和错误，我设法让捆绑包缓存在构建过程中工作。
我所做的是使用以下代码将缓存挂载添加到我的Dockerfile：

...
COPY Gemfile Gemfile.lock $app
RUN --mount=type=cache,target=/bundler \
    BUNDLE_PATH=/bundler bundle install --jobs 3 --verbose && \
    cp -r /bundler/ruby/3.2.0/* /usr/local/bundle
...

(Note路径可能会有所不同，具体取决于您使用的ruby版本）
我想在提交其他答案时，这可能不是一个受支持的docker功能。
希望这能帮助那些努力让bundler与docker cache合作的人！