Migrate off of legacy bundled services

Most of the functionality provided by the legacy bundled services is now provided by the Cloud Client Libraries. For more information, see the recommended alternatives listed below.

If migrating to an unbundled solution is not an option for your project, then you may be able to continue using legacy bundled services in your Python 3 apps as a fallback. This approach gives you flexibility to move to unbundled services later in the migration cycle.

After you migrate off of legacy bundled services, you can continue using App Engine or migrate to Cloud Run. Cloud Run is designed to improve upon the App Engine experience, and incorporates many of the best features of both the standard environment and the flexible environment. To compare features and understand how to migrate, see the App Engine and Cloud Run comparison guide.

Google Cloud provides standalone products that offer similar functionality as some of the bundled services in the Python 2 runtime. For the bundled services that are not available as separate products in Google Cloud, such as image processing, search, and messaging, this guide recommends third-party providers or other workarounds.

This page introduces the migration path for each bundled service.

Understanding Google Cloud permissions

Since your migrated app and the Google Cloud services that it uses are no longer running in the same "sandboxed" environment, your app needs authorization to access each service. For example, to interact with Firestore in Datastore mode (Datastore) or Cloud Tasks, your app needs to supply the credentials of an account that is authorized to access those services.

By default apps in the App Engine standard runtime supply the credentials of the App Engine default service account, which is authorized to access databases in the same project as the app.

If any of the following conditions are true, you need to use an alternative authentication technique that explicitly provides credentials:

  • Your app and the Memorystore database are in different Google Cloud projects.

  • You have changed the roles assigned to the default App Engine service account.

For information about alternative authentication techniques, see Setting up Authentication for Server to Server Production Applications.

Authentication for local development

To develop or test your app locally, we recommend creating and using a service account. Do not use the App Engine default service account, since it has a high level of permissions for everything in your project. Instead, create and use a service account with the lowest level of permissions you need for your specific development and testing task.

For instructions on setting up a service account and connecting it to your app, see Obtaining and providing service account credentials manually.

Installing client libraries

The easiest way to use Google Cloud services from a Python app is to install the service's Python client library. Google Cloud services also provide JSON REST and other interfaces. The steps for installing the client libraries into the App Engine runtime are different for Python 2 apps and Python 3 apps.

Installing libraries for Python 2 apps

To install a library for your app to use when it's running in the Python 2 runtime:

  1. Create a directory to store your third-party libraries, such as lib/.

  2. Create a requirements.txt file in the same folder as your app.yaml file and add the name of a client library.

    For example, the following file can be used to install libraries for Pub/Sub and Cloud Tasks:

    google-cloud-pubsub
    google-cloud-tasks
    
  3. Use pip install to install the libraries into the folder that you created. For example:

    pip install -t lib -r requirements.txt
  4. In your app's app.yaml file, specify the required Google RPC and setuptools libraries, and the optional SSL library in the libraries section:

    libraries:
    - name: grpcio
      version: 1.0.0
    - name: setuptools
      version: 36.6.0
    - name: ssl
      version: latest
    

    Some client libraries don't need the SSL library. If you don't include the SSL library for a client library that needs it, you'll see an SSL error in the Logs Explorer when youf app receives a request.

  5. Create an appengine_config.py file in the same folder as your app.yaml file if you do not already have one. Add the following to your appengine_config.py file:

    # appengine_config.py
    import pkg_resources
    from google.appengine.ext import vendor
    
    # Set path to your libraries folder.
    path = 'lib'
    # Add libraries installed in the path folder.
    vendor.add(path)
    # Add libraries to pkg_resources working set to find the distribution.
    pkg_resources.working_set.add_entry(path)

    Be sure to use thepkg_resources module, which ensures that your app uses the right distribution of the client libraries.

    The appengine_config.py file in the preceding example assumes that the the lib folder is located in the current working directory. If you can't guarantee that lib will always be in the current working directory, specify the full path to the lib folder. For example:

    import os
    path = os.path.join(os.path.dirname(os.path.realpath(__file__)), 'lib')
  6. Deploy the app.

App Engine uploads all of the libraries in the directory you specified in the appengine_config.py file to the Python 2 runtime.

Installing libraries for Python 3 apps

To install a library for your app to use when it's running in the Python 3 runtime:

  1. Add the library name your app's requirements.txt file. For example:

    google-cloud-ndb
    
  2. Deploy the app.

App Engine automatically uploads all libraries listed in the requirements.txt file to the Python 3 runtime.

Migration paths for App Engine bundled services

Blobstore

To store and retrieve data, use Cloud Storage through the Cloud Client Libraries. To get started, see Using Cloud Storage and Migrate from Blobstore to Cloud Storage guide. To simulate this migration, add Blobstore usage to a sample app and migrate to Cloud Storage.

Datastore

If your Python 2 app uses NDB to interact with Datastore, migrate to the Cloud NDB library. Cloud NDB is meant primarily as a transition tool for migrating Python 2 apps. We recommend that Python 3 apps use the Datastore mode client library.

For details, see Migrating to Cloud NDB. To simulate this migration with a sample app, see Migrating from App Engine ndb to Cloud NDB.

Images

You can serve images from Cloud Storage, serve them directly, or use a third-party content delivery network (CDN).

To resize, convert, and manipulate images, use an image processing library such as Pillow or a Python interface for ImageMagick.

To use one of these third-party libraries, add the library as a dependency and update your code to call the library's APIs.

The App Engine Images service also provided functionality to avoid dynamic requests to your application by handling image resizing using a serving URL. If you want similar functionality, you can generate the re-sized images ahead of time and upload them to Cloud Storage for serving. Alternatively, you could use a third-party content delivery network (CDN) service that offers image resizing.

Logging

We recommend that you update your app to use Cloud Logging, which supports features such as viewing logs in the Logs Explorer, downloading logs, filtering messages by severity, and correlating app messages with specific requests. Alternatively, if you prefer simplicity over data accuracy, you can write structured logs to stdout or stderr. For more information, see Writing and viewing logs and Migrating to Cloud Logging.

Mail

To send email, use a third-party mail provider such as SendGrid, Mailgun, or Mailjet. All of these services offer APIs to send emails from applications. A recommended third-party alternative for inbound messaging is not available at this time.

Memcache

To cache application data, use Memorystore for Redis.

For details, see Migrate Memcache to Memorystore. To simulate this migration, add Memcache usage to a sample app and migrate to Memorystore for Redis.

For apps that use Memcache only to reduce latency for NDB (or Cloud NDB) requests, use Cloud NDB's built-in support for Redis instead of Memcache or Memorystore for Redis.

Modules

To obtain information and modify your application's running services, use a combination of environment variables and the App Engine Admin API:

Service information How to access
Current application ID GAE_APPLICATION environment variable
Current project ID GOOGLE_CLOUD_PROJECT environment variable
Current service name GAE_SERVICE environment variable
Current service version GAE_VERSION environment variable
Current instance ID GAE_INSTANCE environment variable
Default hostname Admin API apps.get method
List of services Admin API apps.services.list method
List of versions for a service Admin API apps.services.versions.list method
Default version for a service, including any traffic splits Admin API apps.services.get method
List of running instances for a version Admin API apps.services.versions.instances.list method

For more information about the data available about your application's running services, see Python 3 runtime environment.

Namespaces

The Namespaces API enables multitenant apps to partition data across tenants simply by specifying a unique namespace string for each tenant.

While Datastore supports multitenancy directly, other Google Cloud services do not. If your multitenant app uses other Google Cloud services, you will need to handle multitenancy manually. To have completely isolated instances of services, you can create new projects programmatically using the Cloud Resource Manager API and access resources across projects.

OAuth

Instead of using the App Engine OAuth service to verify OAuth 2.0 tokens, use the oauth2.tokeninfo method of the OAuth 2.0 API.

Host any full-text search database such as Elasticsearch on Compute Engine and access it from your service.

Task queue

The App Engine Task Queue service is available in two different modes. Migrating away from either points towards two different standalone Cloud products.

Push tasks

Instead of App Engine Task Queue push tasks service for asynchronous code execution, use Cloud Tasks client libraries with a Python 3 standard environment endpoint as the target. For more information, see Migrating push queues to Cloud Tasks.

To simulate this migration with a sample app, see How to use App Engine push queues in Flask apps and migrating to Cloud Tasks.

Pull tasks

If you use the Task Queue pull tasks service, for example, queuing up tasks or messages to be processed by separate workers, Cloud Pub/Sub can be a good alternative. It it offers similar functionality and delivery guarantees. Like other Cloud services, Pub/Sub provides convenient client libraries to access the service. For more information, see Writing and responding to Pub/Sub messages and Task Queue pull tasks to Pub/Sub migration guide.

To simulate this migration with a sample app, see How to use App Engine pull tasks usage to a sample app and migrating to Pub/Sub.

URL Fetch

By default, the Python 2.7 runtime uses the URL Fetch service to handle outbound HTTP(S) requests, even if you use standard Python libraries to issue those requests.

If your app uses URL Fetch APIs directly, for example to make asynchronous requests, we recommend migrating to a standard Python library such as the Requests library.

For more information, see Migrating Outbound Requests.

User authentication

For an alternative to the Users API, use any of the HTTP-based authentication mechanisms described on the User authentication page.