Question

我正在尝试使用更具成本效益的方式来部署我的Rails应用，并通过Ruby Starter Projects来了解Google云端平台。

它几乎完美，而且价格确实具有竞争力，但部署速度非常慢。

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

我可以在Compute Engine/VM Instances page上看到一个新的gae-builder-vm个实例，我得到the familiar Docker build output - 这需要大约十分钟才能完成。

如果我立即重新部署，我会通过the exact same ten-minute build process with no apparent caching from the first time the image was built获得新的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模块，每个模块位于预先构建相应default模块的同一VM上，因此不会在部署中重复使用。

另一个更新：可能是一种在部署中获取缓存命中的方法......

gcloud preview app deploy DESCRIPTION表示除了临时VM之外，还可以使用Container Builder API（看似默认设置！）来完成托管构建：

使用临时VM（使用默认的--docker-build = remote 设置），而不是Container Builder API来执行docker 构建，运行：
$ gcloud config set app/use_cloud_build false

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

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

1 个答案: