Region ID
The REGION_ID
is an abbreviated code that Google assigns
based on the region you select when you create your app. The code does not
correspond to a country or province, even though some region IDs may appear
similar to commonly used country and province codes. Including
REGION_ID.r
in App Engine URLs is optional for
existing apps and will soon be required for all new apps.
To ensure a smooth transition, we are slowly updating App Engine to use region IDs. If we haven't updated your Google Cloud project yet, you won't see a region ID for your app. Since the ID is optional for existing apps, you don't need to update URLs or make other changes once the region ID is available for your existing apps.
Learn more about region IDs.
Learn how to run your application locally, deploy it, and test on App Engine.
Running locally
To test your application's functionality before deploying, run your application in your local environment with the development tools that you usually use.
Deploying your application
Deploy your application to App Engine using the
gcloud app deploy
command.
This command automatically builds a container image by using the
Cloud Build service and then deploys
that image to the App Engine flexible environment. The container
will include any local modifications that you've made to the runtime image.
To programmatically deploy your apps, use the Admin API.
Before you begin
Before you can deploy your application:
The Owner of the Cloud project must enable App Engine.
Ensure that your user account includes the required privileges.
Ensuring successful deployment
If you enable updated health checks, deployments are rolled back if your application does not reach healthy status.
When you deploy your first application to the flexible environment, there might
be a delay as your virtual machine (VM) and other infrastructure are set up.
After the initial setup, the health checks
make sure that your instance is healthy and ready to receive traffic. If
your application does not reach ready status in a
specified amount of time, indicated by the initial_delay_sec
field in the liveness_check
section of your app.yaml file,
then your deployment fails and is rolled back.
Your application might need more time to become ready. For example, you might
initialize your application by downloading large files or preloading caches. If
you are using
updated health checks,
then you can increase the amount of time by modifying the
app_start_timeout_sec
configuration setting in the readiness_check
section of
in your app.yaml
file.
If your deployment fails, make sure the Cloud Build API is enabled in your project. App Engine enables this API automatically the first time you deploy an app, but if someone has since disabled the API, deployments will fail.
Deploying a service
You deploy your application to App Engine by deploying versions of your application's services and each of their configuration files.
To deploy a version of your application's service, run the following command
from the directory where the app.yaml
file of your service is located:
gcloud app deploy
Specifying no files with the command deploys only the app.yaml
file in your
current directory. By default, the deploy
command generates a unique ID
for the version that you deploy, deploys the version to the
Cloud project you configured the gcloud
tool to use, and
routes all traffic to the new version.
You can change the default behavior of the command by targeting specific files or including additional parameters:
To deploy the other configuration files of your service, you must target and deploy each file separately. For example:
gcloud app deploy cron.yaml gcloud app deploy dispatch.yaml gcloud app deploy index.yaml
To specify a custom version ID, use the
--version
flag.To prevent traffic from being automatically routed to the new version, use the
--no-promote
flag.To deploy to a specific Cloud project, use the
--project
flag.
For example, to deploy the service defined by app.yaml
to a specific
Cloud project, assign it a custom version ID, and
prevent traffic from being routed to the new version:
gcloud app deploy --project PROJECT_ID --version VERSION_ID --no-promote
For more information about this command, see the
gcloud app deploy
reference.
Deploying multiple services
You use the same deployment command for deploying or updating the multiple services that make up your application.
To deploy multiple services, you must separately deploy each service's
app.yaml
file. For example:
gcloud app deploy service1/app.yaml
gcloud app deploy service2/app.yaml
You can specify multiple files with a single deploy command:
gcloud app deploy service1/app.yaml service2/app.yaml
Requirements for deploying multiple services
You must initially deploy a version of your application to the
default
service before you can create and deploy subsequent services.The ID of each of your services must be specified in their corresponding
app.yaml
configuration files. To specify the service ID, include theservice
element definition in each configuration file. By default, excluding this element definition from your configuration file deploys the version to thedefault
service.
Ignoring files
You can use a .gcloudignore
file to specify files and directories not to upload to Google Cloud
when you deploy your services. This is useful for ignoring build artifacts
and other files that do not need to be uploaded with your deployment.
Learn more about the syntax of the .gcloudignore
file in the
gcloud
reference.
Manually building a container for deployment
To build your container images outside of Google Cloud Platform, you must
first upload your images to a container image repository before you can deploy
your images to App Engine with the gcloud app deploy
command.
For example, if you build your container images locally with Docker, you can
push those images to Google Container
Registry and then
specify the URL of your image in the --image-url
flag of the command:
gcloud app deploy --image-url gcr.io/YOUR_PROJECT_ID/YOUR_CONTAINER_IMAGE
Using automated continuous deployment pipelines
You can use Cloud Build to automate deployments in continuous deployment pipelines. For more information, see Deploying artifacts, and Automating Builds using Build Triggers in the Cloud Build documentation.
Docker base images for PHP
If you'd like to build a PHP custom runtime application from scratch, use a provided base image in your Dockerfile:
Version | Docker command |
---|---|
PHP 5.6 | FROM gcr.io/google-appengine/php56 |
PHP 7.0 | FROM gcr.io/google-appengine/php70 |
PHP 7.1 | FROM gcr.io/google-appengine/php71 |
PHP 7.2 | FROM gcr.io/google-appengine/php72 |
PHP 7.3 | FROM gcr.io/google-appengine/php73 |
The source code of the base images are available at: https://github.com/GoogleCloudPlatform/php-docker
Viewing your application
After you deploy your application to App Engine, you can run the
following command to launch your browser and view it at
https://PROJECT_ID.REGION_ID.r.appspot.com
:
gcloud app browse
Testing on App Engine
Before configuring a new version to receive traffic, you can test it on
App Engine. For example, to test a new version of your
default
service:
Deploy your new version and include the
--no-promote
flag:gcloud app deploy --no-promote
Access your new version by navigating to the following URL:
https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
Now you can test your new version in the App Engine runtime environment. You can debug your application by viewing its logs in the Google Cloud Console Logs Viewer. For more information, see Writing Application Logs.
Requests sent to
https://PROJECT_ID.REGION_ID.r.appspot.com
will still be routed to the version previously configured to receive traffic.When you want to send traffic to the new version, use the Cloud Console to migrate traffic:
Select the version you just deployed and click Migrate traffic.
You can use the same process to test new versions of other services
by replacing default
in the URL with your service's name:
Troubleshooting
The following are common error messages that you might encounter when deploying apps:
PERMISSION_DENIED: Operation not allowed
The "appengine.applications.create" permission is required.
- If the Cloud project does not include the required
App Engine
application, the
gcloud app deploy
command can fail when it tries to run thegcloud app create
command. Only accounts with Owner role have the necessary permissions to create App Engine applications. 502 Bad Gateway
- The Cloud project can fail to start if the
app.yaml
is misconfigured. Check the app logs for more detailed error messages.