Эта страница переведена с помощью Cloud Translation API.

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

1. Обзор

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

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

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

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

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

Проект Google Cloud Platform с активным платежным аккаунтом GCP.
Базовые навыки Python
Знание основных команд Linux.
Базовые знания разработки и развертывания приложений App Engine.
Работающее приложение Cloud NDB Python 3 App Engine модуля 2.
Рекомендуется : завершить работу над кодом модуля 2, а также выполнить дополнительный этап переноса приложения с Python 2 на 3.

Опрос

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

Прочтите только до конца

Прочитайте его и выполните упражнения.

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

Новичок

Средний

Опытный

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

Новичок

Средний

Опытный

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

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

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

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

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

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

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

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

3. Настройка/Предварительная работа

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

1. Проект установки

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

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

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

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

НАЧАЛО: код модуля 2 (3.x [папка репозитория модуля 2b])
ОТДЕЛКА: код модуля 11 (3.x)
Весь репозиторий (для клонирования или загрузки ZIP)

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

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

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

Оставшиеся подготовительные шаги, которые необходимо выполнить сейчас:

Повторно ознакомьтесь с инструментом командной строки gcloud
Повторно разверните пример приложения с помощью gcloud app deploy
Убедитесь, что приложение работает на 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 , поэтому все необходимые изменения для перехода к облачным функциям происходят в этом файле.

Импорт

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

Поскольку веб-фреймворки не являются частью ландшафта облачных функций, импорт из 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.

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

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

Flask больше не используется после преобразования приложения в облачную функцию, поэтому удалите декораторы маршрутов.
Cloud Functions автоматически передает объект Flask Request в качестве параметра, поэтому создайте для него переменную. В нашем примере приложения мы назовем его request .
Развернутым облачным функциям необходимо дать имя. Наш основной обработчик в App Engine получил соответствующее имя root() чтобы описать, что это такое (корневой обработчик приложения). В качестве облачной функции использование этого имени не имеет смысла. Вместо этого мы развернем функцию Cloud с именем 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)

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

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

В то время как 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:

Как и в большинстве других кодовых лабораторий и видеороликов этой серии, базовая функциональность приложения не меняется. Цель состоит в том, чтобы применить один метод модернизации и заставить приложение работать точно так же, как и раньше, но на основе более новой инфраструктуры, например, миграция со старой устаревшей службы 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 нет функции «отключить». Сделайте резервную копию вашего кода и просто удалите функцию. Вы всегда можете повторно развернуть его с тем же именем позже. Однако, если вы не собираетесь продолжать работу с другими лабораториями по миграции и хотите полностью удалить все, закройте свои облачные проекты .

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

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

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

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

Модуль 2. Переход с App Engine ndb на Cloud NDB.
Модули 7–9 : переход от push-задач из очереди задач App Engine в облачные задачи.
Модули 12–13 : миграция с App Engine Memcache на Cloud Memorystore.
Модули 15–16 : миграция из App Engine Blobstore в облачное хранилище.
Модули 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

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

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

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

Кодлаб	Питон 3
Модуль 2	код
Модуль 11	код

Интернет-ресурсы

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

Механизм приложений

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

Другая информация об облаке

Python на облачной платформе Google
Клиентские библиотеки Google Cloud Python
Уровень Google Cloud «Всегда бесплатно»
Google Cloud SDK (инструмент командной строки gcloud )
Вся документация Google Cloud

Видео

Лицензия

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