1. Введение
Cloud Run — это управляемая вычислительная платформа, которая позволяет запускать контейнеры без отслеживания состояния, которые можно вызвать с помощью HTTP-запросов. Cloud Run не требует серверов: он абстрагирует все управление инфраструктурой, поэтому вы можете сосредоточиться на самом важном — создании отличных приложений.
Он также естественным образом взаимодействует со многими другими частями экосистемы Google Cloud, включая Cloud SQL для управляемых баз данных, Cloud Storage для унифицированного хранилища объектов и Secret Manager для управления секретами.
Wagtail — это система управления контентом (CMS) с открытым исходным кодом, построенная на базе Django. Django — это веб-фреймворк Python высокого уровня.
В этом руководстве вы будете использовать эти компоненты для развертывания небольшого проекта Wagtail.
Примечание. Последний раз эта кодовая лаборатория была проверена с помощью Wagtail 5.2.2 , которая поддерживает Django 5.
Что вы узнаете
- Как использовать Cloud Shell
- Как создать базу данных Cloud SQL
- Как создать корзину Cloud Storage
- Как создать секреты Secret Manager
- Как использовать секреты из разных сервисов Google Cloud
- Как подключить компоненты Google Cloud к сервису Cloud Run
- Как использовать реестр контейнеров для хранения собранных контейнеров
- Как выполнить развертывание в Cloud Run
- Как запустить миграцию схемы базы данных в Cloud Build
2. Настройка и требования
Самостоятельная настройка среды
- Войдите в Google Cloud Console и создайте новый проект или повторно используйте существующий. Если у вас еще нет учетной записи Gmail или Google Workspace, вам необходимо ее создать .
- Имя проекта — это отображаемое имя для участников этого проекта. Это строка символов, не используемая API Google. Вы всегда можете обновить его.
- Идентификатор проекта уникален для всех проектов Google Cloud и является неизменяемым (невозможно изменить после его установки). Cloud Console автоматически генерирует уникальную строку; обычно тебя не волнует, что это такое. В большинстве лабораторий кода вам потребуется указать идентификатор проекта (обычно идентифицируемый как
PROJECT_ID
). Если вам не нравится сгенерированный идентификатор, вы можете создать другой случайный идентификатор. Кроме того, вы можете попробовать свой собственный и посмотреть, доступен ли он. Его нельзя изменить после этого шага и он сохраняется на протяжении всего проекта. - К вашему сведению, есть третье значение — номер проекта , который используют некоторые API. Подробнее обо всех трех этих значениях читайте в документации .
- Затем вам необходимо включить выставление счетов в Cloud Console, чтобы использовать облачные ресурсы/API. Прохождение этой лаборатории кода не будет стоить много, если вообще что-то стоить. Чтобы отключить ресурсы и избежать выставления счетов за пределами этого руководства, вы можете удалить созданные вами ресурсы или удалить проект. Новые пользователи Google Cloud имеют право на участие в программе бесплатной пробной версии стоимостью 300 долларов США .
Google Cloud Shell
Хотя Google Cloud можно управлять удаленно с вашего ноутбука, в этой лаборатории мы будем использовать Google Cloud Shell , среду командной строки, работающую в облаке.
Активировать Cloud Shell
- В Cloud Console нажмите «Активировать Cloud Shell». .
Если вы запускаете Cloud Shell впервые, вы увидите промежуточный экран с описанием того, что это такое. Если вам был представлен промежуточный экран, нажмите «Продолжить» .
Подготовка и подключение к Cloud Shell займет всего несколько минут.
Эта виртуальная машина загружена всеми необходимыми инструментами разработки. Он предлагает постоянный домашний каталог объемом 5 ГБ и работает в Google Cloud, что значительно повышает производительность сети и аутентификацию. Большую часть, если не всю, работу в этой лаборатории кода можно выполнить с помощью браузера.
После подключения к Cloud Shell вы увидите, что вы прошли аутентификацию и что для проекта установлен идентификатор вашего проекта.
- Выполните следующую команду в Cloud Shell, чтобы подтвердить, что вы прошли аутентификацию:
gcloud auth list
Вывод команды
Credentialed Accounts ACTIVE ACCOUNT * <my_account>@<my_domain.com> To set the active account, run: $ gcloud config set account `ACCOUNT`
- Выполните следующую команду в Cloud Shell, чтобы убедиться, что команда gcloud знает о вашем проекте:
gcloud config list project
Вывод команды
[core] project = <PROJECT_ID>
Если это не так, вы можете установить это с помощью этой команды:
gcloud config set project <PROJECT_ID>
Вывод команды
Updated property [core/project].
3. Включите облачные API.
В Cloud Shell включите Cloud API для компонентов, которые будут использоваться:
gcloud services enable \ run.googleapis.com \ sql-component.googleapis.com \ sqladmin.googleapis.com \ compute.googleapis.com \ cloudbuild.googleapis.com \ secretmanager.googleapis.com \ artifactregistry.googleapis.com
Поскольку вы впервые вызываете API из gcloud, вам будет предложено авторизоваться, используя свои учетные данные для выполнения этого запроса. Это произойдет один раз за сеанс Cloud Shell.
Выполнение этой операции может занять несколько минут.
После завершения должно появиться сообщение об успехе, подобное этому:
Operation "operations/acf.cc11852d-40af-47ad-9d59-477a12847c9e" finished successfully.
4. Создайте шаблон проекта
В качестве примера проекта Wagtail вы будете использовать шаблон проекта Wagtail по умолчанию. Для этого вы временно установите Wagtail для создания шаблона.
Чтобы создать этот шаблон проекта, используйте Cloud Shell, чтобы создать новый каталог с именем wagtail-cloudrun
и перейдите к нему:
mkdir ~/wagtail-cloudrun cd ~/wagtail-cloudrun
Затем установите Wagtail во временную виртуальную среду:
virtualenv venv source venv/bin/activate pip install wagtail
Затем создайте новый проект шаблона в текущей папке:
wagtail start myproject .
Теперь в текущей папке у вас появится шаблон проекта Wagtail:
ls -F
Dockerfile home/ manage.py* myproject/ requirements.txt search/ venv/
Теперь вы можете выйти и удалить временную виртуальную среду:
deactivate rm -rf venv
Отсюда Wagtail будет вызываться внутри контейнера.
5. Создайте службы поддержки
Теперь вы создадите свои вспомогательные службы: выделенную учетную запись службы, реестр артефактов, базу данных Cloud SQL, корзину Cloud Storage и ряд значений Secret Manager.
Защита значений паролей, используемых при развертывании, важна для безопасности любого проекта и гарантирует, что никто случайно не разместит пароли там, где им не место (например, непосредственно в файлах настроек или не будет введен непосредственно в ваш терминал, где они могут быть извлечь из истории.)
Для начала установите две базовые переменные среды, одну для идентификатора проекта:
PROJECT_ID=$(gcloud config get-value core/project)
И один для региона:
REGION=us-central1
Создать учетную запись службы
Чтобы ограничить доступ службы к другим частям Google Cloud, создайте специальную учетную запись службы:
gcloud iam service-accounts create cloudrun-serviceaccount
Вы будете ссылаться на эту учетную запись по электронной почте в будущих разделах этой лаборатории кода. Установите это значение в переменной среды:
SERVICE_ACCOUNT=$(gcloud iam service-accounts list \ --filter cloudrun-serviceaccount --format "value(email)")
Создайте реестр артефактов
Чтобы сохранить собранный образ контейнера, создайте реестр контейнеров в выбранном вами регионе:
gcloud artifacts repositories create containers --repository-format docker --location $REGION
Вы будете ссылаться на этот реестр по имени в будущих разделах этой кодовой лаборатории:
ARTIFACT_REGISTRY=${REGION}-docker.pkg.dev/${PROJECT_ID}/containers
Создать базу данных
Создайте экземпляр Cloud SQL:
gcloud sql instances create myinstance --project $PROJECT_ID \ --database-version POSTGRES_14 --tier db-f1-micro --region $REGION
Выполнение этой операции может занять несколько минут.
В этом случае создайте базу данных:
gcloud sql databases create mydatabase --instance myinstance
В этом же случае создайте пользователя:
DJPASS="$(cat /dev/urandom | LC_ALL=C tr -dc 'a-zA-Z0-9' | fold -w 30 | head -n 1)" gcloud sql users create djuser --instance myinstance --password $DJPASS
Предоставьте учетной записи службы разрешение на подключение к экземпляру:
gcloud projects add-iam-policy-binding $PROJECT_ID \ --member serviceAccount:${SERVICE_ACCOUNT} \ --role roles/cloudsql.client
Создайте сегмент хранилища
Создайте корзину Cloud Storage (обратите внимание, что имя должно быть глобально уникальным):
GS_BUCKET_NAME=${PROJECT_ID}-media gcloud storage buckets create gs://${GS_BUCKET_NAME} --location ${REGION}
Предоставьте учетной записи службы разрешения на администрирование корзины:
gcloud storage buckets add-iam-policy-binding gs://${GS_BUCKET_NAME} \ --member serviceAccount:${SERVICE_ACCOUNT} \ --role roles/storage.admin
Поскольку объекты, хранящиеся в корзине, будут иметь другое происхождение (URL-адрес корзины, а не URL-адрес Cloud Run), вам необходимо настроить параметры совместного использования ресурсов между источниками (CORS) .
Создайте новый файл cors.json
со следующим содержимым:
touch cors.json cloudshell edit cors.json
cors.json
[
{
"origin": ["*"],
"responseHeader": ["Content-Type"],
"method": ["GET"],
"maxAgeSeconds": 3600
}
]
Примените эту конфигурацию CORS к вновь созданному сегменту хранилища:
gsutil cors set cors.json gs://$GS_BUCKET_NAME
Хранить конфигурацию в секрете
Настроив службы поддержки, вы сохраните эти значения в файле, защищенном с помощью Secret Manager.
Secret Manager позволяет хранить секреты, управлять ими и получать к ним доступ в виде двоичных объектов или текстовых строк. Он хорошо подходит для хранения информации о конфигурации, такой как пароли базы данных, ключи API или сертификаты TLS, необходимые приложению во время выполнения.
Сначала создайте файл со значениями строки подключения к базе данных , медиа-база, секретного ключа для Django (используется для криптографической подписи сессий и токенов) и включите отладку:
echo DATABASE_URL=\"postgres://djuser:${DJPASS}@//cloudsql/${PROJECT_ID}:${REGION}:myinstance/mydatabase\" > .env echo GS_BUCKET_NAME=\"${GS_BUCKET_NAME}\" >> .env echo SECRET_KEY=\"$(cat /dev/urandom | LC_ALL=C tr -dc 'a-zA-Z0-9' | fold -w 50 | head -n 1)\" >> .env echo DEBUG=True >> .env
Затем создайте секрет под названием application_settings
, используя этот файл в качестве секрета:
gcloud secrets create application_settings --data-file .env
Разрешите учетной записи службы доступ к этому секрету:
gcloud secrets add-iam-policy-binding application_settings \ --member serviceAccount:${SERVICE_ACCOUNT} --role roles/secretmanager.secretAccessor
Подтвердите создание секрета, перечислив секреты:
gcloud secrets versions list application_settings
Убедившись, что секрет создан, удалите локальный файл:
rm .env
6. Настройте свое приложение
Созданный ранее шаблонный проект теперь нуждается в некоторых изменениях. Эти изменения упростят настройку параметров шаблонов, поставляемых с Wagtail, а также интегрируют Wagtail с ранее созданными вами службами поддержки.
Настройка параметров
Найдите сгенерированный файл настроек base.py
и переименуйте его в basesettings.py
в основной папке myproject
:
mv myproject/settings/base.py myproject/basesettings.py
С помощью веб-редактора Cloud Shell создайте новый файл settings.py
со следующим кодом:
touch myproject/settings.py cloudshell edit myproject/settings.py
мойпроект/settings.py
import io
import os
from urllib.parse import urlparse
import environ
# Import the original settings from each template
from .basesettings import *
# Load the settings from the environment variable
env = environ.Env()
env.read_env(io.StringIO(os.environ.get("APPLICATION_SETTINGS", None)))
# Setting this value from django-environ
SECRET_KEY = env("SECRET_KEY")
# Ensure myproject is added to the installed applications
if "myproject" not in INSTALLED_APPS:
INSTALLED_APPS.append("myproject")
# If defined, add service URLs to Django security settings
CLOUDRUN_SERVICE_URLS = env("CLOUDRUN_SERVICE_URLS", default=None)
if CLOUDRUN_SERVICE_URLS:
CSRF_TRUSTED_ORIGINS = env("CLOUDRUN_SERVICE_URLS").split(",")
# Remove the scheme from URLs for ALLOWED_HOSTS
ALLOWED_HOSTS = [urlparse(url).netloc for url in CSRF_TRUSTED_ORIGINS]
else:
ALLOWED_HOSTS = ["*"]
# Default false. True allows default landing pages to be visible
DEBUG = env("DEBUG", default=False)
# Set this value from django-environ
DATABASES = {"default": env.db()}
# Change database settings if using the Cloud SQL Auth Proxy
if os.getenv("USE_CLOUD_SQL_AUTH_PROXY", None):
DATABASES["default"]["HOST"] = "127.0.0.1"
DATABASES["default"]["PORT"] = 5432
# Define static storage via django-storages[google]
GS_BUCKET_NAME = env("GS_BUCKET_NAME")
STATICFILES_DIRS = []
GS_DEFAULT_ACL = "publicRead"
STORAGES = {
"default": {
"BACKEND": "storages.backends.gcloud.GoogleCloudStorage",
},
"staticfiles": {
"BACKEND": "storages.backends.gcloud.GoogleCloudStorage",
},
}
Потратьте время, чтобы прочитать комментарии, добавленные к каждой конфигурации.
Обратите внимание, что в этом файле вы можете увидеть ошибки линтинга. Это ожидаемо. Cloud Shell не имеет контекста требований для этого проекта и поэтому может сообщать о недопустимом импорте и неиспользуемом импорте.
Затем удалите старую папку настроек.
rm -rf myproject/settings/
После этого у вас будет два файла настроек: один из Wagtail и другой, который вы только что создали и созданный на основе этих настроек:
ls myproject/*settings*
myproject/basesettings.py myproject/settings.py
Наконец, откройте файл настроек manage.py
и обновите конфигурацию, чтобы Wagtail указал на основной файл settings.py
.
cloudshell edit manage.py
строка Manage.py (до)
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings.dev")
строка Manage.py (после)
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")
Внесите такое же изменение конфигурации в файл myproject/wsgi.py
:
cloudshell edit myproject/wsgi.py
строка myproject/wsgi.py (ранее)
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings.dev")
строка myproject/wsgi.py (после)
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")
Удалите автоматически созданный Dockerfile:
rm Dockerfile
Зависимости Python
Найдите файл requirements.txt
и добавьте следующие пакеты:
cloudshell edit requirements.txt
требования.txt (добавить)
gunicorn psycopg2-binary django-storages[google] django-environ
Определите образ вашего приложения
Cloud Run будет запускать любой контейнер, если он соответствует Контракту Cloud Run Container . В этом руководстве мы решили не использовать Dockerfile
, а вместо этого использовать Cloud Native Buildpacks . Пакеты сборки помогают создавать контейнеры для распространенных языков, включая Python.
В этом руководстве предлагается настроить Procfile
используемый для запуска веб-приложения.
Чтобы контейнеризировать проект-шаблон, сначала создайте новый файл с именем Procfile
на верхнем уровне вашего проекта (в том же каталоге, что и manage.py
) и скопируйте следующее содержимое:
touch Procfile cloudshell edit Procfile
Прокфайл
web: gunicorn --bind 0.0.0.0:$PORT --workers 1 --threads 8 --timeout 0 myproject.wsgi:application
7. Настройте, создайте и запустите этапы миграции.
Чтобы создать схему базы данных в базе данных Cloud SQL и заполнить корзину Cloud Storage статическими ресурсами, вам необходимо запустить migrate
collectstatic
.
Эти базовые команды миграции Django необходимо запускать в контексте созданного вами образа контейнера с доступом к вашей базе данных.
Вам также потребуется запустить createsuperuser
, чтобы создать учетную запись администратора для входа в систему администратора Django.
Для этого вы будете использовать Cloud Run Jobs для выполнения этих задач. Задания Cloud Run позволяют запускать процессы с определенным завершением, что делает их идеальными для задач администрирования.
Определите свой пароль суперпользователя Django
Чтобы создать суперпользователя, вы будете использовать неинтерактивную версию команды createsuperuser
. Для этой команды требуется переменная среды со специальным именем, которую можно использовать вместо запроса на ввод пароля.
Создайте новый секрет, используя случайно сгенерированный пароль:
echo -n $(cat /dev/urandom | LC_ALL=C tr -dc 'a-zA-Z0-9' | fold -w 30 | head -n 1) | gcloud secrets create django_superuser_password --data-file=-
Разрешите вашему сервисному аккаунту доступ к этому секрету:
gcloud secrets add-iam-policy-binding django_superuser_password \ --member serviceAccount:${SERVICE_ACCOUNT} \ --role roles/secretmanager.secretAccessor
Обновите свой профиль
Чтобы сделать ваши задания Cloud Run более понятными, создайте ярлыки в вашем Procfile и добавьте в Procfile
следующие точки входа:
migrate: python manage.py migrate && python manage.py collectstatic --noinput --clear createuser: python manage.py createsuperuser --username admin --email noop@example.com --noinput
Теперь у вас должно быть три записи: точка входа web
по умолчанию, точка входа migrate
для применения миграции базы данных и точка входа createuser
для запуска команды createsuperuser
.
Создайте образ своего приложения
Имея обновления Procfile, создайте образ:
gcloud builds submit --pack image=${ARTIFACT_REGISTRY}/myimage
Создание заданий Cloud Run
Теперь, когда образ существует, вы можете создавать с его помощью задания Cloud Run.
Эти задания используют ранее созданный образ, но используют другие значения command
. Они соответствуют значениям в Procfile
.
Создайте задание для миграции:
gcloud run jobs create migrate \ --region $REGION \ --image ${ARTIFACT_REGISTRY}/myimage \ --set-cloudsql-instances ${PROJECT_ID}:${REGION}:myinstance \ --set-secrets APPLICATION_SETTINGS=application_settings:latest \ --service-account $SERVICE_ACCOUNT \ --command migrate
Создайте задание на создание пользователя:
gcloud run jobs create createuser \ --region $REGION \ --image ${ARTIFACT_REGISTRY}/myimage \ --set-cloudsql-instances ${PROJECT_ID}:${REGION}:myinstance \ --set-secrets APPLICATION_SETTINGS=application_settings:latest \ --set-secrets DJANGO_SUPERUSER_PASSWORD=django_superuser_password:latest \ --service-account $SERVICE_ACCOUNT \ --command createuser
Выполнение заданий Cloud Run
Имея настройки задания, запустите миграцию:
gcloud run jobs execute migrate --region $REGION --wait
Убедитесь, что в выводе этой команды указано, что выполнение «успешно завершено».
Вы запустите эту команду позже, когда будете обновлять свое приложение.
После настройки базы данных создайте пользователя, используя задание:
gcloud run jobs execute createuser --region $REGION --wait
Убедитесь, что в выводе этой команды указано, что выполнение «успешно завершено».
Вам не придется запускать эту команду еще раз.
8. Развертывание в Cloud Run
Теперь, когда службы поддержки созданы и заполнены, вы можете создать службу Cloud Run для доступа к ним.
Первоначальное развертывание вашего контейнерного приложения в Cloud Run создается с помощью следующей команды:
gcloud run deploy wagtail-cloudrun \ --region $REGION \ --image ${ARTIFACT_REGISTRY}/myimage \ --set-cloudsql-instances ${PROJECT_ID}:${REGION}:myinstance \ --set-secrets APPLICATION_SETTINGS=application_settings:latest \ --service-account $SERVICE_ACCOUNT \ --allow-unauthenticated
Подождите несколько минут, пока развертывание не завершится. В случае успеха в командной строке отображается URL-адрес службы:
Service [wagtail-cloudrun] revision [wagtail-cloudrun-00001-...] has been deployed and is serving 100 percent of traffic. Service URL: https://wagtail-cloudrun-...run.app
Теперь вы можете посетить развернутый контейнер, открыв этот URL-адрес в веб-браузере:
9. Доступ к администратору Django
Обновление настроек CSRF
Django включает защиту от подделки межсайтовых запросов (CSRF) . Каждый раз, когда форма отправляется на ваш сайт Django, включая вход в систему администратора Django, проверяется настройка Trusted Origins. Если он не соответствует источнику запроса, Django возвращает ошибку.
Если в файле mysite/settings.py
определена переменная среды CLOUDRUN_SERVICE_URL
, она используется в настройках CSRF_TRUSTED_ORIGINS
и ALLOWED_HOSTS
. Хотя определение ALLOWED_HOSTS
не является обязательным, рекомендуется добавить его, поскольку оно уже требуется для CSRF_TRUSTED_ORIGINS
.
Поскольку вам нужен URL-адрес службы, эту конфигурацию можно добавить только после первого развертывания.
Вам придется обновить свою службу, чтобы добавить эту переменную среды. Его можно добавить в секрет application_settings
или добавить непосредственно как переменную среды.
В приведенной ниже реализации используются преимущества форматирования и экранирования gcloud.
Получите URL-адрес вашей службы:
CLOUDRUN_SERVICE_URLS=$(gcloud run services describe wagtail-cloudrun \ --region $REGION \ --format "value(metadata.annotations[\"run.googleapis.com/urls\"])" | tr -d '"[]') echo $CLOUDRUN_SERVICE_URLS
Установите это значение в качестве переменной среды в службе Cloud Run:
gcloud run services update wagtail-cloudrun \ --region $REGION \ --update-env-vars "^##^CLOUDRUN_SERVICE_URLS=$CLOUDRUN_SERVICE_URLS"
Вход в админку Django
Чтобы получить доступ к интерфейсу администратора Django, добавьте /admin
к URL-адресу вашего сервиса.
Теперь войдите в систему под именем пользователя «admin» и получите свой пароль с помощью следующей команды:
gcloud secrets versions access latest --secret django_superuser_password && echo ""
10. Разработка вашего приложения
По мере разработки приложения вам захочется протестировать его локально. Для этого вам нужно будет подключиться либо к вашей («производственной») базе данных Cloud SQL, либо к локальной («тестовой») базе данных.
Подключитесь к вашей производственной базе данных
Вы можете подключиться к своим экземплярам Cloud SQL с помощью прокси-сервера аутентификации Cloud SQL . Это приложение создает соединение вашего локального компьютера с базой данных.
После установки прокси-сервера Cloud SQL Auth выполните следующие действия:
# Create a virtualenv virtualenv venv source venv/bin/activate pip install -r requirements.txt # Copy the application settings to your local machine gcloud secrets versions access latest --secret application_settings > temp_settings # Run the Cloud SQL Auth Proxy ./cloud-sql-proxy ${PROJECT_ID}:${REGION}:myinstance # In a new tab, start the local web server using these new settings USE_CLOUD_SQL_AUTH_PROXY=true APPLICATION_SETTINGS=$(cat temp_settings) python manage.py runserver
Обязательно удалите файл temp_settings
после завершения работы.
Подключиться к локальной базе данных SQLite
Альтернативно вы можете использовать локальную базу данных при разработке приложения. Django поддерживает базы данных как PostgreSQL, так и SQLite, и есть некоторые функции PostgreSQL, которых нет в SQLite, но во многих случаях функциональность идентична.
Чтобы настроить SQLite, вам придется обновить настройки приложения, чтобы указать на локальную базу данных, а затем вам придется применить миграцию схемы.
Чтобы настроить этот метод:
# Create a virtualenv virtualenv venv source venv/bin/activate pip install -r requirements.txt # Copy the application settings to your local machine gcloud secrets versions access latest --secret application_settings > temp_settings # Edit the DATABASE_URL setting to use a local sqlite file. For example: DATABASE_URL=sqlite:////tmp/my-tmp-sqlite.db # Set the updated settings as an environment variable APPLICATION_SETTINGS=$(cat temp_settings) # Apply migrations to the local database python manage.py migrate # Start the local web server python manage.py runserver
Обязательно удалите файл temp_settings
после завершения работы.
Создание миграций
При внесении изменений в модели базы данных вам может потребоваться создать файлы миграции Django, запустив python manage.py makemigrations
.
Вы можете запустить эту команду после настройки производственного или тестового подключения к базе данных. Альтернативно вы можете сгенерировать файлы миграции без базы данных, указав пустые настройки:
SECRET_KEY="" DATABASE_URL="" GS_BUCKET_NAME="" python manage.py makemigrations
Применение обновлений приложения
Чтобы применить изменения к вашему заявлению, вам необходимо:
- внесите свои изменения в новое изображение,
- применить любую базу данных или статическую миграцию, а затем
- обновите службу Cloud Run, чтобы использовать новый образ.
Чтобы создать свой имидж:
gcloud builds submit --pack image=${ARTIFACT_REGISTRY}/myimage
Если вам нужно применить какие-либо миграции, запустите задание Cloud Run:
gcloud run jobs execute migrate --region $REGION --wait
Чтобы обновить службу новым образом:
gcloud run services update wagtail-cloudrun \ --region $REGION \ --image ${ARTIFACT_REGISTRY}/myimage
11. Поздравляем!
Вы только что развернули сложный проект в Cloud Run!
- Cloud Run автоматически и горизонтально масштабирует образ контейнера для обработки полученных запросов, а затем уменьшает масштаб, когда спрос снижается. Вы платите только за процессор, память и сеть, использованные во время обработки запроса.
- Cloud SQL позволяет вам предоставить управляемый экземпляр PostgreSQL, который автоматически поддерживается для вас и изначально интегрируется во многие системы Google Cloud.
- Облачное хранилище позволяет вам иметь облачное хранилище таким образом, чтобы оно было легко доступно в Django.
- Secret Manager позволяет вам хранить секреты и делать их доступными для определенных частей Google Cloud, а не для других.
Очистить
Чтобы избежать списания средств с вашей учетной записи Google Cloud Platform за ресурсы, используемые в этом руководстве:
- В Cloud Console перейдите на страницу «Управление ресурсами» .
- В списке проектов выберите свой проект и нажмите «Удалить» .
- В диалоговом окне введите идентификатор проекта и нажмите «Завершить работу», чтобы удалить проект.
Узнать больше
- Django в Cloud Run: https://cloud.google.com/python/django/run
- Привет, Cloud Run с Python: https://codelabs.developers.google.com/codelabs/cloud-run-hello-python3
- Python в Google Cloud: https://cloud.google.com/python
- Клиент Google Cloud Python: https://github.com/googleapis/google-cloud-python.
/