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

1. Обзор

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

В этом руководстве вы узнаете, как контейнеризировать приложения App Engine для развертывания в полностью управляемом сервисе Cloud Run с помощью Docker — известной в отрасли платформы для разработки, распространения и запуска приложений в контейнерах. Для разработчиков на Python 2 это руководство начинается с примера приложения App Engine из модуля 2 Cloud NDB, а для разработчиков на Python 3 — с примера Cloud Datastore из модуля 3 .

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

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

Данная миграция включает в себя следующие этапы:

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

3. Подготовка/Предварительные работы

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

1. Настройка проекта

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

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

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

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

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

$ 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). Наше базовое демонстрационное приложение достаточно легковесно, чтобы избежать некоторых из упомянутых выше проблем Dockerfile .

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

Описание

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 — нет. Именно для этого и существуют команды ENTRYPOINT и CMD Dockerfile . Подробнее о 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. Подробнее см. на странице образов Python в Docker .

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

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

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

конфигурация стороннего разработчика

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

Запускать

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

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

runtime: python38
entrypoint: python main.py

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

  • Docker: строка в Dockerfile : ENTRYPOINT ["python", "main.py"]
  • Buildpacks: строка в Procfile : web: python main.py

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

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

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

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

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

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

Кодлаб

Python 2

Python 3

Модуль 2

код

( код )

Модуль 3

( код )

код

Модуль 4

код

код

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

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