ruby on rails - engine - ¿Cómo puedo acelerar las implementaciones de Rails Docker en Google Cloud Platform?

google app engine rails

Question

Estoy experimentando con formas más rentables para implementar mis aplicaciones de Rails, y pasé por Ruby Starter Projects para tener una idea de Google Cloud Platform.

Es casi perfecto, y ciertamente competitivo en precio, pero las implementaciones son increíblemente lentas.

Cuando ejecuto el comando de implementación desde la aplicación de Bookshelf de muestra :

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

Puedo ver una nueva instancia de gae-builder-vm en la página de instancias de Compute Engine / VM y obtengo el resultado de compilación de Docker , que demora aproximadamente diez minutos.

Sin embargo, si vuelvo a desplegar de inmediato, obtengo un nuevo spin up de gae-builder-vm que pasa por el mismo proceso de compilación de diez minutos sin caché aparente desde la primera vez que se construyó la imagen .

En ambos casos, el segundo módulo (worker.yaml) se almacena en caché y va muy rápido:

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

pero no tiene sentido para mí que estas versiones no se puedan almacenar en caché entre las implementaciones si nada ha cambiado.

Idealmente, creo que esto iría más rápido si activara una reconstrucción en un servidor de compilación dedicado (que podría recordar imágenes Docker entre compilaciones), que luego actualizó un archivo de imagen pública y le pidió a Google que volviera a desplegar con la imagen precompilada, que iría más rápido .

Aquí está el archivo Docker generado por 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"

¿Cómo puedo hacer que este proceso sea más rápido?

Answer 1

Bueno, estás mezclando un poco 2 casos diferentes:

• volver a implementar exactamente el mismo código de aplicación, de hecho, Google no verifica si hubo algún cambio en la aplicación que se implementará, en cuyo caso toda la imagen de la ventana acoplable podría volver a utilizarse, pero ya tienes esa imagen, efectivamente no lo haces incluso necesita volver a implementarse. A menos que sospeche que algo salió mal y realmente insiste en reconstruir la imagen (y la utilidad de despliegue hace exactamente eso). Un caso bastante académico con poca relación con la rentabilidad de las implementaciones de aplicaciones de la vida real :)
• está implementando un código de aplicación diferente (no importa qué tan diferente), bueno, si no se reutilizan los artefactos almacenados en caché durante la creación de la imagen (lo que sucede según los registros de construcción), la imagen final aún debe ser construido para incorporar el nuevo código de aplicación - inevitable. Reutilizar la imagen previamente construida no es realmente posible.

Actualización: omití su punto anterior, al examinar más de cerca sus registros, estoy de acuerdo con su observación de que el caché parece ser local para cada VM de compilación (explicado por los aciertos de caché solo durante la construcción de los módulos de worker , cada uno en la misma VM) donde el módulo default correspondiente se construyó de antemano) y, por lo tanto, no se volvió a utilizar en las implementaciones.

Otra actualización : puede haber una forma de obtener visitas de caché a través de implementaciones ...

La gcloud preview app deploy DESCRIPCIÓN indica que la compilación alojada también podría realizarse utilizando la API de contenedor de compilación (que parece ser la configuración predeterminada ) además de una VM temporal:

Para usar una VM temporal (con la configuración predeterminada --docker-build = remote), en lugar de la API de Container Builder para realizar construcciones de docker, ejecute:

$ gcloud config set app/use_cloud_build false

Las compilaciones realizadas con la API Container Builder pueden usar un almacenamiento compartido, lo que podría permitir visitas a caché en las implementaciones. En mi humilde opinión, vale la pena intentarlo.