Wagtail ב-Cloud Run

1. מבוא

894762ebb681671c.png

Cloud Run היא פלטפורמת מחשוב מנוהלת שמאפשרת להריץ קונטיינרים ללא שמירת מצב, שניתן להפעיל באמצעות בקשות HTTP. Cloud Run הוא שירות ללא שרת: הוא מספק שירותי ניהול תשתית באופן מופשט, כדי שתוכלו להתמקד במה שהכי חשוב – פיתוח אפליקציות מעולות.

בנוסף, יש לו ממשק מקורי עם חלקים רבים אחרים בסביבה העסקית של Google Cloud, כולל Cloud SQL למסדי נתונים מנוהלים, Cloud Storage לאחסון אובייקטים מאוחד ו-Secret Manager לניהול סודות.

Wagtail היא מערכת ניהול תוכן (CMS) בקוד פתוח שמבוססת על Django. Django הוא מסגרת אינטרנט ברמה גבוהה ב-Python.

במדריך הזה תשתמשו ברכיבים האלה כדי לפרוס פרויקט Wagtail קטן.

הערה: ה-Codelab הזה אומת לאחרונה באמצעות Wagtail 5.2.2, שתומך ב-Django 5.

מה תלמדו

  • איך משתמשים ב-Cloud Shell
  • איך יוצרים מסד נתונים ב-Cloud SQL
  • איך יוצרים קטגוריה של Cloud Storage
  • איך יוצרים סודות ב-Secret Manager
  • איך משתמשים ב-Secrets משירותי Google Cloud שונים
  • איך מחברים רכיבים של Google Cloud לשירות של Cloud Run
  • איך משתמשים ב-Container Registry לאחסון קונטיינרים שנוצרו
  • איך לפרוס ב-Cloud Run
  • איך מפעילים העברות של סכימות של מסד נתונים ב-Cloud Build

2. הגדרה ודרישות

הגדרת סביבה בקצב עצמאי

  1. נכנסים למסוף Google Cloud ויוצרים פרויקט חדש או עושים שימוש חוזר בפרויקט קיים. אם עדיין אין לכם חשבון Gmail או חשבון Google Workspace, עליכם ליצור חשבון.

fbef9caa1602edd0.png

a99b7ace416376c4.png

5e3ff691252acf41.png

  • Project name הוא השם המוצג של המשתתפים בפרויקט. זו מחרוזת תווים שלא משמשת את Google APIs. תמיד אפשר לעדכן.
  • מזהה הפרויקט הוא ייחודי לכל הפרויקטים ב-Google Cloud ואי אפשר לשנות אותו אחרי שמגדירים אותו. מסוף Cloud יוצר מחרוזת ייחודית באופן אוטומטי. בדרך כלל לא משנה מה המחרוזת הזו. ברוב ה-codelabs תצטרכו להפנות למזהה הפרויקט (בדרך כלל מזהים אותו בתור PROJECT_ID). אם המזהה שנוצר לא מוצא חן בעיניכם, תוכלו ליצור מזהה אקראי אחר. לחלופין, אפשר לנסות כתובת משלכם ולבדוק אם היא זמינה. לא ניתן לשנות אותו אחרי השלב הזה, והוא נשאר למשך הפרויקט.
  • לידיעתך, יש ערך שלישי, מספר פרויקט, שמשתמשים בו בממשקי API מסוימים. מידע נוסף על כל שלושת הערכים האלה זמין במסמכי העזרה.
  1. בשלב הבא, תצטרכו להפעיל את החיוב במסוף Cloud כדי להשתמש במשאבים או ב-API של Cloud. מעבר ב-Codelab הזה לא יעלה הרבה כסף, אם בכלל. כדי להשבית משאבים ולא לצבור חיובים מעבר למדריך הזה, אתם יכולים למחוק את המשאבים שיצרתם או למחוק את הפרויקט. משתמשים חדשים ב-Google Cloud זכאים להשתתף בתוכנית תקופת ניסיון בחינם בשווי 1,200 ש"ח.

Google Cloud Shell

אפשר להפעיל את Google Cloud מרחוק מהמחשב הנייד, אבל בסדנת הקוד הזו נשתמש ב-Google Cloud Shell, סביבת שורת פקודה שפועלת ב-Cloud.

הפעלת Cloud Shell

  1. במסוף Cloud, לוחצים על Activate Cloud Shell 853e55310c205094.png.

3c1dabeca90e44e5.png

אם זו הפעם הראשונה שאתם מפעילים את Cloud Shell, יוצג לכם מסך ביניים שמתוארת בו. אם הוצג לכם מסך ביניים, לוחצים על המשך.

9c92662c6a846a5c.png

ההקצאה וההתחברות ל-Cloud Shell נמשכת כמה דקות.

9f0e51b578fecce5.png

המכונה הווירטואלית הזו כוללת את כל הכלים הנדרשים לפיתוח. יש בה ספריית בית בנפח מתמיד של 5GB והיא פועלת ב-Google Cloud, מה שמשפר משמעותית את ביצועי הרשת והאימות. אם לא את כולן, ניתן לבצע חלק גדול מהעבודה ב-Codelab הזה באמצעות דפדפן.

אחרי שתתחברו ל-Cloud Shell, אמורה להופיע הודעה על כך שהאימות בוצע והפרויקט מוגדר לפי מזהה הפרויקט שלכם.

  1. מריצים את הפקודה הבאה ב-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`
  1. מריצים את הפקודה הבאה ב-Cloud Shell כדי לוודא שהפקודה gcloud מכירה את הפרויקט:
gcloud config list project

פלט הפקודה

[core]
project = <PROJECT_ID>

אם לא, אפשר להגדיר אותו באמצעות הפקודה הבאה:

gcloud config set project <PROJECT_ID>

פלט הפקודה

Updated property [core/project].

3. הפעלת ממשקי Cloud 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. יצירת שירותי התמיכה

עכשיו נוצר את שירותי התמיכה: חשבון שירות ייעודי, Artifact Registry, מסד נתונים של 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

את החשבון הזה תפנה לכתובת האימייל שלו בקטעים עתידיים ב-Codelab הזה. מגדירים את הערך הזה במשתנה סביבה:

SERVICE_ACCOUNT=$(gcloud iam service-accounts list \
    --filter cloudrun-serviceaccount --format "value(email)")

יצירת Artifact Registry

כדי לאחסן את קובץ האימג' של הקונטיינר שנוצר, יוצרים מרשם קונטיינרים באזור הרצוי:

gcloud artifacts repositories create containers --repository-format docker --location $REGION

עליך להשתמש במרשם הזה לפי שמו בקטעים עתידיים ב-Codelab הזה:

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 אפשר לאחסן סודות, לנהל אותם ולגשת אליהם כ-blobs בינאריים או כמחרוזות טקסט. הוא מתאים לאחסון פרטי הגדרה כמו סיסמאות של מסדי נתונים, מפתחות 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

יוצרים קובץ settings.py חדש באמצעות עורך האינטרנט של Cloud Shell, עם הקוד הבא:

touch myproject/settings.py
cloudshell edit myproject/settings.py

myproject/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

management.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 line (before)

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings.dev")

myproject/wsgi.py line (אחרי)

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")

מסירים את קובץ Dockerfile שנוצר באופן אוטומטי:

rm Dockerfile

יחסי תלות של Python

מאתרים את הקובץ requirements.txt ומצרפים את החבילות הבאות:

cloudshell edit requirements.txt

requirements.txt (צירוף)

gunicorn
psycopg2-binary
django-storages[google]
django-environ

הגדרת קובץ האימג' של האפליקציה

Cloud Run יריץ כל קונטיינר כל עוד הוא תואם לחוזה הקונטיינרים של Cloud Run. במדריך הזה לא נעשה שימוש ב-Dockerfile, אלא ב-Cloud Native Buildpacks. ה-buildpacks עוזר לפתח קונטיינרים לשפות נפוצות, כולל Python.

במדריך הזה בוחרים להתאים אישית את Procfile שמשמש להפעלת אפליקציית האינטרנט.

כדי לארוז את פרויקט התבנית בקונטיינר, קודם יוצרים קובץ חדש בשם Procfile ברמה העליונה של הפרויקט (באותה ספרייה שבה נמצא הקובץ manage.py) ומעתיקים את התוכן הבא:

touch Procfile
cloudshell edit Procfile

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 כדי לבצע את המשימות האלה. המשימות ב-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

עדכון ה-Procfile

כדי ליצור משימות ברורות יותר ב-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 הבאה בדפדפן אינטרנט:

c2f23d1f5b97a79a.png

9. גישה לאדמין של Django

עדכון הגדרות CSRF

Django כולל הגנות מפני זיוף בקשות בין אתרים (CSRF). בכל פעם שנשלח טופס באתר Django, כולל התחברות לאדמין של Django, ההגדרה 'מקורות מהימנים' נבדקת. אם הוא לא תואם למקור הבקשה, 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 Admin

כדי לגשת לממשק האדמין של Django, צריך להוסיף את הערך /admin לכתובת ה-URL של השירות.

עכשיו מתחברים באמצעות שם המשתמש 'admin' ומאחזרים את הסיסמה באמצעות הפקודה הבאה:

gcloud secrets versions access latest --secret django_superuser_password && echo ""

2b9139acc7208827.png

8ad565366c53ba3c.png

10. פיתוח האפליקציה

במהלך הפיתוח של האפליקציה, כדאי לבדוק אותה באופן מקומי. לשם כך, צריך להתחבר למסד הנתונים של Cloud SQL ('ייצור') או למסד נתונים מקומי ('בדיקה').

קישור למסד הנתונים בסביבת הייצור

אפשר להתחבר למכונות Cloud SQL באמצעות שרת proxy ל-Cloud SQL Auth. האפליקציה הזו יוצרת חיבור מהמכונה המקומית שלכם למסד הנתונים.

אחרי שמתקינים את שרת ה-proxy ל-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 --instances=${PROJECT_ID}:${REGION}:myinstance=tcp:5432

# 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 מגדיל את קובץ האימג' של הקונטיינר באופן אוטומטי ואופקי כדי לטפל בבקשות שהתקבלו, ולאחר מכן מצטמצם כשהביקוש יורד. התשלום הוא רק על המעבד (CPU), הזיכרון והרשת שנצרכו במהלך הטיפול בבקשות.
  • Cloud SQL מאפשר להקצות מכונה מנוהלת של PostgreSQL שמתוחזקת באופן אוטומטי, ומשלבת באופן מקורי עם מערכות רבות של Google Cloud.
  • Cloud Storage מאפשר לכם להשתמש באחסון בענן בצורה נגישה בצורה חלקה ב-Django.
  • באמצעות Secret Manager תוכלו לאחסן סודות ולאפשר גישה אליהם לחלקים מסוימים ב-Google Cloud ולא לאחרים.

ניקוי

כדי להימנע מצבירת חיובים בחשבון Google Cloud Platform על המשאבים שבהם השתמשתם במדריך הזה:

  • במסוף Cloud, עוברים לדף Manage resources.
  • ברשימת הפרויקטים, בוחרים את הפרויקט הרלוונטי ולוחצים על מחיקה.
  • כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

מידע נוסף

/