Модуль 4. Переход с Google App Engine на Cloud Run с Docker

1. Обзор

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

Из этого руководства вы узнаете, как контейнеризировать приложения App Engine для развертывания в полностью управляемом сервисе Cloud Run с помощью Docker , известной в отрасли платформы для разработки, доставки и запуска приложений в контейнерах. Для разработчиков Python 2 это руководство НАЧИНАЕТСЯ с примера приложения Cloud NDB App Engine Модуля 2, а для разработчиков Python 3 НАЧИНАЕТСЯ с примера Cloud Datastore Модуля 3 .

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

  • Контейнеризируйте свое приложение с помощью Docker
  • Развертывание образов контейнеров в 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 конфигурацией контейнера, определять, что входит в контейнер, а затем указывать, как запускать приложение — многие из этих вещей автоматически обрабатываются App Engine.

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

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

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

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

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

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

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

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

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

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

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

Если вы используете собственный код модуля 2 (2.x), у вас также будет папка lib . Ни lib , ни appengine_config.py не используются для Python 3, где код запуска модуля 3 (3.x) должен выглядеть следующим образом: 

$ 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. Не стесняйтесь также выполнить лабораторную работу по Модулю 5 (идентичную этой, но с Cloud Buildpacks) после этого. Наш пример приложения Barebone достаточно легок, чтобы избежать некоторых из вышеупомянутых проблем Dockerfile .

Шаги миграции включают замену файлов конфигурации App Engine и указание способа запуска вашего приложения. Ниже приведена таблица с кратким описанием файлов конфигурации, которые следует ожидать для каждого типа платформы. Сравните столбец 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 означает замену app.yaml файлом Dockerfile , в котором описано, как создать и запустить контейнер. App Engine автоматически запускает ваше приложение, а Cloud Run — нет. Для этого предназначены команды Dockerfile ENTRYPOINT и CMD . Узнайте больше о Dockerfile на этой странице документации Cloud Run , а также посмотрите пример Dockerfile , который создает gunicorn .

Альтернативой использованию ENTRYPOINT или CMD в Dockerfile является использование Procfile . Наконец, .dockerignore помогает отфильтровывать файлы, не относящиеся к приложениям, чтобы уменьшить размер контейнера. Подробнее об этом в ближайшее время!

Удалите app.yaml и создайте Dockerfile

app.yaml не используется в контейнерах, поэтому удалите его сейчас . Файл конфигурации контейнера — Dockerfile , а нашему примеру приложения требуется только минимальный файл. Создайте свой Dockerfile с этим содержимым, заменив NNN на 2 или 3 , в зависимости от того, какую версию Python вы используете:

FROM python:NNN-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
ENTRYPOINT ["python", "main.py"]

Большая часть файла Dockerfile определяет, как создать контейнер, за исключением ENTRYPOINT , который определяет, как запустить контейнер, в данном случае вызывая python main.py для выполнения сервера разработки Flask. Если вы новичок в Docker, директива FROM указывает базовый образ, с которого нужно начать, а «slim» относится к минимальному дистрибутиву Python. Узнайте больше на странице изображений Docker Python .

Средний набор команд создает рабочий каталог ( /app ), копирует в него файлы приложения, а затем запускает pip install для добавления сторонних библиотек в контейнер. WORKDIR объединяет команды Linux mkdir и cd ; подробнее об этом читайте в документации WORKDIR . Директивы COPY и RUN говорят сами за себя.

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

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

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

Разработчики App Engine Python 2 знают, что сторонние библиотеки либо копируются в папку lib , на которые есть ссылки в requirements.txt , детализируются в app.yaml и поддерживаются appengine_config.py . Контейнеры, такие как приложения App Engine Python 3, используют только requirements.txt , поэтому все остальное можно удалить. Это означает, что если у вас есть приложение App Engine 2.x, удалите appengine_config.py и любую папку lib прямо сейчас.

Запускать

Пользователи Python 2 не запускают веб-сервер App Engine, но при переходе в контейнер вам придется это сделать. Это делается путем добавления директивы CMD или ENTRYPOINT в ваш Dockerfile , указывающей, как запустить ваше приложение, и это описано ниже так же, как для пользователей Python 3.

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

runtime: python38
entrypoint: python main.py

Директива entrypoint сообщает App Engine, как запустить сервер. Вы можете переместить его практически прямо в свой Dockerfile (или Procfile если используете Buildpacks [см. Модуль 5] для контейнеризации вашего приложения). Подводя итог, где будет проходить директива точки входа между обеими платформами:

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

Использование сервера разработки Flask подходит для тестирования, но если для вашего приложения используется рабочий сервер, например gunicorn , обязательно укажите на него директиву ENTRYPOINT или CMD , как в примере Cloud Run Quickstart .

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

Мы рекомендуем создать файл .dockerignore , чтобы уменьшить размер вашего контейнера и не загромождать образ контейнера лишними файлами, такими как эти: 

*.md
*.pyc
*.pyo
.git/
.gitignore
__pycache__

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

Все приложения Модуля 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. Сборка и развертывание

После завершения настройки Docker и обновления исходного файла вы готовы запустить его в 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 beta 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 Dockerfile and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying new service... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision... Deploying Revision.
  ✓ Routing traffic...
  ✓ Setting IAM Policy...
Done.
Service [SVC_NAME] revision [SVC_NAME-00001-vos] 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

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

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

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

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

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

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

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

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

  • Перейдите на Python 3, если вы еще этого не сделали. Пример приложения уже совместим с версиями 2.x и 3.x, поэтому единственное изменение заключается в том, что пользователи Docker должны обновить свой Dockerfile для использования образа Python 3.
  • Модуль 5. Переход на Cloud Run с помощью Cloud Buildpacks
    • Контейнеризируйте свое приложение для запуска в облаке. Запускайте с помощью Cloud Buildpacks.
    • Вам не нужно ничего знать о Docker, контейнерах или Dockerfile .
    • Требуется, чтобы вы уже перенесли свое приложение на Python 3.
  • Модуль 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 (НАЧАЛО) и Модуля 4 (ФИНИШ) можно найти в таблице ниже. Доступ к ним также можно получить из репозитория для всех миграций лабораторий кода App Engine , которые можно клонировать или загрузить в виде ZIP-файла.

Кодлаб

Питон 2

Питон 3

Модуль 2

код

( код )

Модуль 3

( код )

код

Модуль 4

код

код

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

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