מידע על Codelab זה
1. מבוא
Cloud Run היא פלטפורמת מחשוב מנוהלת שמאפשרת להריץ קונטיינרים ללא שמירת מצב שאפשר להפעיל באמצעות בקשות HTTP. Cloud Run הוא ללא שרת (serverless): הוא מפשט את כל ניהול התשתית, כך שאתם יכולים להתמקד במה שהכי חשוב – פיתוח אפליקציות מעולות.
בנוסף, יש לו ממשק מקורי עם חלקים רבים אחרים בסביבה העסקית של Google Cloud, כולל Cloud SQL למסדי נתונים מנוהלים, Cloud Storage לאחסון אובייקטים מאוחד ו-Secret Manager לניהול סודות.
Django הוא מסגרת אינטרנט ברמה גבוהה ב-Python.
במדריך הזה תשתמשו ברכיבים האלו כדי לפרוס פרויקט Django קטן.
הערה: ה-Codelab הזה אומת לאחרונה באמצעות Django 5.0. ה-Codelab הזה אמור להמשיך לפעול, אלא אם יהיו שינויים שעלולים לגרום לכשלים בעדכונים הבאים. כדאי לעקוב אחרי הערות המוצר של גרסאות Django עתידיות.
מה תלמדו
- איך משתמשים ב-Cloud Shell
- איך יוצרים מסד נתונים ב-Cloud SQL
- איך יוצרים קטגוריה של Cloud Storage
- איך יוצרים סודות ב-Secret Manager
- איך משתמשים ב-Secrets משירותי Google Cloud שונים
- איך לחבר רכיבים של Google Cloud לשירות Cloud Run
- איך משתמשים ב-Container Registry לאחסון קונטיינרים שנוצרו
- איך פורסים ב-Cloud Run
- איך מריצים העברות של סכימות של מסדי נתונים ב-Cloud Build
2. הגדרה ודרישות
הגדרת סביבה בקצב אישי
- נכנסים למסוף Google Cloud ויוצרים פרויקט חדש או עושים שימוש חוזר בפרויקט קיים. אם עדיין אין לכם חשבון Gmail או חשבון Google Workspace, עליכם ליצור חשבון.
- שם הפרויקט הוא השם המוצג של המשתתפים בפרויקט. זו מחרוזת תווים שלא משמשת את Google APIs. תמיד אפשר לעדכן אותו.
- מזהה הפרויקט הוא ייחודי לכל הפרויקטים ב-Google Cloud ואי אפשר לשנות אותו אחרי שמגדירים אותו. מסוף Cloud יוצר מחרוזת ייחודית באופן אוטומטי; בדרך כלל לא מעניין אותך מה זה. ברוב ה-codelabs תצטרכו להפנות למזהה הפרויקט שלכם (בדרך כלל מזוהה כ-
PROJECT_ID
). אם המזהה שנוצר לא מוצא חן בעיניכם, אתם יכולים ליצור מזהה אקראי אחר. לחלופין, אפשר לנסות כתובת משלכם ולבדוק אם היא זמינה. לא ניתן לשנות אותו אחרי השלב הזה, והוא נשאר למשך הפרויקט. - לידיעתך, יש ערך שלישי, מספר פרויקט, שמשתמשים בו בממשקי API מסוימים. מידע נוסף על כל שלושת הערכים האלה זמין במסמכי העזרה.
- בשלב הבא, כדי להשתמש במשאבים או ב-API של Cloud, תצטרכו להפעיל את החיוב במסוף Cloud. מעבר ב-Codelab הזה לא יעלה הרבה כסף, אם בכלל. כדי להשבית את המשאבים ולמנוע חיובים אחרי סיום המדריך, אפשר למחוק את המשאבים שיצרתם או למחוק את הפרויקט. משתמשים חדשים ב-Google Cloud זכאים להצטרף לתוכנית תקופת ניסיון בחינם בשווי 1,200 ש"ח.
Google Cloud Shell
אומנם אפשר להפעיל את Google Cloud מרחוק מהמחשב הנייד, אבל ב-Codelab הזה נשתמש ב-Google Cloud Shell, סביבת שורת הפקודה שפועלת ב-Cloud.
הפעלת Cloud Shell
- במסוף Cloud, לוחצים על Activate Cloud Shell
.
אם זו הפעם הראשונה שאתם מפעילים את Cloud Shell, יוצג מסך ביניים עם תיאור של השירות. אם יוצג מסך ביניים, לוחצים על Continue (המשך).
ההקצאה וההתחברות ל-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 API לרכיבים שבהם רוצים להשתמש ב-Cloud Shell:
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
זו הפעם הראשונה שאתם קוראים ל-APIs מ-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 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",
},
}
כדאי להקדיש זמן לקריאת ההערות שנוספו לגבי כל הגדרה.
שימו לב: ייתכן שיהיו שגיאות של איתור שגיאות בקוד (linting) בקובץ הזה. זו תופעה נורמלית. ל-Cloud Shell אין הקשר של הדרישות לפרויקט הזה, ולכן יכול להיות שהוא ידווח על ייבוא לא חוקי ועל ייבוא שלא נעשה בו שימוש.
יחסי תלות ב-Python
מאתרים את הקובץ requirements.txt
ומצרפים את החבילות הבאות:
cloudshell edit requirements.txt
requirements.txt (append)
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 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
עדכון של 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 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-...run.app
עכשיו אפשר להיכנס לקונטיינר שנפרס על ידי פתיחת כתובת ה-URL הזו בדפדפן אינטרנט:
9. גישה ל-Django Admin
אחת מהתכונות העיקריות של 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 django-cloudrun \ --region $REGION \ --format "value(metadata.annotations[\"run.googleapis.com/urls\"])" | tr -d '"[]') echo $CLOUDRUN_SERVICE_URLS
מגדירים את הערך הזה כמשתנה סביבה בשירות Cloud Run:
gcloud run services update django-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 ""
10. פיתוח האפליקציה
במהלך הפיתוח של האפליקציה, כדאי לבדוק אותה באופן מקומי. לשם כך, צריך להתחבר למסד הנתונים של Cloud SQL ('ייצור') או למסד נתונים מקומי ('בדיקה').
חיבור למסד הנתונים בסביבת הייצור
תוכלו להתחבר למכונות של Cloud SQL באמצעות Cloud SQL Auth Proxy. האפליקציה הזו יוצרת חיבור מהמכונה המקומית שלכם למסד הנתונים.
אחרי שמתקינים את שרת ה-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 ${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 django-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.
מידע נוסף
- 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