如何加快在 Google Cloud Platform 上的 Rails Docker 部署? [英] How can I speed up Rails Docker deployments on Google Cloud Platform?

问题描述

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

I'm experimenting with more cost effective ways to deploy my Rails apps, and went through the Ruby Starter Projects to get a feel for Google Cloud Platform.

它几乎完美，而且在价格上肯定具有竞争力，但部署速度非常慢.

It's almost perfect, and certainly competitive on price, but the deployments are incredibly slow.

当我从示例书架应用运行部署命令时:

When I run the deployment command from the sample Bookshelf app:

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

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

I can see a new gae-builder-vm instance on the Compute Engine/VM Instances page and I get the familiar Docker build output - this takes about ten minutes to finish.

如果我立即重新部署，我会得到一个新的 gae-builder-vm，它会通过 与第一次构建映像时完全相同的十分钟构建过程，没有明显的缓存.

If I immediately redeploy, though, I get a new gae-builder-vm spun up that goes through the exact same ten-minute build process with no apparent caching from the first time the image was built.

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

In both cases, the second module (worker.yaml) gets cached and goes really quickly:

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

但如果没有任何变化，这些版本无法在部署之间缓存，这对我来说没有任何意义.

but it doesn't make sense to me that these versions couldn't be cached between deployments if nothing has changed.

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

Ideally I'm thinking this would go faster if I triggered a rebuild on a dedicated build server (which could remember Docker images between builds), which then updated a public image file and asked Google to redeploy with the prebuilt image, which would go faster.

这是 gcloud 生成的 Docker 文件:

Here's the Docker file that was generated by gcloud:

# 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"

我怎样才能使这个过程更快?

How can I make this process faster?

推荐答案

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

Well, you're kinda mixing up 2 different cases:

• 重新部署完全相同应用程序代码 - 实际上，Google 不会检查要部署的应用程序是否有任何变化，在这种情况下，可以重新使用整个 docker 映像 - 但是您已经拥有该图像，实际上您甚至不需要重新部署.除非您怀疑出了什么问题，并且您真的坚持要重新构建映像(而部署实用程序正是这样做的).一个相当学术的案例，对实际应用部署的成本效益几乎没有影响:)
• 您正在部署 不同 应用程序代码(无论有多大不同) - 好吧，在构建映像期间没有重用缓存的工件(根据您的构建会发生这种情况)日志) - 最终图像仍然需要构建以包含新的应用程序代码 - 不可避免.重新使用之前构建的图像是不可能的.

• re-deploying the exact same app code - indeed Google doesn't check if there was any change in the app to be deployed in which case the entire docker image could be re-used - but you already have that image, effectively you don't even need to re-deploy. Unless you suspect something went wrong and you really insist on re-building the image (and the deployment utility does exactly that). A rather academic case with little bearing to cost-effectiveness of real-life app deployments :)
• you're deploying a different app code (doesn't matter how much different) - well, short of re-using the cached artifacts during the image building (which happens, according to your build logs) - the final image still needs to be built to incorporate the new app code - unavoidable. Re-using the previously built image is not really possible.

更新:我之前错过了你的观点，在仔细查看你的两个日志后，我同意你的观察，缓存似乎是每个构建 VM 的本地(解释为缓存命中仅在构建 worker 模块，每个模块都在相同的 VM 上，相应的 default 模块是预先构建的)，因此不会在部署中重复使用.

Update: I missed your point earlier, upon a closer look at both your logs I agree with your observation that the cache seems to be local to each build VM (explained by the cache hits only during building the worker modules, each on the same VM where the corresponding default module was built beforehand) and thus not re-used across deployments.

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

Another Update: there might be a way to get cache hits across deployments...

gcloud preview app deploy 描述 表示除了临时 VM 之外，还可以使用 Container Builder API(这似乎是默认设置！)来完成托管构建:

The gcloud preview app deploy DESCRIPTION indicates that the hosted build could also be done using the Container Builder API (which appears to be the default setting!) in addition to a temporary VM:

使用临时虚拟机(使用默认 --docker-build=remote设置)，而不是 Container Builder API 来执行 docker构建，运行:

To use a temporary VM (with the default --docker-build=remote setting), rather than the Container Builder API to perform docker builds, run:

$ gcloud config set app/use_cloud_build false

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

Builds done using the Container Builder API might use a shared storage, which might allow cache hits across deployments. IMHO it's worth a try.

这篇关于如何加快在 Google Cloud Platform 上的 Rails Docker 部署?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！