Module: Google::Serverless::Exec::Tasks

Defined in:

lib/google/serverless/exec/tasks.rb

Overview

Rake Task for serverless exec

This module implements the serverless:exec rake task. To make it available, add the line

require "google/serverless/exec/tasks"

to your Rakefile. If your app uses Ruby on Rails, then the gem provides a railtie that adds this task automatically, so you don't have to do anything beyond adding the gem to your Gemfile.

Usage

The serverless:exec a given command in the context of a serverless application. See Google::Serverless::Exec for more information on this capability.

The command to be run may either be provided as a rake argument, or as command line arguments, delimited by two dashes --. (The dashes are needed to separate your command from rake arguments and flags.) For example, to run a production database migration, you can run either of the following equivalent commands:

bundle exec rake "serverless:exec[bundle exec bin/rails db:migrate]"
bundle exec rake serverless:exec -- bundle exec bin/rails db:migrate

To display usage instructions, provide two dashes but no command:

bundle exec rake serverless:exec --

Parameters

You may customize the behavior of the serverless execution through a few enviroment variable parameters. These are set via the normal mechanism at the end of a rake command line. For example, to set EXEC_APP_CONFIG:

bundle exec rake serverless:exec EXEC_APP_CONFIG=myservice.yaml -- bundle exec bin/rails db:migrate

Be sure to set these parameters before the double dash. Any arguments following the double dash are interpreted as part of the command itself.

The following environment variable parameters are supported:

EXEC_PROJECT

The ID of your Google Cloud project. If not specified, uses the current project from gcloud.

EXEC_PRODUCT

The product used to deploy the app. Valid values are app_engine or cloud_run. If omitted, the task will try to guess based on whether an App Engine config file (e.g. app.yaml) is present.

EXEC_REGION

The Google Cloud region to which the app is deployed. Required for Cloud Run apps.

EXEC_STRATEGY

The execution strategy to use. Valid values are deployment (which is the default for App Engine Standard apps) and cloud_build (which is the default for App Engine Flexible and Cloud Run apps).

Normally you should leave the strategy set to the default. The main reason to change it is if your app runs on the Flexible Environment and talks to a database over a VPC (using a private IP address). The cloud_build strategy used by default for Flexible apps cannot connect to a VPC, so you should use deployment in this case. (But note that, otherwise, the deployment strategy is significantly slower for apps on the App Engine Flexible Environment.)

EXEC_TIMEOUT

Amount of time to wait before serverless:exec terminates the command. Expressed as a string formatted like: 2h15m10s. Default is 10m.

EXEC_SERVICE_NAME

Name of the service to be used. If your app uses Cloud Run, this is required. If your app uses App Engine, normally the service name is obtained from the config file, but you can override it using this parameter.

EXEC_APP_CONFIG

Path to the App Engine config file, used when your app has multiple services, or the config file is otherwise not called ./app.yaml. The config file is used to determine the name of the App Engine service. Unused for Cloud Run apps.

EXEC_APP_VERSION

The version of the App Engine service, used to identify which application image to use to run your command. If not specified, uses the most recently created version, regardless of whether that version is actually serving traffic. Applies only to the cloud_build strategy for App Engine apps; ignored for the deployment strategy or if your app uses Cloud Run.

EXEC_BUILD_LOGS_DIR

GCS bucket name of the cloud build log when GAE_STRATEGY is cloud_build. (ex. gs://BUCKET-NAME/FOLDER-NAME)

EXEC_WRAPPER_IMAGE

The fully-qualified name of the wrapper image to use. (This is a Docker image that emulates the App Engine environment in Google Cloud Build for the cloud_build strategy, and applies only to that strategy.) Normally, you should not override this unless you are testing a new wrapper.