Модуль 5. Переход с Google App Engine на Cloud Run с помощью Cloud Buildpacks

1. Обзор

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

Из этого руководства вы узнаете, как контейнеризировать приложения App Engine для развертывания в полностью управляемом сервисе Cloud Run с помощью Cloud Buildpacks , альтернативы Docker. Cloud Buildpacks помещает ваши приложения в контейнеры, не управляя файлами Dockerfile и даже ничего не зная о Docker.

Эта лаборатория кода предназначена для разработчиков App Engine Python 2, которые перенесли свои приложения из исходных встроенных сервисов на Python 3 и теперь хотят запускать их в контейнере. Лаборатория кода НАЧИНАЕТСЯ с готового приложения модуля 2 или модуля 3 Python 3.

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

  • Контейнеризируйте свое приложение с помощью Cloud Buildpacks.
  • Развертывание образов контейнеров в Cloud Run

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

Опрос

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

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

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

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

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

Изучение того, как использовать Cloud Run, выходит за рамки этой лаборатории; это описано в документации Cloud Run . Цель здесь – помочь вам узнать, как контейнеризировать приложение App Engine для Cloud Run (или других сервисов). Прежде чем двигаться дальше, вам следует знать несколько вещей, в первую очередь то, что ваш пользовательский опыт будет немного другим, немного более низкоуровневым, поскольку вы больше не будете брать код приложения и развертывать его.

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

В этом руководстве вы узнаете, как поместить приложение в контейнер, удалить файлы конфигурации App Engine, управлять веб-сервером, в том числе как запустить приложение.

Эта миграция включает в себя следующие шаги:

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

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

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

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

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

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

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

Используете ли вы свой или наш, именно здесь НАЧИНАЕТСЯ это руководство. Эта лаборатория кода проведет вас через миграцию, и к тому времени, когда вы закончите, она должна в основном соответствовать тому, что находится в папке репозитория FINISH модуля 5.

Каталог файлов START (ваших или наших) должен выглядеть так: 

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

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

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

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

После успешного выполнения этих шагов вы готовы к контейнеризации.

4. Контейнеризация приложения

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

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

Шаги миграции включают замену файлов конфигурации App Engine и указание способа запуска вашего приложения. Ниже приведена таблица с кратким описанием файлов конфигурации, которые следует ожидать для каждого типа платформы. Сравните столбец App Engine со столбцом Buildpacks (и, при необходимости, Docker):

Описание

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

Докер

Сборочные пакеты

Общая конфигурация

app.yaml

Dockerfile

( service.yaml )

сторонние библиотеки

requirements.txt

requirements.txt

requirements.txt

Сторонняя конфигурация

app.yaml (плюс appengine_config.py и lib [только для 2.x])

(н/д)

(н/д)

Запускать

(н/д) или app.yaml (если используется entrypoint )

Dockerfile

Procfile

Игнорировать файлы

.gcloudignore и .gitignore

.gcloudignore , .gitignore и .dockerignore

.gcloudignore и .gitignore

После того как ваше приложение будет помещено в контейнер, его можно будет развернуть в Cloud Run. Другие варианты контейнерной платформы Google Cloud включают Compute Engine , GKE и Anthos .

Общая конфигурация

App Engine автоматически запускает ваше приложение, а Cloud Run — нет. Procfile выполняет ту же роль, что и директива app.yaml entrypoint . В нашем примере приложения Procfile выполнит python main.py для запуска сервера разработки Flask. При желании вы также можете использовать рабочий веб-сервер, например gunicorn , и если вы это сделаете, обязательно добавьте его в requirements.txt . Узнайте больше о том, как выполнить развертывание из исходного кода с помощью пакетов сборки, на этой странице документации Cloud Run .

Вам нужно только переместить директиву app.yaml entrypoint в Procfile . Если у вас его нет, используйте сейчас сервер разработки Flask, поскольку это всего лишь образец тестового приложения для ознакомления пользователей с этой миграцией. Ваше приложение будет представлять собой конкретную команду запуска, которую вы знаете лучше всего. Под прикрытием служба Cloud Run создает файл service.yaml , который больше похож на app.yaml . Вы можете просмотреть автоматически созданный service.yaml перейдя по такой ссылке, но для вашего сервиса SVC_NAME и REGION : https://console.cloud.google.com/run/detail/REGION/SVC_NAME/yaml/view .

сторонние библиотеки

Файл requirements.txt изменять не нужно; Flask должен быть там вместе с вашей клиентской библиотекой Datastore (Cloud Datastore или Cloud NDB). Если вы хотите использовать другой WSGI-совместимый HTTP-сервер, например Gunicorn (текущая версия на момент написания статьи — 20.0.4), добавьте gunicorn==20.0.4 в requirements.txt .

Сторонняя конфигурация

Buildpacks не поддерживает Python 2, поэтому мы не обсуждаем это здесь. Приложения Python 3, работающие в контейнерах в Cloud Run, аналогичны приложениям Python 3 App Engine тем, что сторонние библиотеки должны быть указаны в requirements.txt .

Запускать

Пользователи Python 3 имеют возможность преобразовать свои файлы app.yaml , чтобы в их разделе handlers была entrypoint вместо script: auto . Если вы используете entrypoint в своем app.yaml Python 3, это будет выглядеть примерно так:

runtime: python38
entrypoint: python main.py

Директива entrypoint сообщает App Engine, как запустить сервер. Вы можете переместить его практически прямо в свой Procfile . Подводя итог, где будет проходить директива точки входа между обеими платформами: Это напрямую переводится в следующее: также показан эквивалент Docker как к вашему сведению:

  • Пакеты сборки: строка в Procfile : web: python main.py
  • Docker: строка в Dockerfile : ENTRYPOINT ["python", "main.py"]

Для тестирования и промежуточного тестирования можно просто запустить сервер разработки Flask из Python, как описано выше, но разработчики могут выбрать что-то более мощное для производства, например образец Cloud Run Quickstart , в котором используется gunicorn .

Файлы приложений

Все приложения Модуля 2 или Модуля 3 полностью совместимы с Python 2–3, что означает отсутствие изменений в основных компонентах main.py ; мы добавим только несколько строк стартового кода. Добавьте пару строк внизу файла main.py , чтобы запустить сервер разработки, поскольку Cloud Run требует, чтобы порт 8080 был открыт, чтобы он мог вызывать ваше приложение: 

if __name__ == '__main__':
    import os
    app.run(debug=True, threaded=True, host='0.0.0.0',
            port=int(os.environ.get('PORT', 8080)))

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

После замены конфигурации App Engine на пакеты сборки и завершения обновления исходных файлов вы готовы запустить ее в Cloud Run. Перед этим давайте кратко обсудим сервисы .

Сервисы против приложений

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

Если ваше приложение App Engine не состоит из нескольких сервисов, вам действительно не нужно присваивать какие-либо имена при развертывании приложений. Ситуация меняется с появлением Cloud Run, где вам нужно придумать имя службы . В то время как домен appspot.com App Engine содержит идентификатор проекта, например, https://PROJECT_ID.appspot.com , и, возможно, аббревиатуру идентификатора региона, например, http://PROJECT_ID.REGION_ID.r.appspot.com .

Однако домен для службы Cloud Run содержит имя службы , аббревиатуру идентификатора региона и хеш, но не идентификатор проекта, например https://SVC_NAME-HASH-REG_ABBR.a.run.app . Итог: начните думать о названии службы!

Развернуть сервис

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

$ gcloud run deploy SVC_NAME --source .
Please choose a target platform:
 [1] Cloud Run (fully managed)
 [2] Cloud Run for Anthos deployed on Google Cloud
 [3] Cloud Run for Anthos deployed on VMware
 [4] cancel
Please enter your numeric choice:  1

To specify the platform yourself, pass `--platform managed`. Or, to make this the default target platform, run `gcloud config set run/platform managed`.

Please specify a region:
 [1] asia-east1
 [2] asia-east2
 [3] asia-northeast1
 [4] asia-northeast2
 [5] asia-northeast3
 [6] asia-south1
 [7] asia-southeast1
 [8] asia-southeast2
 [9] australia-southeast1
 [10] europe-north1
 [11] europe-west1
 [12] europe-west2
 [13] europe-west3
 [14] europe-west4
 [15] europe-west6
 [16] northamerica-northeast1
 [17] southamerica-east1
 [18] us-central1
 [19] us-east1
 [20] us-east4
 [21] us-west1
 [22] us-west2
 [23] us-west3
 [24] us-west4
 [25] cancel
Please enter your numeric choice: <select your numeric region choice>

To make this the default region, run `gcloud config set run/region REGION`.

Allow unauthenticated invocations to [SVC_NAME] (y/N)?  y

Building using Buildpacks and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision...
  ✓ Routing traffic...
Done.
Service [SVC_NAME] revision [SVC_NAME-00014-soc] has been deployed and is serving 100 percent of traffic.
Service URL: https://SVC_NAME-HASH-REG_ABBR.a.run.app

Посетите указанный URL-адрес в своем браузере, чтобы убедиться, что развертывание прошло успешно!

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

$ gcloud beta run deploy SVC_NAME --source . --platform managed --region REGION --allow-unauthenticated

Если вы используете этот вариант, обязательно выберите одно и то же имя службы SVC_NAME и желаемое имя REGION , а не индексированный выбор меню, как мы это делали в интерактивном режиме выше.

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

Убедитесь, что приложение работает в Cloud Run так же, как и в App Engine. Если вы приступили к этой серии, не пройдя ни одной из предыдущих работ по коду, само приложение не изменится; он регистрирует все посещения главной веб-страницы ( / ) и выглядит так, если вы посетили сайт достаточное количество раз:

приложение Visitme

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

Дополнительно: очистка

А как насчет очистки, чтобы избежать выставления счетов до тех пор, пока вы не будете готовы перейти к следующей лаборатории кода миграции? Поскольку теперь вы используете другой продукт, обязательно ознакомьтесь с руководством по ценам Cloud Run .

Необязательно: отключить службу

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

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

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

Поздравляем, вы контейнеризировали свое приложение, и это завершает этот урок! Отсюда следующий шаг — узнать, как сделать то же самое с Docker в лаборатории кода модуля 4 (ссылка ниже) или выполнить другую миграцию App Engine:

  • Модуль 4. Переход на Cloud Run с помощью Docker
    • Контейнеризируйте свое приложение для работы в облаке. Работайте с Docker.
    • Позволяет вам оставаться на Python 2
  • Модуль 7. Очереди задач App Engine Push (требуется, если вы используете очереди задач [push])
    • Добавляет taskqueue задач App Engine в приложение модуля 1.
    • Готовит пользователей к переходу на облачные задачи в модуле 8.
  • Модуль 3:
    • Модернизация доступа к хранилищу данных с Cloud NDB на Cloud Datastore
    • Это библиотека, используемая для приложений Python 3 App Engine и приложений, не принадлежащих App Engine.
  • Модуль 6: Миграция в Cloud Firestore
    • Перейдите в Cloud Firestore, чтобы получить доступ к функциям Firebase.
    • Хотя Cloud Firestore поддерживает Python 2, эта кодовая лаборатория доступна только в Python 3.

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

Проблемы и отзывы о модулях миграции App Engine

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

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

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

Кодлаб

Питон 2

Питон 3

Модуль 2

код

( код )

Модуль 3

( код )

код

Модуль 5

(н/д)

код

Ресурсы App Engine и Cloud Run

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