Как ускорить развертывание Rails Docker на Google Cloud Platform?

Я экспериментирую с более экономичными способами развертывания своих приложений Rails и прошел через Ruby Starter Projects, чтобы получить представление об Google Cloud Platform.

Это почти идеально и, безусловно, конкурентоспособно по цене, но развертывание происходит невероятно медленно.

Когда я запускаю команду развертывания из образца приложения Bookshelf:

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

Я вижу новый экземпляр gae-builder-vm на странице экземпляров Compute Engine/VM и получаю знакомый вывод сборки 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 переразвернуть с готовым образом, что будет быстрее. .

Вот файл Docker, созданный 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"

Как я могу ускорить этот процесс?


person cgenco    schedule 28.12.2015    source источник
comment
Вы нашли способ ускорить процесс? Мои развертывания в данный момент мучительно медленные   -  person sthomps    schedule 17.04.2016
comment
Нет, в итоге я использовал dokku на дешевых VPS-боксах. Его было проще настроить, чем GAE, и так же просто/быстро развернуть, как Heroku (просто git push, и виртуальная машина запоминает свои установленные драгоценные камни).   -  person cgenco    schedule 18.04.2016


Ответы (1)


Ну, вы как бы смешиваете 2 разных случая:

  • повторное развертывание точно такого же кода приложения — действительно, Google не проверяет, были ли какие-либо изменения в развертываемом приложении, и в этом случае можно повторно использовать весь образ докера — но у вас уже есть этот образ, по сути, вам даже не нужно повторно развертывать. Если только вы не подозреваете, что что-то пошло не так, и вы действительно настаиваете на пересборке образа (а именно это и делает утилита развертывания). Довольно академический случай, мало связанный с экономической эффективностью развертывания реальных приложений :)
  • вы развертываете другой код приложения (не имеет значения, насколько он отличается) — ну, за исключением повторного использования кэшированных артефактов во время сборки образа (что происходит, согласно вашим журналам сборки) — окончательное изображение все еще должно быть создано для включения нового кода приложения - неизбежно. Повторное использование ранее созданного образа на самом деле невозможно.

Обновление: я упустил вашу мысль ранее, при более внимательном рассмотрении обоих ваших журналов я согласен с вашим наблюдением, что кеш кажется локальным для каждой виртуальной машины сборки (объясняется попаданием в кеш только во время сборки worker модули, каждый на той же виртуальной машине, где соответствующий default модуль был создан заранее) и, таким образом, не используются повторно в развертываниях.

Еще одно обновление: может быть есть способ получить попадания в кеш в разных развертываниях...

В gcloud preview app deploy DESCRIPTION указано, что размещенная сборка также может быть выполнена с использованием API Container Builder (который является настройкой по умолчанию!) в дополнение к временной виртуальной машине:

Чтобы использовать временную виртуальную машину (с настройкой по умолчанию --docker-build=remote), а не API Container Builder для выполнения сборок докеров, запустите:

$ gcloud config set app/use_cloud_build false

Сборки, выполненные с помощью API Container Builder, могут использовать общий хранилище, которое может допускать попадания в кеш в разных развертываниях. ИМХО стоит попробовать.

person Dan Cornilescu    schedule 17.04.2016