Миграция с Memcache App Engine на Cloud Memorystore (модуль 13)

1. Обзор

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

Цель этой лаборатории кода — показать разработчикам App Engine Python 2, как перейти с Memcache App Engine на Cloud Memorystore (для Redis ). Существует также неявная миграция из App Engine ndb в Cloud NDB , но она в основном рассматривается в лаборатории кода Модуля 2 ; проверьте это для получения дополнительной пошаговой информации.

Не используете Memcache?

Если ваше приложение не использует Memcache App Engine, вы можете пропустить эту лабораторную работу или выполнить ее в качестве упражнения, чтобы ознакомиться с переходом на Cloud Memorystore .

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

• Настройте экземпляр Cloud Memorystore (из Cloud Console или инструмента gcloud ).
• Настройте соединитель Cloud Serverless VPC Access (из Cloud Console или инструмента gcloud ).
• Миграция с Memcache App Engine на Cloud Memorystore
• Реализуйте кеширование с помощью Cloud Memorystore в примере приложения.
• Миграция с App Engine ndb на Cloud NDB

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

• Проект Google Cloud с активной платежной учетной записью (это не бесплатная лаборатория кода).
• Базовые навыки Python
• Знание основных команд Linux.
• Базовые знания разработки и развертывания приложений App Engine.
• Рабочее приложение App Engine Модуля 12 (завершите кодовую лабораторию Модуля 12 [рекомендуется] или скопируйте приложение Модуля 12 из репозитория).

Опрос

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

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

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

Новичок Средний Опытный

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

Новичок Средний Опытный

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

В этой лаборатории кода показано, как перенести пример приложения из Memcache App Engine (и NDB) в Cloud Memorystore (и Cloud NDB). Этот процесс включает в себя замену зависимостей от встроенных служб App Engine, что делает ваши приложения более переносимыми. Вы можете либо остаться на App Engine, либо рассмотреть возможность перехода на любой из альтернатив, описанных ранее.

Эта миграция требует больше усилий по сравнению с другими в этой серии. Рекомендуемой заменой App Engine Memcache является Cloud Memorystore , полностью управляемый облачный сервис кэширования. Memorystore поддерживает пару популярных механизмов кэширования с открытым исходным кодом: Redis и Memcached . Этот модуль миграции использует Cloud Memorystore для Redis . Подробнее вы можете узнать в обзоре Memorystore и Redis .

Поскольку для Memorystore требуется работающий сервер, также необходим Cloud VPC . В частности, необходимо создать соединитель бессерверного доступа к VPC , чтобы приложение App Engine могло подключаться к экземпляру Memorystore через его частный IP-адрес. Выполнив это упражнение, вы обновите приложение, и, хотя оно будет работать как прежде, Cloud Memorystore будет службой кэширования, заменяющей службу Memcache App Engine.

Это руководство начинается с примера приложения Модуля 12 на Python 2, за которым следует дополнительное, необязательное, незначительное обновление до Python 3. Если вы уже знакомы с доступом к встроенным службам App Engine из Python 3 через Python 3 App Engine SDK , вы можете вместо этого начните с версии Python 3 примера приложения Модуля 12 . Это повлечет за собой прекращение использования SDK, поскольку Memorystore не входит в состав службы App Engine. Изучение использования SDK Python 3 App Engine выходит за рамки этого руководства.

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

1. Настройка/предварительная работа
2. Настройка служб кэширования
3. Обновить файлы конфигурации
4. Обновить основное приложение

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

Подготовить облачный проект

Мы рекомендуем повторно использовать тот же проект, который вы использовали для выполнения лабораторной работы по Модулю 12 . Альтернативно вы можете создать новый проект или повторно использовать другой существующий проект. Каждая лаборатория кода в этой серии имеет «СТАРТ» (базовый код, с которого нужно начать) и «ФИНИШ» (перенесенное приложение). Предоставляется код FINISH, чтобы вы могли сравнить свои решения с нашими в случае возникновения проблем. Вы всегда можете вернуться к START, если что-то пойдет не так. Эти контрольные точки предназначены для того, чтобы гарантировать, что вы успешно научитесь выполнять миграцию.

Какой бы облачный проект вы ни использовали, убедитесь, что у него есть активный платежный аккаунт . Также убедитесь, что App Engine включен . Просмотрите и убедитесь, что вы понимаете общие затраты, связанные с выполнением этих руководств. Однако, в отличие от других в этой серии, в этой лаборатории кода используются облачные ресурсы, у которых нет уровня бесплатного пользования , поэтому для выполнения упражнения потребуются некоторые затраты. Будет предоставлена ​​более конкретная информация о стоимости вместе с рекомендациями по сокращению использования, включая инструкции в конце по освобождению ресурсов для минимизации расходов по выставлению счетов.

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

Эта лаборатория кода шаг за шагом проведет вас через базовый код Модуля 12, с которого мы НАЧИНАЕМ. По завершении вы получите работающее приложение Модуля 13, очень похожее на код в одной из папок FINISH. Вот эти ресурсы:

• НАЧАЛО: Модуль 12. Приложение Python 2 ( mod12 ) или Python 3 ( mod12b ).
• ЗАВЕРШЕНИЕ: Модуль 13. Приложение Python 2 ( mod13a ) или Python 3 ( mod13b ).
• Весь репозиторий миграции (клонировать или загрузить ZIP)

В папке START должны находиться следующие файлы:

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

Если вы начинаете с версии Python 2, там также будет файл appengine_config.py и, возможно, папка lib , если вы завершили лабораторную работу по модулю 12.

(Повторное) развертывание приложения модуля 12

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

1. Повторно ознакомьтесь с инструментом командной строки gcloud (при необходимости).
2. (Повторно) разверните код Модуля 12 в App Engine (при необходимости).

Пользователи Python 2 должны удалить и переустановить папку lib с помощью следующих команд:

rm -rf ./lib; pip install -t lib -r requirements.txt                

Теперь каждый (пользователь Python 2 и 3) должен загрузить код в App Engine с помощью этой команды:

gcloud app deploy                

После успешного развертывания убедитесь, что приложение выглядит и функционирует так же, как приложение из Модуля 12 — веб-приложение, которое отслеживает посещения и кэширует их для одного и того же пользователя в течение часа:

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

4. Настройте службы кэширования

Cloud Memorystore не является бессерверным. Требуется экземпляр; в данном случае запущен Redis. В отличие от Memcache, Memorystore является автономным облачным продуктом и не имеет уровня бесплатного пользования , поэтому обязательно проверьте информацию о ценах на Memorystore для Redis, прежде чем продолжить. Чтобы минимизировать затраты на это упражнение, мы рекомендуем использовать минимальное количество ресурсов: уровень обслуживания «Базовый» и емкость 1 ГБ .

Экземпляр Memorystore находится в другой сети, чем ваше приложение (экземпляры) App Engine, поэтому необходимо создать соединитель бессерверного доступа к VPC , чтобы App Engine мог получить доступ к вашим ресурсам Memorystore. Чтобы минимизировать затраты на VPC, выберите тип инстанса ( f1-micro ) и наименьшее количество запрашиваемых инстансов (мы предлагаем минимум 2 , максимум 3 ). Также посетите страницу с информацией о ценах на VPC .

Стоимость: этот урок НЕ бесплатен.

Хотя большинство работ по миграции из этой серии можно выполнить бесплатно, этот является исключением. Ни у Cloud Memorystore, ни у Cloud VPC нет уровня бесплатного пользования, поэтому вы не можете продолжить работу, не взимая при этом некоторые счета. Мы настоятельно рекомендуем вам просмотреть информацию о ценах на оба продукта, прежде чем продолжить. Если вы чувствительны к затратам, но хотите продолжить, мы рекомендуем использовать самые дешевые варианты. Чтобы свести затраты к минимуму, немедленно освободите эти ресурсы после завершения работы над кодом.

Мы повторяем эти рекомендации по сокращению затрат по мере создания каждого необходимого ресурса. Кроме того, когда вы создаете ресурсы Memorystore и VPC в Cloud Console, вы увидите калькулятор цен для каждого продукта в правом верхнем углу, который предоставит вам ежемесячную оценку затрат (см. иллюстрацию ниже). Эти значения автоматически корректируются, если вы измените свои параметры. Это примерно то, что вы должны ожидать увидеть:

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

Как только оба ресурса будут подключены к сети, вы добавите соответствующую информацию в app.yaml , чтобы ваше приложение могло получить доступ к кешу. Вы также можете обратиться к руководствам по Python 2 или Python 3 в официальной документации. Также стоит обратиться к руководству по кэшированию данных на странице миграции Cloud NDB ( Python 2 или Python 3 ).

Создайте все ресурсы в регионе App Engine.

Ниже вы создадите все дополнительные облачные ресурсы, необходимые для использования Cloud Memorystore в качестве службы кэширования вашего приложения App Engine. Прежде чем сделать это, учтите, что вам необходимо создать экземпляр Memorystore и соединитель бессерверного доступа к VPC в том же регионе, что и приложение App Engine.

Создайте экземпляр Cloud Memorystore.

Поскольку в Cloud Memorystore нет уровня бесплатного пользования, мы рекомендуем выделять наименьшее количество ресурсов для выполнения лаборатории кода. Вы можете свести затраты к минимуму, используя следующие настройки:

• Выберите самый низкий уровень обслуживания: «Базовый» (по умолчанию в консоли: «Стандарт», по умолчанию gcloud : «Базовый»).
• Выберите наименьший объем хранилища: 1 ГБ (по умолчанию для консоли: 16 ГБ, по умолчанию gcloud : 1 ГБ).
• Обычно новейшие версии любого программного обеспечения требуют наибольшее количество ресурсов, но выбирать самую старую версию, вероятно, также не рекомендуется. Вторая последняя версия на данный момент — Redis версии 5.0 (по умолчанию консоль: 6.x).

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

Из облачной консоли

Перейдите на страницу Cloud Memorystore в Cloud Console (вам может быть предложено ввести платежную информацию). Если вы еще не включили Memorystore, вам будет предложено это сделать:

Как только вы включите его (и, возможно, вместе с выставлением счетов), вы попадете на панель управления Memorystore. Здесь вы можете увидеть все экземпляры, созданные в вашем проекте. В показанном ниже проекте их нет, поэтому вы видите сообщение «Нет строк для отображения». Чтобы создать экземпляр Memorystore, нажмите «Создать экземпляр» вверху:

Обновления облачной консоли

Обратите внимание, что пользовательский интерфейс Cloud Console время от времени меняется, поэтому он может выглядеть не совсем так, как показано на скриншотах.

На этой странице есть форма для заполнения желаемых настроек для создания экземпляра Memorystore:

Чтобы снизить затраты на это руководство и пример приложения, следуйте рекомендациям, изложенным ранее. После того, как вы сделали свой выбор, нажмите «Создать» . Процесс создания занимает несколько минут. По завершении скопируйте IP-адрес и номер порта экземпляра , чтобы добавить их в app.yaml .

Из командной строки

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

Как и в случае с Cloud Console, необходимо включить Cloud Memorystore для Redis. Введите команду gcloud services enable redis.googleapis.com и дождитесь ее завершения, как в этом примере:

$ gcloud services enable redis.googleapis.com
Operation "operations/acat.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.

Если служба уже включена, повторный запуск команды не имеет (отрицательных) побочных эффектов. Включив службу, давайте создадим экземпляр Memorystore. Эта команда выглядит следующим образом:

gcloud redis instances create NAME --redis-version VERSION \
    --region REGION --project PROJECT_ID

Выберите имя для своего экземпляра Memorystore; в этой лаборатории в качестве имени используется « demo-ms » вместе с идентификатором проекта « my-project ». Регион этого примера приложения — us-central1 (так же, как us-central ), но вы можете использовать более близкий к вам регион, если задержка вызывает беспокойство. Вы должны выбрать тот же регион, что и ваше приложение App Engine. Вы можете выбрать любую версию Redis, которую предпочитаете, но мы используем версию 5, как было рекомендовано ранее. Учитывая эти настройки, вы должны ввести следующую команду (вместе с соответствующим выводом):

$ gcloud redis instances create demo-ms --region us-central1 \
    --redis-version redis_5_0 --project my-project

Create request issued for: [demo-ms]
Waiting for operation [projects/my-project/locations/us-central1/operations/operation-xxxx] to complete...done.
Created instance [demo-ms].

В отличие от настроек по умолчанию в Cloud Console, gcloud по умолчанию использует минимальные ресурсы. В результате в этой команде не требовались ни уровень обслуживания, ни объем хранилища. Создание экземпляра Memorystore занимает несколько минут, и когда это будет сделано, запишите IP-адрес экземпляра и номер порта, поскольку они скоро будут добавлены в app.yaml .

Подтвердите создание экземпляра

Из облачной консоли или командной строки

Независимо от того, создали ли вы свой экземпляр из облачной консоли или из командной строки, вы можете подтвердить, что он доступен и готов к использованию с помощью этой команды: gcloud redis instances list --region REGION

Вот команда для проверки экземпляров в регионе us-central1 вместе с ожидаемым результатом, показывающим только что созданный экземпляр:

$ gcloud redis instances list --region us-central1
INSTANCE_NAME  VERSION    REGION       TIER   SIZE_GB  HOST         PORT  NETWORK  RESERVED_IP     STATUS  CREATE_TIME
demo-ms        REDIS_5_0  us-central1  BASIC  1        10.aa.bb.cc  6379  default  10.aa.bb.dd/29  READY   2022-01-28T09:24:45

При запросе информации об экземпляре или настройке приложения обязательно используйте HOST и PORT (а не RESERVED_IP ). На панели управления Cloud Memorystore в Cloud Console теперь должен отображаться этот экземпляр:

С виртуальной машины Compute Engine

Если у вас есть виртуальная машина Compute Engine (ВМ), вы также можете отправлять прямые команды экземпляру Memorystore с виртуальной машины, чтобы убедиться, что она работает. Имейте в виду, что использование виртуальной машины может повлечь за собой затраты, независимые от ресурсов, которые вы уже используете.

Создание соединителя бессерверного доступа к VPC.

Как и в случае с Cloud Memorystore, вы можете создать бессерверный соединитель Cloud VPC в облачной консоли или в командной строке. Аналогично, Cloud VPC не имеет уровня бесплатного пользования , поэтому мы рекомендуем выделять наименьшее количество ресурсов для завершения работы над кодом, чтобы свести затраты к минимуму, и этого можно достичь с помощью следующих настроек:

• Выберите наименьшее максимальное количество экземпляров: 3 (по умолчанию для консоли и gcloud : 10).
• Выберите тип машины с наименьшей стоимостью: f1-micro (по умолчанию в консоли: e2-micro , без значения по умолчанию gcloud ).

В следующем разделе вы узнаете, как создать коннектор из облачной консоли с использованием указанных выше настроек Cloud VPC. Если вы предпочитаете делать это из командной строки, перейдите к следующему разделу.

Из облачной консоли

Перейдите на страницу облачной сети «Бессерверный доступ к VPC» в облачной консоли (вам может быть предложено ввести платежную информацию). Если вы еще не включили API, вам будет предложено это сделать:

После включения API (и, возможно, вместе с выставлением счетов) вы попадете на панель мониторинга, отображающую все созданные соединители VPC. В проекте, показанном на снимке экрана ниже, их нет, поэтому в нем написано «Нет строк для отображения». В консоли нажмите «Создать соединитель» вверху:

Заполните форму с желаемыми настройками:

Выберите подходящие настройки для своих приложений. Для этого руководства и примера приложения с минимальными потребностями имеет смысл минимизировать затраты, поэтому следуйте рекомендациям, изложенным ранее. После того, как вы сделали свой выбор, нажмите «Создать» . Запрос соединителя VPC займет несколько минут.

Из командной строки

Прежде чем создавать соединитель VPC, сначала включите API бессерверного доступа к VPC. Вы должны увидеть аналогичный результат после ввода следующей команды:

$ gcloud services enable vpcaccess.googleapis.com
Operation "operations/acf.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.

При включенном API коннектор VPC создается с помощью команды, которая выглядит следующим образом:

gcloud compute networks vpc-access connectors create CONNECTOR_NAME \
    --range 10.8.0.0/28 --region REGION --project PROJECT_ID

Выберите имя для своего соединителя, а также неиспользуемый начальный IP-адрес блока /28 CIDR. В этом руководстве сделаны следующие предположения:

• Идентификатор проекта : my-project
• Имя разъема VPC : demo-vpc
• Минимальное количество экземпляров : 2 (по умолчанию) и максимальное количество экземпляров : 3.
• Тип экземпляра : f1-micro
• Регион : us-central1
• Блок IPv4 CIDR : 10.8.0.0/28 (как рекомендовано в облачной консоли)

Ожидайте вывода, похожего на то, что вы видите ниже, если вы выполните следующую команду с учетом приведенных выше предположений:

$ gcloud compute networks vpc-access connectors create demo-vpc \
    --max-instances 3 --range 10.8.0.0/28 --machine-type f1-micro \
    --region us-central1  --project my-project

Create request issued for: [demo-vpc]
Waiting for operation [projects/my-project/locations/us-central1/operations/xxx] to complete...done.
Created connector [demo-vpc].

В приведенной выше команде не указываются значения по умолчанию, такие как минимальное количество экземпляров 2 и сеть с именем default . Создание соединителя VPC занимает несколько минут.

Подтвердите создание соединителя

После завершения процесса введите следующую команду gcloud , предполагая, что это регион us-central1 , чтобы подтвердить, что он создан и готов к использованию:

$ gcloud compute networks vpc-access connectors list --region us-central1
CONNECTOR_ID  REGION       NETWORK  IP_CIDR_RANGE  SUBNET  SUBNET_PROJECT  MIN_THROUGHPUT  MAX_THROUGHPUT  STATE
demo-vpc      us-central1  default  10.8.0.0/28                            200             300             READY

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

Запишите идентификатор облачного проекта, имя соединителя VPC и регион.

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

5. Обновите файлы конфигурации.

Первым шагом является внесение всех необходимых обновлений в файлы конфигурации. Основная цель этой лаборатории кода — помочь пользователям Python 2 перейти на Python 2, однако за содержанием обычно следует информация о дальнейшем портировании на Python 3 в каждом разделе ниже.

требования.txt

В этом разделе мы добавляем пакеты для поддержки Cloud Memorystore, а также Cloud NDB. Для Cloud Memorystore для Redis достаточно использовать стандартный клиент Redis для Python ( redis ), поскольку клиентской библиотеки Cloud Memorystore как таковой нет. Добавьте redis и google-cloud-ndb в requirements.txt , присоединив flask из модуля 12:

flask
redis
google-cloud-ndb

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

app.yaml

Новые разделы для добавления

Среде выполнения Python 2 App Engine требуются определенные сторонние пакеты при использовании Cloud API, таких как Cloud NDB, а именно grpcio и setuptools . Пользователи Python 2 должны перечислить подобные встроенные библиотеки вместе с доступной версией в app.yaml . Если у вас еще нет раздела libraries , создайте его и добавьте обе библиотеки, как показано ниже:

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest

При переносе вашего приложения в нем может уже быть раздел libraries . Если это так, и grpcio и setuptools отсутствуют, просто добавьте их в раздел существующих libraries .

Далее нашему примеру приложения потребуется информация об экземпляре Cloud Memorystore и соединителе VPC, поэтому добавьте следующие два новых раздела в app.yaml независимо от того, какую среду выполнения Python вы используете:

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

Это все, что касается необходимых обновлений. Ваш обновленный app.yaml теперь должен выглядеть так:

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

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

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

Ниже приведены «до и после», иллюстрирующие обновления, которые следует применить к app.yaml :

* Отличия Python 3

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

Ни threadsafe , ни api_version не используются для среды выполнения Python 3, поэтому удалите оба этих параметра. Последняя версия среды выполнения App Engine не поддерживает встроенные сторонние библиотеки и копирование сторонних библиотек . Единственное требование для сторонних пакетов — указать их в requirements.txt . В результате весь раздел libraries в app.yaml может быть удален.

Далее, среда выполнения Python 3 требует использования веб-фреймворков, которые выполняют собственную маршрутизацию, поэтому в модуле 1 мы показали разработчикам, как перейти с webp2 на Flask . В результате все обработчики скриптов необходимо изменить на auto . Поскольку это приложение не обслуживает статические файлы, «бессмысленно» указывать обработчики (поскольку все они являются auto ), поэтому весь раздел handlers также можно удалить. В результате ваш новый сокращенный app.yaml настроенный для Python 3, должен быть сокращен и выглядеть следующим образом:

runtime: python39

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

Подведем итоги различий в app.yaml при портировании на Python 3:

• Удалить настройки threadsafe и api_version
• Удалить раздел libraries
• Удалите раздел handlers (или просто обработчиков script , если ваше приложение обслуживает статические файлы).

Замените значения

Значения в новых разделах Memorystore и соединителя VPC — это всего лишь заполнители. Замените эти значения с заглавной буквы ( YOUR_REDIS_HOST, YOUR_REDIS_PORT, PROJECT_ID, REGION, CONNECTOR_NAME ) значениями, сохраненными при создании этих ресурсов ранее. Что касается вашего экземпляра Memorystore, обязательно используйте HOST (не RESERVED_IP ) и PORT . Вот быстрый способ получить HOST и PORT из командной строки, предполагая, что имя экземпляра demo-ms , а REGION — us-central1 :

$ gcloud redis instances describe demo-ms --region us-central1 \
    --format "value(host,port)"
10.251.161.51   6379

Если в нашем примере IP-адрес экземпляра Redis был 10.10.10.10 с использованием порта 6379 в нашем проекте my-project , расположенном в регионе us-central1 с именем соединителя VPC demo-vpc , эти разделы в app.yaml будут выглядеть следующим образом:

env_variables:
    REDIS_HOST: '10.10.10.10'
    REDIS_PORT: '6379'

vpc_access_connector:
    name: projects/my-project/locations/us-central1/connectors/demo-vpc

Создайте или обновите appengine_config.py.

Добавить поддержку встроенных сторонних библиотек.

Как и ранее мы делали с app.yaml , добавьте использование библиотек grpcio и setuptools . Измените appengine_config.py для поддержки встроенных сторонних библиотек. Если это кажется вам знакомым, то это потому, что это также требовалось еще в Модуле 2 при переходе с App Engine ndb на Cloud NDB. Точное необходимое изменение — добавить папку lib в рабочий набор setuptools.pkg_resources :

* Отличия Python 3

Этот раздел является необязательным и доступен только в том случае, если вы переносите на Python 3. Одним из приятных изменений второго поколения App Engine является то, что копирование (иногда называемое «поставщиком») (не встроенных) сторонних пакетов и ссылка на встроенные в сторонних пакетах в app.yaml больше нет необходимости, то есть вы можете удалить весь файл appengine_config.py .

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

Существует только один файл приложения — main.py , поэтому все изменения в этом разделе затрагивают только этот файл. Мы предоставили графическое представление изменений, которые мы собираемся внести для переноса этого приложения в Cloud Memorystore. Это только для иллюстративных целей и не предназначено для внимательного анализа. Вся работа заключается в изменениях, которые мы вносим в код.

Давайте рассмотрим эти разделы по одному, начиная сверху.

Обновить импорт

Раздел импорта в main.py для модуля 12 использует Cloud NDB и Cloud Tasks; вот их импорт:

ДО:

from flask import Flask, render_template, request
from google.appengine.api import memcache
from google.appengine.ext import ndb

Для переключения на Memorystore требуется чтение переменных среды, а это означает, что нам нужен модуль Python os , а также redis , клиент Python Redis. Поскольку Redis не может кэшировать объекты Python, упорядочите список последних посещений с помощью pickle , поэтому импортируйте и его. Одним из преимуществ Memcache является то, что сериализация объектов происходит автоматически, тогда как Memorystore немного более «сделай сам». Наконец, обновите App Engine ndb до Cloud NDB, заменив google.appengine.ext.ndb на google.cloud.ndb . После этих изменений ваш импорт должен выглядеть следующим образом:

ПОСЛЕ:

import os
import pickle
from flask import Flask, render_template, request
from google.cloud import ndb
import redis

Инициализация обновления

Инициализация модуля 12 состоит из создания app объекта приложения Flask и установки константы для часового кэширования:

ДО :

app = Flask(__name__)
HOUR = 3600

Для использования Cloud API требуется клиент, поэтому создайте экземпляр клиента Cloud NDB сразу после Flask. Затем получите IP-адрес и номер порта для экземпляра Memorystore из переменных среды, которые вы установили в app.yaml . Вооружившись этой информацией, создайте экземпляр клиента Redis. Вот как выглядит ваш код после этих обновлений:

ПОСЛЕ:

app = Flask(__name__)
ds_client = ndb.Client()
HOUR = 3600
REDIS_HOST = os.environ.get('REDIS_HOST', 'localhost')
REDIS_PORT = os.environ.get('REDIS_PORT', '6379')
REDIS = redis.Redis(host=REDIS_HOST, port=REDIS_PORT)

*Миграция Python 3

Этот раздел является необязательным, если вы начинаете с версии Python 3 приложения Модуля 12. Если да, то необходимо внести несколько изменений, связанных с импортом и инициализацией.

Во-первых, поскольку Memcache является встроенной службой App Engine, для ее использования в приложении Python 3 требуется App Engine SDK, в частности, оболочка приложения WSGI (а также другая необходимая конфигурация ):

ДО:

from flask import Flask, render_template, request
from google.appengine.api import memcache, wrap_wsgi_app
from google.appengine.ext import ndb

app = Flask(__name__)
app.wsgi_app = wrap_wsgi_app(app.wsgi_app)
HOUR = 3600

Поскольку мы переходим на Cloud Memorystore (а не на встроенную службу App Engine, например Memcache), использование SDK необходимо прекратить. Это просто, поскольку вы просто удалите всю строку, которая импортирует как memcache , так и wrap_wsgi_app . Также удалите строку, вызывающую wrap_wsgi_app() . Эти обновления делают эту часть приложения (фактически все приложение) идентичной версии Python 2.

ПОСЛЕ:

import os
import pickle
from flask import Flask, render_template, request
from google.cloud import ndb
import redis

app = Flask(__name__)
ds_client = ndb.Client()
HOUR = 3600
REDIS_HOST = os.environ.get('REDIS_HOST', 'localhost')
REDIS_PORT = os.environ.get('REDIS_PORT', '6379')
REDIS = redis.Redis(host=REDIS_HOST, port=REDIS_PORT)

Наконец, удалите использование SDK из app.yaml (удалите строку: app_engine_apis: true ) и requirements.txt (удалите строку: appengine-python-standard ).

Миграция в Cloud Memorystore (и Cloud NDB)

Модель данных Cloud NDB совместима с ndb App Engine, то есть определение объектов Visit остается прежним. Имитируя миграцию Модуля 2 в Cloud NDB, все вызовы Datastore в store_visit() и fetch_visits() дополняются и встраиваются в новый блок with (поскольку требуется использование контекстного менеджера Cloud NDB). Вот те вызовы до этого изменения:

ДО:

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

def fetch_visits(limit):
    'get most recent visits'
    return Visit.query().order(-Visit.timestamp).fetch(limit)

Добавьте блок with ds_client.context() к обеим функциям и поместите внутрь вызовы хранилища данных (с отступом). В этом случае никаких изменений в самих вызовах не требуется:

ПОСЛЕ:

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()

def fetch_visits(limit):
    'get most recent visits'
    with ds_client.context():
        return Visit.query().order(-Visit.timestamp).fetch(limit)

Далее давайте посмотрим на изменения в кэшировании. Вот функция main() из модуля 12:

ДО:

@app.route('/')
def root():
    'main application (GET) handler'
    # check for (hour-)cached visits
    ip_addr, usr_agt = request.remote_addr, request.user_agent
    visitor = '{}: {}'.format(ip_addr, usr_agt)
    visits = memcache.get('visits')

    # register visit & run DB query if cache empty or new visitor
    if not visits or visits[0].visitor != visitor:
        store_visit(ip_addr, usr_agt)
        visits = list(fetch_visits(10))
        memcache.set('visits', visits, HOUR)  # set() not add()

    return render_template('index.html', visits=visits)

В Redis есть вызовы «get» и «set», как и в Memcache. Все, что мы делаем, это меняем соответствующие клиентские библиотеки, верно? Почти. Как упоминалось ранее, мы не можем кэшировать список Python с помощью Redis (потому что сначала его необходимо сериализовать, о чем Memcache позаботится автоматически), поэтому в вызове set() «собирайте» посещения в строку с помощью pickle.dumps() . Аналогично, при получении посещений из кеша вам необходимо отменить его с помощью pickle.loads() сразу после get() . Вот основной обработчик после реализации этих изменений:

ПОСЛЕ:

@app.route('/')
def root():
    'main application (GET) handler'
    # check for (hour-)cached visits
    ip_addr, usr_agt = request.remote_addr, request.user_agent
    visitor = '{}: {}'.format(ip_addr, usr_agt)
    rsp = REDIS.get('visits')
    visits = pickle.loads(rsp) if rsp else None

    # register visit & run DB query if cache empty or new visitor
    if not visits or visits[0].visitor != visitor:
        store_visit(ip_addr, usr_agt)
        visits = list(fetch_visits(10))
        REDIS.set('visits', pickle.dumps(visits), ex=HOUR)

    return render_template('index.html', visits=visits)

На этом завершаются изменения, необходимые в main.py для преобразования использования Memcache в примере приложения в Cloud Memorystore. А как насчет HTML-шаблона и переноса на Python 3?

Обновить файл шаблона HTML и перенести его на Python 3?

Сюрприз! Здесь нечего делать, поскольку приложение было разработано для работы как на Python 2, так и на 3 без каких-либо изменений кода и библиотек совместимости. Вы найдете main.py идентичны в папках «FINISH» mod13a (2.x) и mod13b (3.x). То же самое касается и requirements.txt , за исключением любых различий в номерах версий (если они используются). Поскольку пользовательский интерфейс остается неизменным, templates/index.html также не обновляются.

Все необходимое для запуска этого приложения на Python 3 App Engine было выполнено ранее в конфигурации: ненужные директивы были удалены из app.yaml , а appengine_config.py и папка lib были удалены, поскольку они не используются в Python 3.

App Engine NDB и Cloud NDB обеспечивают автоматическое кэширование.

Хотя мы явно переходим с App Engine Memcache на Cloud Memorystore, обратите внимание, что и App Engine ndb , и Cloud NDB обеспечивают автоматическое кэширование в Memcache или Memorystore соответственно для Python 2 или 3. О кэшировании ndb читайте на странице NDB Caching и Cloud NDB. кэширование в разделе Включение кэширования данных , последняя из инструкций которого точно повторяет инструкции в этой кодовой лаборатории. Дополнительные функции можно найти в разделе «Контекст и параметры транзакции» .

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

7. Подведение итогов/очистка

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

Развертывание и проверка приложения

Последней проверкой всегда является развертывание примера приложения. Разработчики Python 2: удалите и переустановите lib с помощью команд ниже. (Если в вашей системе установлены Python 2 и 3, вам может потребоваться вместо этого явно запустить pip2 .)

rm -rf ./lib
pip install -t lib -r requirements.txt

Разработчики Python 2 и 3 теперь должны развертывать свои приложения с помощью:

gcloud app deploy

Поскольку вы просто перенастроили все под капотом для совершенно другой службы кэширования, само приложение должно работать идентично вашему приложению Модуля 12:

Этот шаг завершает работу над кодом. Мы приглашаем вас сравнить обновленный пример приложения с любой из папок Модуля 13: mod13a (Python 2) или mod13b (Python 3).

Очистить

Общий

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

Для полной информации: развертывание на бессерверной вычислительной платформе Google Cloud, такой как App Engine, требует незначительных затрат на сборку и хранение . Cloud Build имеет собственную бесплатную квоту, как и 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 », если ваше приложение размещено в США.

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

Специально для этой кодовой лаборатории

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

• Cloud Memorystore требует наличия экземпляров и не имеет уровня бесплатного пользования; Чтобы узнать больше о стоимости использования, посетите страницу с ценами .
• Для соединителей Cloud Serverless VPC Access требуются экземпляры, и у них нет уровня бесплатного пользования; Чтобы узнать больше о стоимости использования, см. соответствующий раздел на странице цен на Cloud VPC .
• Cloud Datastore (Cloud Firestore в режиме хранилища данных) имеет уровень бесплатного пользования; дополнительную информацию см. на странице цен .

В этом руководстве использовалось четыре облачных продукта:

• Механизм приложений
• Облачное хранилище данных
• Облачное хранилище памяти
• Облачное облако VPC

Ниже приведены инструкции по освобождению этих ресурсов и предотвращению/минимизации расходов по выставлению счетов.

Завершение работы экземпляра Memorystore и соединителя VPC.

Эти продукты не имеют уровня бесплатного пользования , поэтому вы должны платить за них прямо сейчас . Если вы не закроете свой облачный проект (см. следующий раздел), вам придется удалить как экземпляр Memorystore, так и соединитель VPC, чтобы прекратить выставление счетов. Подобно тому, как вы создавали эти ресурсы, вы также можете освободить их либо из облачной консоли, либо из командной строки.

Из облачной консоли

Чтобы удалить экземпляр Memorystore, вернитесь на панель управления Memorystore и щелкните идентификатор экземпляра:

На странице сведений об этом экземпляре нажмите «Удалить» и подтвердите:

Чтобы удалить коннектор VPC, перейдите на его панель управления и установите флажок рядом с коннектором, который вы хотите удалить, затем нажмите «Удалить» и подтвердите:

Из командной строки

Следующая пара команд gcloud удаляет экземпляр Memorystore и соединитель VPC соответственно:

• gcloud redis instances delete INSTANCE --region REGION
• gcloud compute networks vpc-access connectors delete CONNECTOR --region REGION

Если вы не установили идентификатор проекта с помощью gcloud config set project , вам, возможно, придется указать --project PROJECT_ID . Если ваш экземпляр Memorystore называется demo-ms , а коннектор VPC — demo-vpc и оба находятся в регионе us-central1 , введите следующую пару команд и подтвердите:

$ gcloud redis instances delete demo-ms --region us-central1
You are about to delete instance [demo-ms] in [us-central1].
Any associated data will be lost.

Do you want to continue (Y/n)?

Delete request issued for: [demo-ms]
Waiting for operation [projects/PROJECT/locations/REGION/operations/operation-aaaaa-bbbbb-ccccc-ddddd] to complete...done.
Deleted instance [demo-ms].
$
$ gcloud compute networks vpc-access connectors delete demo-vpc --region us-central1
You are about to delete connector [demo-vpc] in [us-central1].
Any associated data will be lost.

Do you want to continue (Y/n)?

Delete request issued for: [demo-vpc]
Waiting for operation [projects/PROJECT/locations/REGION/operations/aaaaa-bbbb-cccc-dddd-eeeee] to complete...done.
Deleted connector [demo-vpc].

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

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

Помимо этого руководства, следует рассмотреть и другие модули миграции, направленные на отказ от устаревших комплексных услуг:

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

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

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

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

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

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

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

Проблемы/отзывы Codelabs

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

• Поиск проблем
• Сообщить о новой проблеме/отзыве

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

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

Кодлаб	Питон 2	Питон 3
Модуль 12	код	код
Модуль 13 (эта кодовая лаборатория)	код	код

Интернет-ссылки

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

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

• Документация App Engine
• Среда выполнения Python 2 App Engine (стандартная среда)
• Использование встроенных библиотек App Engine в App Engine Python 2
• Среда выполнения Python 3 App Engine (стандартная среда)
• Различия между средами выполнения App Engine Python 2 и 3 (стандартная среда)
• Руководство по переходу с Python 2 на App Engine (стандартная среда)
• Информация о ценах и квотах App Engine

App Engine NDB и Cloud NDB

• Обзор App Engine NDB
• Использование хранилища данных App Engine NDB
• Документы Google Cloud NDB
• Репозиторий Google Cloud NDB
• Информация о ценах на Cloud Datastore

Memcache App Engine и Cloud Memorystore

• Обзор Memcache App Engine
• Справочник memcache App Engine Python 2
• Справочник memcache App Engine Python 3
• Руководство по миграции memcache App Engine в Cloud Memorystore
• Документация Cloud Memorystore
• Документация Cloud Memorystore для Redis
• Информация о ценах Cloud Memorystore для Redis
• Cloud Memorystore поддерживает версии Redis
• Домашняя страница Cloud Memorystore
• Создайте новый экземпляр Memorystore в Cloud Console.
• Домашняя страница клиента Python Redis
• Документация клиентской библиотеки Python Redis

Облачный VPC

• Google Cloud VPC Docs
• Google Cloud VPC домашняя страница
• Информация о ценах с облачным VPC
• Создать новый разъем VPC без сервера в облачной консоли

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

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

Лицензия

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