问捆绑安装和纱线安装中的入口脚本-码头

EN

它浪费了几分钟的时间，每次启动应用程序都会耗尽网络带宽。在进行本地开发时，这相当于每次运行应用程序时都要这样做：

rm -rf vendor node_modules
bundle install              # from scratch
yarn install                # from scratch
bundle exec rails s

Docker的核心部分是重建图像(就像Go、Java、类型记录等语言有一个“构建”阶段一样)。试图避免图像重建通常是不可取的。对于编写良好的Dockerfile，特别是对于解释语言，运行docker build应该是相当有效的。

一个重要的技巧是分别复制指定依赖项的文件和应用程序的其余部分。一旦Dockerfile COPY指令遇到一个已更改的文件，它将禁用应用程序其余部分的层缓存。由于依赖项更改的频率相对较低，如果依赖文件没有更改，那么先复制依赖文件，然后安装依赖项，然后复制应用程序的序列可以直接跳转到最后一步。

COPY Gemfile Gemfile.lock ./
RUN bundle install

COPY package.json yarn.lock ./
RUN yarn install

COPY . ./

(确保将邦德勒vendor目录和node_modules目录包含在.dockerignore文件中，以便最后一个COPY步骤不会覆盖以前安装的内容。)

这个问题是基于意见的。正如您自己已经发现的，在映像构建过程中安装依赖项(包、纱、其他)是一种常见的做法，而不是图像运行过程。

其基本原理是，您run的次数比build多，并且您希望运行操作能够快速启动。

就像在构建阶段执行apt install...或yum install...一样，通常也应该在构建阶段执行bundle install。

也就是说，如果bundle install作为入口点的一部分对您有意义的话，那就是您的选择。我怀疑在你做完这件事之后，你会发现它不那么常见是有原因的。

关于停靠层的另一个注意事项:如果Gemfile更改，不仅引用它的层会改变，而且所有后续的层也会改变。因此，通常将依赖项清单(Gemfile.*)的副本与应用程序的复制分开，如下所示：

# Pre-install gems
COPY Gemfile* ./
RUN gem install bundler && \
    bundle install --jobs=3 --retry=3 

# Copy the rest of the app
COPY . .

这样，如果您的应用程序文件更改，而不是依赖项，构建将更快。