דף זה תורגם על ידי Cloud Translation API.

Django ב-Cloud Run

1. מבוא

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

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

Django הוא framework ברמה גבוהה של אתרי Python.

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

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

מה תלמדו

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

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

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

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

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

בשלב הבא צריך להפעיל את החיוב במסוף Cloud כדי להשתמש במשאבים או בממשקי API של Cloud. מעבר ב-Codelab הזה לא יעלה הרבה כסף, אם בכלל. כדי להשבית משאבים ולא לצבור חיובים מעבר למדריך הזה, אתם יכולים למחוק את המשאבים שיצרתם או למחוק את הפרויקט. משתמשים חדשים ב-Google Cloud זכאים להשתתף בתוכנית תקופת ניסיון בחינם בשווי 1,200 ש"ח.

Google Cloud Shell

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

הפעלת Cloud Shell

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

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

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

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

אחרי ההתחברות ל-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. הפעלת ממשקי 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. יצירת פרויקט בתבנית

המערכת תשתמש בתבנית ברירת המחדל של פרויקט Django בתור פרויקט Django לדוגמה.

כדי ליצור את פרויקט התבנית הזה, משתמשים ב-Cloud Shell כדי ליצור ספרייה חדשה בשם django-cloudrun ולעבור אליה:

mkdir ~/django-cloudrun
cd ~/django-cloudrun

לאחר מכן, התקינו את Django בסביבה וירטואלית זמנית:

virtualenv venv
source venv/bin/activate
pip install Django

שמירה של רשימת החבילות שמותקנות ב-requirements.txt

pip freeze > requirements.txt

הרשימה צריכה לכלול את Django ואת יחסי התלות שלו: sqlparse ו-asgiref.

לאחר מכן, יוצרים פרויקט תבנית חדש:

django-admin startproject myproject .

ייפתח קובץ חדש בשם manage.py ותיקייה חדשה בשם myproject שתכיל כמה קבצים, כולל settings.py.

מוודאים שתוכן התיקייה ברמה העליונה הוא כצפוי:

ls -F

manage.py myproject/ requirements.txt venv/

יש לוודא שהתוכן של התיקייה myproject הוא תקין:

ls -F myproject/

__init__.py asgi.py settings.py  urls.py  wsgi.py

עכשיו אתם יכולים לצאת מהסביבה הווירטואלית הזמנית ולהסיר אותה:

deactivate
rm -rf venv

מכאן, תתבצע קריאה ל-Django בתוך הקונטיינר.

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

אחסון הגדרות אישיות כסוד

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

תצטרכו לבצע כמה שינויים בפרויקט התבנית בהתאם לשירותי הגיבוי שיצרתם.

כחלק מהפעולה הזו, צריך להכניס את django-environ לשימוש במשתני סביבה כהגדרות התצורה, שייכנסו לך עם הערכים שהגדרת כסודות. כדי ליישם את האפשרות הזו, נרחיב את הגדרות התבנית. תצטרכו להוסיף גם יחסי תלות של Python.

קביעת הגדרות

מעבירים את הקובץ settings.py ומשנים את השם שלו ל-basesettings.py:

mv myproject/settings.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 URL to Django security settings
CLOUDRUN_SERVICE_URL = env("CLOUDRUN_SERVICE_URL", default=None)
if CLOUDRUN_SERVICE_URL:
    ALLOWED_HOSTS = [urlparse(CLOUDRUN_SERVICE_URL).netloc]
    CSRF_TRUSTED_ORIGINS = [CLOUDRUN_SERVICE_URL]
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 = []
DEFAULT_FILE_STORAGE = "storages.backends.gcloud.GoogleCloudStorage"
STATICFILES_STORAGE = "storages.backends.gcloud.GoogleCloudStorage"
GS_DEFAULT_ACL = "publicRead"

כדאי להקדיש זמן לקריאת הפרשנות שנוספה לגבי כל הגדרה.

שימו לב: ייתכן שיהיו שגיאות של איתור שגיאות בקוד (linting) בקובץ הזה. זו תופעה נורמלית. ל-Cloud Shell אין הקשר לדרישות של הפרויקט הזה, ולכן יכול להיות שידווחו על ייבוא לא חוקי ועל ייבוא שלא נעשה בו שימוש.

יחסי תלות של 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 צריכות לרוץ בהקשר של קובץ האימג' שנוצר בקונטיינר עם גישה למסד הנתונים שלכם.

כדי ליצור חשבון אדמין ולהתחבר לאדמין של Django, צריך גם להריץ את createsuperuser.

לשם כך, צריך להשתמש במשימות של 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

עכשיו אמורות להיות לכם שלוש רשומות: נקודת הכניסה שמוגדרת כברירת מחדל באינטרנט, נקודת הכניסה 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 django-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 [django-cloudrun] revision [django-cloudrun-00001-...] has been deployed and is serving 100 percent of traffic.
Service URL: https://django-cloudrun-...-uc.a.run.app

עכשיו אפשר להיכנס למאגר התגים שנפרס על ידי פתיחת כתובת ה-URL הבאה בדפדפן אינטרנט:

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

אחת התכונות העיקריות של Django היא האדמין האינטראקטיבי.

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

Django כולל הגנות מפני Cross-Site Request Forgery (CSRF). בכל פעם שנשלח טופס באתר Django, כולל התחברות לאדמין של Django, ההגדרה 'מקורות מהימנים' נבדקת. אם הוא לא תואם למקור הבקשה, Django יחזיר שגיאה.

בקובץ mysite/settings.py, אם מוגדר משתנה הסביבה CLOUDRUN_SERVICE_URL, נעשה בו שימוש בהגדרות CSRF_TRUSTED_ORIGINS ו-ALLOWED_HOSTS. ההגדרה של ALLOWED_HOSTS לא חובה, אבל מומלץ להוסיף אותה כי היא כבר נדרשת בשביל CSRF_TRUSTED_ORIGINS.

בגלל שדרושה לך כתובת ה-URL של השירות, לא ניתן להוסיף את התצורה הזו עד לאחר הפריסה הראשונה.

צריך לעדכן את השירות כדי להוסיף את משתנה הסביבה הזה. אפשר להוסיף אותו לסוד של application_settings, או להוסיף אותו ישירות כמשתנה סביבה.

מאחזרים את כתובת ה-URL של השירות:

CLOUDRUN_SERVICE_URL=$(gcloud run services describe django-cloudrun \
  --platform managed \
  --region $REGION  \
  --format "value(status.url)")
echo $CLOUDRUN_SERVICE_URL

מגדירים את הערך הזה כמשתנה סביבה בשירות Cloud Run:

gcloud run services update django-cloudrun \
  --region $REGION \
  --update-env-vars CLOUDRUN_SERVICE_URL=$CLOUDRUN_SERVICE_URL

כניסה לאדמין של Django

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

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

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

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

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

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

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

אחרי שמתקינים את Cloud SQL Auth Proxy, פועלים לפי השלבים הבאים:

# 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 django-cloudrun \
  --platform managed \
  --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.

מידע נוסף

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
לקוח Python ל-Google Cloud: https://github.com/googleapis/google-cloud-python