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

1. Обзор

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

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

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

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

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

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

Опрос

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

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

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

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

Однако гибкость контейнеров также является привлекательным преимуществом: возможность выбора любого языка программирования, любой библиотеки, любого исполняемого файла. 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 Engine

Docker

Buildpacks

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

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 . Подробнее о развертывании из исходного кода с помощью Buildpacks можно узнать на этой странице документации 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). Если вы хотите использовать другой HTTP-сервер, совместимый с WSGI, например 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 , заменив директивы script: auto в разделе handlers на entrypoint . Если вы используете entrypoint в файле app.yaml на Python 3, это будет выглядеть примерно так:

runtime: python38
entrypoint: python main.py

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

  • Buildpacks: строка в 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 на Buildpacks и обновления исходных файлов вы готовы запустить приложение в 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: Миграция в облако. Запуск с помощью Docker.
    • Создайте контейнер для запуска вашего приложения в Cloud Run с помощью 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 на Codelabs

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

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

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

Кодлаб

Python 2

Python 3

Модуль 2

код

( код )

Модуль 3

( код )

код

Модуль 5

(н/д)

код

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

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