如何加速Google Cloud Platform上的Rails Docker部署？

Question

我正在尝试使用更具成本效益的方式来部署我的Rails应用程序,并通过Ruby Starter项目来了解Google Cloud Platform.

它几乎是完美的,而且在价格方面肯定具有竞争力,但部署速度非常慢.

当我从示例Bookshelf应用程序运行部署命令时:

$ gcloud preview app deploy app.yaml worker.yaml --promote

我可以gae-builder-vm在Compute Engine/VM Instances页面上看到一个新实例,我得到熟悉的Docker构建输出 - 这需要大约十分钟才能完成.

但是,如果我立即重新部署,我会得到一个新的gae-builder-vm旋转,它完成相同的十分钟构建过程,从第一次构建映像时没有明显的缓存.

在这两种情况下,第二个模块(worker.yaml)都会被缓存并且非常快速地进行:

Building and pushing image for module [worker]
---------------------------------------- DOCKER BUILD OUTPUT ----------------------------------------
Step 0 : FROM gcr.io/google_appengine/ruby
---> 3e8b286df835
Step 1 : RUN rbenv install -s 2.2.3 &&     rbenv global 2.2.3 &&     gem install -q --no-rdoc --no-ri bundler --version 1.10.6 &&     gem install -q --no-rdoc --no-ri foreman --version 0.78.0
---> Using cache
---> efdafde40bf8
Step 2 : ENV RBENV_VERSION 2.2.3
---> Using cache
---> 49534db5b7eb
Step 3 : COPY Gemfile Gemfile.lock /app/
---> Using cache
---> d8c2f1c5a44b
Step 4 : RUN bundle install && rbenv rehash
---> Using cache
---> d9f9b57ccbad
Step 5 : COPY . /app/
---> Using cache
---> 503904327f13
Step 6 : ENTRYPOINT bundle exec foreman start --formation "$FORMATION"
---> Using cache
---> af547f521411
Successfully built af547f521411

但是如果没有任何改变,那么在部署之间无法缓存这些版本对我没有意义.

理想情况下,如果我在专用构建服务器(可以记住构建之间的Docker镜像)上触发重建,我认为这会更快,然后更新公共图像文件并要求Google重新部署预构建的图像,这会更快.

这是由gcloud以下生成的Docker文件:

# This Dockerfile for a Ruby application was generated by gcloud with:
# gcloud preview app gen-config --custom

# The base Dockerfile installs:
# * A number of packages needed by the Ruby runtime and by gems
#   commonly used in Ruby web apps (such as libsqlite3)
# * A recent version of NodeJS
# * A recent version of the standard Ruby runtime to use by default
# * The bundler and foreman gems
FROM gcr.io/google_appengine/ruby

# Install ruby 2.2.3 if not already preinstalled by the base image
# base image: https://github.com/GoogleCloudPlatform/ruby-docker/blob/master/appengine/Dockerfile
# preinstalled ruby versions: 2.0.0-p647 2.1.7 2.2.3
RUN rbenv install -s 2.2.3 && \
    rbenv global 2.2.3 && \
    gem install -q --no-rdoc --no-ri bundler --version 1.10.6 && \
    gem install -q --no-rdoc --no-ri foreman --version 0.78.0
ENV RBENV_VERSION 2.2.3

# To install additional packages needed by your gems, uncomment
# the "RUN apt-get update" and "RUN apt-get install" lines below
# and specify your packages.
# RUN apt-get update
# RUN apt-get install -y -q (your packages here)

# Install required gems.
COPY Gemfile Gemfile.lock /app/
RUN bundle install && rbenv rehash

# Start application on port 8080.
COPY . /app/
ENTRYPOINT bundle exec foreman start --formation "$FORMATION"

如何更快地完成此过程？

Answer 1

好吧,你有点混淆了两种不同的情况:

• 重新部署完全相同的应用程序代码 - 事实上Google并没有检查应用程序是否有任何更改需要部署,在这种情况下整个docker镜像可以重新使用 - 但是你已经有了这个图像,实际上你没有'甚至需要重新部署.除非您怀疑出现了问题并且您确实坚持重新构建映像(并且部署实用程序正是如此).一个相当学术的案例,对实际应用程序部署的成本效益几乎没有影响:)
• 你正在部署一个不同的应用程序代码(无论多少不同) - 好吧,没有在图像构建过程中重新使用缓存的工件(根据你的构建日志发生) - 最终的图像仍然需要旨在整合新的应用程序代码 - 不可避免.重新使用以前构建的图像实际上是不可能的.

更新:我早些时候错过了你的观点,仔细看看你的两个日志我同意你的看法,缓存似乎是每个构建VM的本地缓存(只有在构建worker模块时缓存命中解释,每个在同一个VM上相应的default模块是事先构建的,因此不会在部署中重复使用.

另一个更新:可能有一种方法可以跨部署获取缓存命中...

该gcloud preview app deploy说明指出托管构建也使用集装箱生成器API(这似乎是做了默认设置!)除了临时VM:

要使用临时VM(使用默认的--docker-build = remote设置)而不是Container Builder API来执行docker构建,请运行:

$ gcloud config set app/use_cloud_build false

使用Container Builder API 完成的构建可能使用共享存储,这可能允许跨部署的缓存命中.恕我直言,值得一试.