Перенос приложения Python 2 в облако NDB & Приложение Cloud Tasks для Python 3 и Cloud Datastore (модуль 9)

1. Обзор

Серия обучающих материалов Serverless Migration Station (самостоятельные практические уроки) и сопутствующих видеороликов призвана помочь разработчикам бессерверных приложений Google Cloud модернизировать свои приложения, проведя их через одну или несколько миграций, в первую очередь, через отказ от устаревших сервисов. Это делает ваши приложения более портативными, предоставляет больше возможностей и гибкости, позволяя интегрироваться с более широким спектром облачных продуктов и получать к ним доступ, а также упрощает обновление до более новых версий языков программирования. Хотя изначально серия ориентирована на самых первых пользователей облачных сервисов, в первую очередь разработчиков App Engine (стандартная среда), она достаточно широка, чтобы охватить и другие бессерверные платформы, такие как Cloud Functions и Cloud Run , или другие, если это применимо.

Цель данной практической работы — перенести пример приложения из модуля 8 на Python 3, а также переключить доступ к хранилищу данных (Cloud Firestore в режиме Datastore) с использования Cloud NDB на собственную клиентскую библиотеку Cloud Datastore и обновить клиентскую библиотеку Cloud Tasks до последней версии.

В модуле 7 мы добавили использование очереди задач для задач с отложенной отправкой , а в модуле 8 перенесли это использование в облачные задачи. В модуле 9 мы продолжаем работу с Python 3 и облачным хранилищем данных. Тем, кто использует очереди задач для задач с отложенной отправкой , следует перейти к облачной системе публикации/подписки и обратиться к модулям 18-19.

Вы узнаете, как

  • Перенесите пример приложения из модуля 8 на Python 3.
  • Переключите доступ к хранилищу данных с Cloud NDB на клиентские библиотеки Cloud Datastore.
  • Обновите библиотеку клиента Cloud Tasks до последней версии.

Что вам понадобится

Опрос

Как вы будете использовать этот учебный материал?

Прочитайте только до конца. Прочитайте текст и выполните упражнения.

Как бы вы оценили свой опыт работы с Python?

Новичок Средний Профессионал

Как бы вы оценили свой опыт использования сервисов Google Cloud?

Новичок Средний Профессионал

2. Предыстория

В модуле 7 показано, как использовать задачи с отправкой из очереди задач App Engine в приложениях Flask App Engine на Python 2. В модуле 8 вы переведете это приложение с очереди задач на Cloud Tasks. Здесь, в модуле 9 , вы продолжите этот процесс и перенесете приложение на Python 3, а также переключите доступ к хранилищу данных с использования Cloud NDB на собственную клиентскую библиотеку Cloud Datastore .

Поскольку Cloud NDB работает как с Python 2, так и с Python 3, он подходит для пользователей App Engine, переносящих свои приложения с Python 2 на 3. Дополнительная миграция клиентских библиотек в Cloud Datastore совершенно необязательна , и есть только одна причина ее рассмотреть: у вас уже есть приложения, не работающие на App Engine (и/или приложения App Engine на Python 3), использующие клиентскую библиотеку Cloud Datastore, и вы хотите объединить свой код, чтобы обращаться к Datastore с помощью всего одной клиентской библиотеки. Cloud NDB был создан специально для разработчиков App Engine на Python 2 в качестве инструмента миграции на Python 3, поэтому, если у вас еще нет кода, использующего клиентскую библиотеку Cloud Datastore, вам не нужно рассматривать эту миграцию.

Наконец, разработка клиентской библиотеки Cloud Tasks продолжается только на Python 3, поэтому мы «переходим» с одной из последних версий Python 2 на её аналог на Python 3. К счастью, никаких критических изменений по сравнению с Python 2 нет, а это значит, что вам больше ничего делать не нужно.

В этом руководстве описаны следующие шаги:

  1. Подготовка/Настройка
  2. Обновить конфигурацию
  3. Измените код приложения

3. Подготовка/Предварительные работы

В этом разделе объясняется, как:

  1. Настройте свой облачный проект
  2. Получите базовый образец приложения
  3. (Повторное) развертывание и проверка базового приложения.

Эти шаги гарантируют, что вы начинаете с работающего кода и что он готов к миграции в облачные сервисы.

1. Настройка проекта

Если вы выполнили практическое задание модуля 8 , используйте тот же проект (и код). В качестве альтернативы создайте совершенно новый проект или используйте существующий. Убедитесь, что у проекта есть активный платежный аккаунт и включенное приложение App Engine. Найдите идентификатор своего проекта, так как он понадобится вам во время выполнения этого практического задания, используя его всякий раз, когда вы встретите переменную PROJECT_ID .

2. Получите базовый образец приложения.

Одно из необходимых условий — наличие работающего приложения App Engine модуля 8: выполните практическое задание по модулю 8 (рекомендуется) или скопируйте приложение модуля 8 из репозитория. Независимо от того, используете ли вы свой или наш код, мы начнем с кода модуля 8 ("НАЧАЛО"). Это практическое задание проведет вас через процесс миграции и завершится кодом, похожим на тот, что находится в папке репозитория модуля 9 ("ЗАВЕРШЕНИЕ").

Независимо от того, какое приложение из Модуля 7 вы используете, папка должна выглядеть примерно так, как показано ниже, возможно, с дополнительной папкой lib :

$ ls
README.md               appengine_config.py     requirements.txt
app.yaml                main.py                 templates

3. (Повторное) развертывание и проверка базового приложения.

Для развертывания приложения «Модуль 8» выполните следующие действия:

  1. Удалите папку lib , если она есть, и выполните команду pip install -t lib -r requirements.txt , чтобы заново заполнить lib . Возможно, вам потребуется использовать pip2 если на вашей машине для разработки установлены Python 2 и 3.
  2. Убедитесь, что вы установили и инициализировали инструмент командной строки gcloud и ознакомились с его использованием .
  3. (необязательно) Укажите свой облачный проект с помощью gcloud config set project PROJECT_ID если вы не хотите вводить PROJECT_ID при каждой команде gcloud .
  4. Разверните демонстрационное приложение с помощью gcloud app deploy
  5. Убедитесь, что приложение работает должным образом и без проблем. Если вы выполнили практическое задание модуля 8, приложение отображает самых активных посетителей, а также самые последние посещения (иллюстрация ниже). Внизу отображается информация о более старых задачах, которые будут удалены.

4aa8a2cb5f527079.png

4. Обновите конфигурацию

requirements.txt

Новый файл requirements.txt практически идентичен файлу для модуля 8, с одним существенным изменением: замените google-cloud-ndb на google-cloud-datastore . Внесите это изменение, чтобы ваш файл requirements.txt выглядел следующим образом:

flask
google-cloud-datastore
google-cloud-tasks

В файле requirements.txt отсутствуют номера версий, что означает выбор последних версий. В случае возникновения несовместимостей использование номеров версий для фиксации рабочих версий приложения является стандартной практикой.

app.yaml

Вторая версия среды выполнения App Engine не поддерживает встроенные сторонние библиотеки, как в версии 2.x, а также не поддерживает копирование библиотек, не являющихся встроенными . Единственное требование для сторонних пакетов — указать их в файле requirements.txt . В результате весь раздел libraries в app.yaml можно удалить.

Ещё одно обновление заключается в том, что среда выполнения Python 3 требует использования веб-фреймворков, которые выполняют собственную маршрутизацию. В результате все обработчики скриптов должны быть изменены на auto . Однако, поскольку все маршруты должны быть изменены на auto , и в этом примере приложения не обслуживаются статические файлы, наличие каких-либо обработчиков не имеет значения, поэтому удалите весь раздел handlers .

В app.yaml нужно всего лишь указать поддерживаемую версию Python 3, например, 3.10. Внесите это изменение, чтобы новый, сокращенный файл app.yaml состоял всего из одной строки:

runtime: python310

Удалите файлы appengine_config.py и lib.

Среды выполнения App Engine нового поколения кардинально меняют подход к использованию сторонних пакетов:

  • Встроенные библиотеки — это те, которые прошли проверку Google и доступны на серверах App Engine, вероятно, потому что они содержат код на C/C++, который разработчикам не разрешено развертывать в облаке — в средах выполнения второго поколения они больше недоступны.
  • Копирование не встроенных библиотек (иногда называемое «внедрением» или «самостоятельной сборкой») больше не требуется во средах выполнения второго поколения. Вместо этого их следует указывать в файле requirements.txt , где система сборки автоматически установит их от вашего имени во время развертывания.

В результате этих изменений в управлении сторонними пакетами файл appengine_config.py и папка lib больше не нужны, поэтому удалите их. Во втором поколении сред выполнения App Engine автоматически устанавливает сторонние пакеты, перечисленные в requirements.txt . В итоге:

  1. Не используйте самостоятельно собранные или скопированные сторонние библиотеки; перечислите их в requirements.txt
  2. pip install в папку lib запрещена, то есть папка lib вообще не существует.
  3. В app.yaml не должно быть списка встроенных сторонних библиотек (следовательно, отсутствует раздел libraries "); их следует перечислить в requirements.txt
  4. Отсутствие ссылок на сторонние библиотеки в вашем приложении означает отсутствие файла appengine_config.py

Единственное требование к разработчику — указать в файле requirements.txt список всех необходимых сторонних библиотек.

5. Обновите файлы приложения.

Существует только один файл приложения, main.py , поэтому все изменения в этом разделе затрагивают только этот файл. Ниже приведена иллюстрация "различий", показывающая общие изменения, которые необходимо внести для рефакторинга существующего кода в новое приложение. Читателям не нужно читать код построчно, поскольку его цель — просто получить наглядное представление о том, что требуется для этого рефакторинга (но вы можете открыть его в новой вкладке или скачать и увеличить масштаб, если хотите).

5d043768ba7be742.png

Обновление импорта и инициализации

В разделе импорта main.py для модуля 8 используются Cloud NDB и Cloud Tasks; он должен выглядеть следующим образом:

ДО:

from datetime import datetime
import json
import logging
import time
from flask import Flask, render_template, request
import google.auth
from google.cloud import ndb, tasks

app = Flask(__name__)
ds_client = ndb.Client()
ts_client = tasks.CloudTasksClient()

В средах выполнения второго поколения, таких как Python 3, упрощена и улучшена система логирования:

  • Для получения всесторонних данных о логах используйте Cloud Logging .
  • Для простого логирования отправляйте данные в stdout (или stderr ) с помощью print()
  • Нет необходимости использовать модуль logging Python (поэтому удалите его).

Таким образом, удалите импорт logging и замените google.cloud.ndb на google.cloud.datastore . Аналогично, измените ds_client так, чтобы он указывал на клиент Datastore вместо клиента NDB. После внесения этих изменений верхняя часть вашего нового приложения будет выглядеть следующим образом:

ПОСЛЕ:

from datetime import datetime
import json
import time
from flask import Flask, render_template, request
import google.auth
from google.cloud import datastore, tasks

app = Flask(__name__)
ds_client = datastore.Client()
ts_client = tasks.CloudTasksClient()

Миграция в облачное хранилище данных

Теперь пришло время заменить использование клиентской библиотеки NDB на Datastore. И App Engine NDB, и Cloud NDB требуют наличия модели данных (класса); для этого приложения это Visit . Функция store_visit() работает одинаково во всех остальных модулях миграции: она регистрирует посещение, создавая новую запись Visit , сохраняя IP-адрес посетителя и пользовательский агент (тип браузера).

ДО:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    with ds_client.context():
        Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

Однако Cloud Datastore не использует класс модели данных, поэтому удалите этот класс. Кроме того, Cloud Datastore не создает метку времени автоматически при создании записей, поэтому вам придется делать это вручную — это делается с помощью вызова datetime.now() .

Без класса данных ваша измененная store_visit() должна выглядеть следующим образом:

ПОСЛЕ:

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    entity = datastore.Entity(key=ds_client.key('Visit'))
    entity.update({
        'timestamp': datetime.now(),
        'visitor': '{}: {}'.format(remote_addr, user_agent),
    })
    ds_client.put(entity)

Ключевая функция — fetch_visits() . Она не только выполняет исходный запрос для получения последних Visit , но и получает метку времени последнего отображаемого Visit и создает задачу push, которая вызывает /trim (следовательно, trim() ) для массового удаления старых Visit . Вот как это выглядит с использованием Cloud NDB:

ДО:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    with ds_client.context():
        data = Visit.query().order(-Visit.timestamp).fetch(limit)
    oldest = time.mktime(data[-1].timestamp.timetuple())
    oldest_str = time.ctime(oldest)
    logging.info('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    ts_client.create_task(parent=QUEUE_PATH, task=task)
    return (v.to_dict() for v in data), oldest_str

Основные изменения:

  1. Замените запрос Cloud NDB на аналогичный запрос Cloud Datastore; стили запросов немного отличаются.
  2. Datastore не требует использования менеджера контекста и не заставляет вас извлекать его данные (с помощью to_dict() ), как это делает Cloud NDB.
  3. Замените вызовы функции логирования на print()

После этих изменений fetch_visits() выглядит следующим образом:

ПОСЛЕ:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    query = ds_client.query(kind='Visit')
    query.order = ['-timestamp']
    visits = list(query.fetch(limit=limit))
    oldest = time.mktime(visits[-1]['timestamp'].timetuple())
    oldest_str = time.ctime(oldest)
    print('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

Обычно этого было бы достаточно. К сожалению, есть одна серьезная проблема.

(Возможно) Создать новую (push) очередь

В модуле 7 мы добавили использование taskqueue App Engine в существующее приложение из модуля 1. Одним из ключевых преимуществ наличия push-запросов как устаревшей функции App Engine является автоматическое создание «очереди по умолчанию». Когда это приложение было перенесено в Cloud Tasks в модуле 8, эта очередь по умолчанию уже существовала, поэтому нам не нужно было беспокоиться о ней. В модуле 9 это меняется.

Один из важнейших аспектов, который следует учитывать, заключается в том, что новое приложение App Engine больше не использует сервисы App Engine, и, следовательно, нельзя предполагать, что App Engine автоматически создает очередь задач в другом продукте (Cloud Tasks). В текущем виде создание задачи в функции fetch_visits() (для несуществующей очереди) завершится ошибкой. Необходима новая функция для проверки существования очереди ("default") и, если она отсутствует, для ее создания.

Вызовите эту функцию _create_queue_if() и добавьте её в ваше приложение непосредственно перед fetch_visits() поскольку именно там она вызывается. Тело добавляемой функции: 

def _create_queue_if():
    'app-internal function creating default queue if it does not exist'
    try:
        ts_client.get_queue(name=QUEUE_PATH)
    except Exception as e:
        if 'does not exist' in str(e):
            ts_client.create_queue(parent=PATH_PREFIX,
                    queue={'name': QUEUE_PATH})
    return True

Функция create_queue() в Cloud Tasks требует указания полного пути к очереди, за исключением имени очереди. Для простоты создайте еще одну переменную PATH_PREFIX представляющую QUEUE_PATH за вычетом имени очереди ( QUEUE_PATH.rsplit('/', 2)[0] ). Добавьте ее определение ближе к началу, чтобы блок кода со всеми присваиваниями констант выглядел следующим образом: 

_, PROJECT_ID = google.auth.default()
REGION_ID = 'REGION_ID'    # replace w/your own
QUEUE_NAME = 'default'     # replace w/your own
QUEUE_PATH = ts_client.queue_path(PROJECT_ID, REGION_ID, QUEUE_NAME)
PATH_PREFIX = QUEUE_PATH.rsplit('/', 2)[0]

Теперь измените последнюю строку в fetch_visits() , чтобы использовать _create_queue_if() , сначала создавая очередь, если это необходимо, а затем создавая задачу: 

    if _create_queue_if():
        ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

Теперь _create_queue_if() и fetch_visits() в совокупности должны выглядеть следующим образом: 

def _create_queue_if():
    'app-internal function creating default queue if it does not exist'
    try:
        ts_client.get_queue(name=QUEUE_PATH)
    except Exception as e:
        if 'does not exist' in str(e):
            ts_client.create_queue(parent=PATH_PREFIX,
                    queue={'name': QUEUE_PATH})
    return True

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    query = ds_client.query(kind='Visit')
    query.order = ['-timestamp']
    visits = list(query.fetch(limit=limit))
    oldest = time.mktime(visits[-1]['timestamp'].timetuple())
    oldest_str = time.ctime(oldest)
    print('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    if _create_queue_if():
        ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

За исключением необходимости добавления этого дополнительного кода, остальная часть кода Cloud Tasks в основном осталась неизменной по сравнению с модулем 8. Последний фрагмент кода, который следует рассмотреть, — это обработчик задач.

Обработчик задач обновления (отправки)

В обработчике задач trim() код Cloud NDB запрашивает посещения старше самого старого из отображаемых. Он использует запрос только по ключам для ускорения процесса — зачем получать все данные, если нужны только идентификаторы посещений? После получения всех идентификаторов посещений удалите их все одновременно с помощью функции delete_multi() Cloud NDB.

ДО: 

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = float(request.get_json().get('oldest'))
    with ds_client.context():
        keys = Visit.query(
                Visit.timestamp < datetime.fromtimestamp(oldest)
        ).fetch(keys_only=True)
        nkeys = len(keys)
        if nkeys:
            logging.info('Deleting %d entities: %s' % (
                    nkeys, ', '.join(str(k.id()) for k in keys)))
            ndb.delete_multi(keys)
        else:
            logging.info(
                    'No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

Как и в случае с fetch_visits() , основная часть изменений заключается в замене кода Cloud NDB на Cloud Datastore, корректировке стилей запросов, отказе от использования его контекстного менеджера и изменении вызовов логирования на print() .

ПОСЛЕ: 

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = float(request.get_json().get('oldest'))
    query = ds_client.query(kind='Visit')
    query.add_filter('timestamp', '<', datetime.fromtimestamp(oldest))
    query.keys_only()
    keys = list(visit.key for visit in query.fetch())
    nkeys = len(keys)
    if nkeys:
        print('Deleting %d entities: %s' % (
                nkeys, ', '.join(str(k.id) for k in keys)))
        ds_client.delete_multi(keys)
    else:
        print('No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

В основном обработчике приложения root() изменений нет.

Перенос на Python 3

Данное демонстрационное приложение разработано для работы как с Python 2, так и с Python 3. Все изменения, специфичные для Python 3, были рассмотрены ранее в соответствующих разделах этого руководства. Никаких дополнительных шагов или библиотек совместимости не требуется.

Обновление облачных задач

Финальная версия клиентской библиотеки Cloud Tasks, поддерживающая Python 2, — 1.5.0. На момент написания этой статьи последняя версия клиентской библиотеки для Python 3 полностью совместима с этой версией, поэтому никаких дальнейших обновлений не требуется.

обновление HTML-шаблона

В файле HTML-шаблона templates/index.html также не требуется никаких изменений, поэтому на этом завершается внесение всех необходимых изменений для создания приложения Module 9.

6. Подведение итогов/Завершение

Разверните и проверьте приложение.

После завершения обновления кода, в основном переноса на Python 3, разверните приложение с помощью gcloud app deploy . Результат должен быть идентичен приложениям из модулей 7 и 8, за исключением того, что вы перенесли доступ к базе данных в клиентскую библиотеку Cloud Datastore и обновили Python до версии 3.

Модуль 7, приложение visitme

Этот шаг завершает выполнение задания в рамках Codelab. Предлагаем вам сравнить свой код с кодом из папки Module 9. Поздравляем!

Уборка

Общий

Если на этом пока всё, мы рекомендуем отключить ваше приложение App Engine, чтобы избежать дополнительных расходов. Однако, если вы хотите продолжить тестирование или эксперименты, платформа App Engine предоставляет бесплатную квоту , поэтому, пока вы не превысите этот лимит, с вас не должны взиматься дополнительные платежи. Это касается вычислительных ресурсов, но за соответствующие услуги App Engine также может взиматься плата, поэтому проверьте страницу с ценами для получения более подробной информации. Если эта миграция включает другие облачные сервисы, они оплачиваются отдельно. В любом случае, если применимо, см. раздел «Информация, относящаяся к этому практическому занятию» ниже.

Для полной ясности, развертывание на бессерверной вычислительной платформе Google Cloud, такой как App Engine, влечет за собой незначительные затраты на сборку и хранение . Cloud Build и Cloud Storage имеют собственную бесплатную квоту. Хранение образа использует часть этой квоты. Однако вы можете проживать в регионе, где нет такого бесплатного уровня, поэтому следите за использованием хранилища, чтобы минимизировать потенциальные затраты. К числу конкретных «папок» Cloud Storage, которые следует проверить, относятся:

  • console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
  • console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
  • Приведенные выше ссылки на хранилища зависят от вашего PROJECT_ID и * LOC *, например, " us ", если ваше приложение размещено в США.

С другой стороны, если вы не собираетесь продолжать работу над этим приложением или другими связанными с миграцией кодовыми руководствами и хотите полностью удалить все, закройте свой проект .

Это относится именно к данному практическому занятию.

Перечисленные ниже услуги являются уникальными для данной учебной лаборатории. Для получения более подробной информации обратитесь к документации по каждому продукту:

Следующие шаги

На этом завершается наша миграция с задач, отправляемых через очередь задач App Engine, на задачи Cloud Tasks. Дополнительная миграция с Cloud NDB на Cloud Datastore также рассматривается отдельно (без очереди задач или задач Cloud Tasks) в Модуле 3. Помимо Модуля 3, существуют и другие модули миграции, посвященные отказу от устаревших встроенных сервисов App Engine, которые стоит рассмотреть, в том числе:

  • Модуль 2 : миграция с App Engine NDB на Cloud NDB
  • Модуль 3 : миграция с Cloud NDB на Cloud Datastore
  • Модули 12-13 : миграция с App Engine Memcache на Cloud Memorystore.
  • Модули 15-16 : миграция с App Engine Blobstore на Cloud Storage.
  • Модули 18-19 : Очередь задач App Engine (запросы на добавление/отправку) в Cloud Pub/Sub

App Engine больше не является единственной бессерверной платформой в Google Cloud. Если у вас небольшое приложение App Engine или приложение с ограниченной функциональностью, которое вы хотите превратить в автономный микросервис, или вы хотите разбить монолитное приложение на несколько многократно используемых компонентов, это веские причины для перехода на Cloud Functions . Если контейнеризация стала частью вашего рабочего процесса разработки приложений, особенно если он включает в себя конвейер CI/CD (непрерывная интеграция/непрерывная доставка или развертывание), рассмотрите возможность миграции на Cloud Run . Эти сценарии рассматриваются в следующих модулях:

  • Переход с App Engine на Cloud Functions: см. Модуль 11
  • Переход с App Engine на Cloud Run: см. Модуль 4 , чтобы контейнеризировать ваше приложение с помощью Docker, или Модуль 5 , чтобы сделать это без контейнеров, знаний Docker или файлов Dockerfile .

Переход на другую бессерверную платформу необязателен, и мы рекомендуем рассмотреть оптимальные варианты для ваших приложений и сценариев использования, прежде чем вносить какие-либо изменения.

Независимо от того, какой модуль миграции вы выберете следующим, весь контент Serverless Migration Station (практические занятия, видео, исходный код [при наличии]) доступен в его репозитории с открытым исходным кодом . README репозитория также содержится информация о том, какие миграции следует рассмотреть и в каком порядке следует выбирать модули миграции.

7. Дополнительные ресурсы

Вопросы/отзывы о Codelabs

Если вы обнаружите какие-либо проблемы в этом практическом задании, пожалуйста, сначала найдите свою проблему, прежде чем сообщать о ней. Ссылки для поиска и создания новых проблем:

Миграционные ресурсы

Ссылки на папки репозитория для Модуля 8 (НАЧАЛО) и Модуля 9 (ЗАВЕРШЕНИЕ) можно найти в таблице ниже. К ним также можно получить доступ из репозитория для всех миграций кода App Engine, которые можно клонировать или загрузить в виде ZIP-файла.

Кодлаб

Python 2

Python 3

Модуль 8

код

(н/д)

Модуль 9

(н/д)

код

Онлайн-ресурсы

Ниже приведены онлайн-ресурсы, которые могут быть полезны для данного урока:

App Engine

Облачный NDB

Облачное хранилище данных

Облачные задачи

Прочая информация об облачных сервисах

Лицензия

Данная работа распространяется под лицензией Creative Commons Attribution 2.0 Generic.