Модуль 11. Миграция с Google App Engine на облачные функции

1. Обзор

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

Бывают ситуации, когда для использования ресурсов App Engine или Cloud Run не требуется «целое приложение». Если ваш код состоит только из микросервиса или простой функции, Cloud Functions, вероятно, подойдет лучше. В этом практическом занятии вы узнаете, как мигрировать простые приложения App Engine (или разбить более крупные приложения на несколько микросервисов) и развернуть их в Cloud Functions — еще одной бессерверной платформе, специально созданной для подобных случаев.

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

  • Используйте Cloud Shell
  • Включите API Google Cloud Translation
  • Аутентификация API-запросов
  • Преобразуйте небольшое приложение App Engine для работы в Cloud Functions.
  • Разверните свой код в Cloud Functions

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

Опрос

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

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

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

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

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

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

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

Системы PaaS, такие как Google App Engine и Cloud Functions, предоставляют пользователям множество удобств. Эти бессерверные платформы позволяют вашей технической команде сосредоточиться на создании бизнес-решений, а не тратить время на изучение подходящих платформ и определение необходимого количества оборудования. Приложения могут автоматически масштабироваться по мере необходимости, масштабироваться до нуля с оплатой по факту использования для контроля затрат, и они поддерживают множество распространенных сегодня языков программирования.

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

Cloud Functions предназначен для развертывания небольшого фрагмента кода, который:

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

Вы также можете использовать Cloud Functions для разделения большого монолитного приложения на множество микросервисов, каждый из которых использует общую базу данных, такую ​​как Cloud Firestore или Cloud SQL . А если вы хотите, чтобы ваша функция или микросервис были контейнеризированы и выполнялись бессерверно в Cloud Run, вы тоже можете это сделать.

Наш пример приложения App Engine, который фигурирует почти во всех руководствах по миграции, представляет собой короткое приложение с базовой функциональностью, которое так же хорошо работает в Cloud Functions. В этом руководстве вы узнаете, как модифицировать это приложение для работы в Cloud Functions. С точки зрения App Engine, поскольку функции проще, чем целые приложения, ваш опыт начала работы должен быть проще (и быстрее), и в целом с меньшими «накладными расходами». Эта миграция включает следующие шаги:

  • Подготовка/Настройка
  • Удалите файлы конфигурации
  • Изменяйте файлы приложения.

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

Этот практический урок начинается с версии приложения Cloud NDB App Engine из модуля 2, использующей Python 3, поскольку Cloud Functions не поддерживает Python 2. Сначала давайте настроим наш проект, получим код, а затем развернем базовое приложение, чтобы убедиться, что мы начинаем с работающего кода.

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

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

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

Одно из предварительных условий для выполнения этого практического задания — наличие работающего примера приложения из Модуля 2. Если у вас его нет, пройдите один из уроков, ссылки на которые приведены выше, прежде чем переходить к следующему шагу. В противном случае, если вы уже знакомы с содержанием Модуля 2, вы можете начать с загрузки кода Модуля 2, представленного ниже.

Независимо от того, используете ли вы свой или наш код, мы НАЧНЕМ с кода Python 3 из модуля 2. Этот практический урок по модулю 11 шаг за шагом проведет вас через весь процесс и завершится кодом, похожим на тот, что находится в папке репозитория модуля 11 (КОНЕЦ).

Структура каталога файлов модуля 2 Python 3 (ваших или наших) должна выглядеть следующим образом:

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

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

Осталось выполнить следующие подготовительные шаги:

  1. Вспомните, как работает инструмент командной строки gcloud
  2. Повторно разверните демонстрационное приложение с помощью gcloud app deploy
  3. Убедитесь, что приложение работает в App Engine без проблем.

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

4. Удалите файлы конфигурации.

Файл app.yaml — это артефакт App Engine, не используемый с Cloud Functions, поэтому удалите его сейчас . Если вы этого не сделаете или забудете, ничего страшного не произойдет, поскольку Cloud Functions его не использует. Это единственное изменение конфигурации, так как requirements.txt останется идентичным тому, что был в Модуле 2.

Если вы также переносите приложение App Engine, разработанное на Python 2, на Python 3, удалите файл appengine_config.py и папку lib , если она у вас есть. Это артефакты App Engine, не используемые в среде выполнения Python 3.

5. Измените файлы приложения.

Приложение состоит всего из одного файла — main.py , поэтому все необходимые изменения для перехода на Cloud Functions вносятся в этот файл.

Импорт

Поскольку мы работаем только с функциями, нет необходимости в веб-фреймворке. Однако для удобства при вызове облачных функций на основе Python им автоматически передается объект запроса, который ваш код может использовать по мере необходимости. (Команда Cloud Functions выбрала в качестве объекта запроса Flask объект, передаваемый в вашу функцию.)

Поскольку веб-фреймворки не входят в состав Cloud Functions, импорт из Flask невозможен, если ваше приложение не использует другие функции Flask. В нашем случае это именно так, поскольку рендеринг шаблона всё ещё происходит после преобразования в функцию, а это значит, что вызов flask.render_template() всё ещё необходим, поэтому он импортируется из Flask. Отсутствие веб-фреймворка означает отсутствие необходимости создавать экземпляр приложения Flask, поэтому удалите app = Flask(__name__) . Ваш код выглядит следующим образом до и после внесения изменений:

ДО:

from flask import Flask, render_template, request
from google.cloud import ndb

app = Flask(__name__)
ds_client = ndb.Client()

ПОСЛЕ:

from flask import render_template
from google.cloud import ndb

ds_client = ndb.Client()

Если вы зависите от объекта приложения ( app ) или любой другой инфраструктуры веб-фреймворка, вам необходимо разрешить все эти зависимости, найти подходящие обходные пути, полностью отказаться от их использования или использовать прокси-объекты. Только тогда вы сможете преобразовать свой код в облачную функцию. В противном случае вам лучше остаться на App Engine или контейнеризировать ваше приложение для Cloud Run.

Обновить сигнатуру функции основного обработчика

В сигнатуру функции необходимо внести следующие изменения:

  1. После преобразования приложения в облачную функцию Flask больше не используется, поэтому удалите декораторы маршрутов.
  2. Cloud Functions автоматически передает объект Flask Request в качестве параметра, поэтому создайте для него переменную. В нашем примере приложения мы назовем ее request .
  3. Развернутые облачные функции должны быть именованы. Наш основной обработчик в App Engine был назван root() , что точно описывало его назначение (корневой обработчик приложения). В случае с облачной функцией использовать это имя менее целесообразно. Вместо этого мы развернем облачную функцию с именем visitme , поэтому используйте это имя и для функции Python. Аналогично, в модулях 4 и 5 мы также назвали службу Cloud Run visitme .

Вот фотографии «до» и «после» с учетом этих изменений:

ДО:

@app.route('/')
def root():
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

ПОСЛЕ:

def visitme(request):
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

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

668f30e3865b27a9.png

Локальная разработка и тестирование

В то время как App Engine использует локальный сервер разработки dev_appserver.py , Cloud Functions имеет собственную платформу Functions Framework . С помощью этой платформы вы можете разрабатывать и тестировать локально. Ваш код может быть развернут в Cloud Functions, а также на других вычислительных платформах, таких как Compute Engine , Cloud Run или даже в локальных или гибридных облачных системах, поддерживающих Knative . Дополнительные ссылки на Functions Framework приведены ниже.

6. Сборка и развертывание

Развертывание в Cloud Functions немного отличается от App Engine. Поскольку файлы конфигурации, кроме requirements.txt , не используются, дополнительную информацию о коде необходимо указать в командной строке. Разверните свою новую облачную функцию, запускаемую по HTTP и работающую под управлением Python 3.10, с помощью этой команды:

$ gcloud functions deploy visitme --runtime python310 --trigger-http --allow-unauthenticated

Ожидаемый результат должен быть примерно следующим:

Deploying function (may take a while - up to 2 minutes)...⠛
For Cloud Build Logs, visit: https://console.cloud.google.com/cloud-build/builds;region=REGION/f5f6fc81-1bb3-4cdb-8bfe?project=PROJECT_ID
Deploying function (may take a while - up to 2 minutes)...done.
availableMemoryMb: 256
buildId: f5f6fc81-1bb3-4cdb-8bfe
buildName: projects/PROJECT_ID/locations/REGION/builds/f5f6fc81-1bb3-4cdb-8bfe
dockerRegistry: CONTAINER_REGISTRY
entryPoint: visitme
httpsTrigger:
  securityLevel: SECURE_OPTIONAL
  url: https://REGION-PROJECT_ID.cloudfunctions.net/visitme
ingressSettings: ALLOW_ALL
labels:
  deployment-tool: cli-gcloud
name: projects/PROJECT_ID/locations/REGION/functions/visitme
runtime: python310
serviceAccountEmail: PROJECT_ID@appspot.gserviceaccount.com
sourceUploadUrl: https://storage.googleapis.com/uploads-853031211983.REGION.cloudfunctions.appspot.com/8c923758-cee8-47ce-8e97-5720a5301c34.zip
status: ACTIVE
timeout: 60s
updateTime: '2022-05-16T18:28:06.153Z'
versionId: '8'

После развертывания вашей функции используйте URL-адрес из выходных данных развертывания и посетите ваше приложение. URL-адрес имеет вид: REGION-PROJECT_ID.cloudfunctions.net/visitme . Результат должен быть идентичен тому, что вы видели при предыдущем развертывании в App Engine:

2732ae9218f011a2.png

Как и в большинстве других практических заданий и видеороликов этой серии, базовая функциональность приложения не меняется. Цель состоит в том, чтобы применить один из методов модернизации и заставить приложение работать точно так же, как и раньше, но на базе более современной инфраструктуры, например, мигрировать со старого сервиса App Engine на его замену — автономный облачный продукт, или, как в этом руководстве, перенести приложение на другую бессерверную платформу Google Cloud.

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

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

Уборка

После завершения этого практического занятия вы можете временно или навсегда отключить приложение App Engine из модуля 2, чтобы избежать оплаты. Платформа App Engine имеет бесплатную квоту , поэтому с вас не будет взиматься плата, пока вы остаетесь в рамках установленного тарифного плана. То же самое относится и к Datastore; подробности см. на странице цен Cloud Datastore .

Развертывание на таких платформах, как App Engine и Cloud Functions, влечет за собой незначительные затраты на сборку и хранение данных . В некоторых регионах Cloud Build и Cloud Storage имеют собственную бесплатную квоту. Часть этой квоты расходуется на сборку. Следите за использованием хранилища, чтобы минимизировать потенциальные затраты, особенно если в вашем регионе нет такого бесплатного уровня.

К сожалению, в Cloud Functions нет функции «отключения». Сделайте резервную копию кода и просто удалите функцию. Вы всегда сможете повторно развернуть её с тем же именем позже. Однако, если вы не собираетесь продолжать работу с другими руководствами по миграции и хотите полностью удалить всё, закройте свои проекты в Cloud .

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

Помимо этого руководства, стоит также рассмотреть другие модули миграции, например, контейнеризацию вашего приложения App Engine для Cloud Run. Ссылки на примеры кода для модулей 4 и 5 приведены ниже:

  • Модуль 4 : Миграция в облако. Запуск с помощью Docker.
  • Создайте контейнер для запуска вашего приложения в Cloud Run с помощью Docker.
  • Эта миграция позволит вам остаться на Python 2.
  • Модуль 5 : Миграция в облако с использованием Cloud Buildpacks
  • Создайте контейнер для запуска вашего приложения в Cloud Run с помощью Cloud Buildpacks.
  • Вам не нужно ничего знать о Docker, контейнерах или Dockerfile .
  • Для корректной работы требуется, чтобы ваше приложение уже было переведено на Python 3 (Buildpacks не поддерживает Python 2).

Многие другие модули посвящены тому, как показать разработчикам, как перейти от встроенных сервисов App Engine к автономным облачным решениям:

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

Если контейнеризация стала частью вашего рабочего процесса разработки приложений, особенно если он включает в себя конвейер CI/CD (непрерывная интеграция/непрерывная доставка или развертывание), рассмотрите возможность миграции на Cloud Run вместо Cloud Functions. См. Модуль 4 , чтобы контейнеризировать ваше приложение с помощью Docker, или Модуль 5, чтобы сделать это без контейнеров, знаний Docker или Dockerfile . Независимо от того, рассматриваете ли вы Cloud Functions или Cloud Run, переход на другую бессерверную платформу является необязательным, и мы рекомендуем рассмотреть наилучшие варианты для ваших приложений и сценариев использования, прежде чем вносить какие-либо изменения.

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

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

Проблемы/обратная связь по модулю миграции App Engine на Codelabs

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

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

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

Кодлаб

Python 3

Модуль 2

код

Модуль 11

код

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

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

App Engine

Облачные функции

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

Видео

Лицензия

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