1. מבוא
תאריך עדכון אחרון: 1 בנובמבר 2024
איך מבצעים מודרניזציה של אפליקציית PHP ישנה ב-Google Cloud?
(📽️ סרטון מבוא של 7 דקות ל-Codelab הזה)
לרוב יש אפליקציות מדור קודם שפועלות בארגון וצריכות לעבור מודרניזציה. כלומר, צריך להפוך אותם להתאמה לעומס, מאובטחים וניתנים לפריסה בסביבות שונות.
בסדנה הזו תלמדו:
- העברה של אפליקציית ה-PHP לקונטיינר.
- מעבר לשירות מנוהל של מסד נתונים ( Cloud SQL).
- פריסה ב-Cloud Run (חלופה ל-GKE/Kubernetes ללא צורך בניהול).
- אבטחת האפליקציה באמצעות ניהול זהויות והרשאות גישה (IAM) ו-Secret Manager.
- הגדרת צינור עיבוד נתונים של CI/CD באמצעות Cloud Build. אפשר לחבר את Cloud Build למאגר ה-Git שמתארח אצל ספקי Git פופולריים כמו GitHub או GitLab, ולהפעיל אותו בכל דחיפה ל-main, לדוגמה.
- אירוח התמונות של האפליקציה ב-Cloud Storage. הדבר נעשה באמצעות הרכבה, ואין צורך בקוד כדי לשנות את האפליקציה.
- הצגת הפונקציונליות של AI גנרטיבי באמצעות Gemini, שמנוהלת באמצעות Cloud Functions (ללא שרת).
- כדאי להכיר את ה-SLO ואת הפעלת האפליקציה המעודכנת.
בעזרת השלבים האלה תוכלו לשדרג בהדרגה את אפליקציית ה-PHP שלכם, ולשפר את יכולת ההתאמה לעומס (scalability), האבטחה והגמישות שלה לפריסה. בנוסף, המעבר ל-Google Cloud מאפשר לכם להשתמש בתשתית ובשירותים החזקים שלו כדי להבטיח שהאפליקציה תפעל בצורה חלקה בסביבה מבוססת-ענן.
אנחנו מאמינים שתוכלו ליישם את מה שתלמדו בעזרת השלבים הפשוטים האלה באפליקציה ובארגון שלכם, עם שפה/סטאק שונים ותרחישי שימוש שונים.
מידע על האפליקציה
האפליקציה ( קוד, בכפוף לרישיון MIT) שתפצלו היא אפליקציה בסיסית של PHP 5.7 עם אימות MySQL. הרעיון המרכזי של האפליקציה הוא לספק פלטפורמה שבה משתמשים יכולים להעלות תמונות, ואדמינים יכולים לתייג תמונות לא הולמות. באפליקציה יש שתי טבלאות:
- משתמשים. מגיע עם אדמינים שנוצרו מראש. אנשים חדשים יכולים להירשם.
- תמונות. הספרייה כוללת כמה תמונות לדוגמה. משתמשים מחוברים יכולים להעלות תמונות חדשות. נוסיף כאן קצת קסם.
היעדים שלכם
אנחנו רוצים לבצע מודרניזציה של האפליקציה הישנה כדי להעביר אותה ל-Google Cloud. נשתמש בכלים ובשירותים שלו כדי לשפר את יכולת ההתאמה לעומס, לשפר את האבטחה, להפוך את ניהול התשתית לאוטומטי ולשלב תכונות מתקדמות כמו עיבוד תמונות, מעקב ואחסון נתונים באמצעות שירותים כמו Cloud SQL, Cloud Run, Cloud Build, Secret Manager ועוד.
חשוב מכך, אנחנו רוצים לעשות זאת שלב אחרי שלב כדי שתוכלו ללמוד מהו תהליך החשיבה שמאחורי כל שלב, ובדרך כלל כל שלב פותח אפשרויות חדשות לשלבים הבאים (לדוגמה: מודולים 2 -> 3 ו-6 -> 7).
עדיין לא השתכנעתם? מומלץ לצפות בסרטון של 7 דקות ב-YouTube.
מה צריך להכין
- מחשב מחובר לאינטרנט שמותקן בו דפדפן.
- חלק מהזיכויים ב-GCP. אפשר לבקש מחובבי Google המקומיים ;)
- הפקודה
gcloud
פועלת. - עובדים מקומית? אפשר להוריד אותו כאן. בנוסף, תצטרכו גם עורך נוח (למשל vscode או intellij).
- רוצים לעשות הכל "בענן"? לאחר מכן תוכלו להשתמש ב-Cloud Shell.
- משתמש ב-GitHub. צריך את זה כדי ליצור הסתעפות מהקוד המקורי 🧑🏻💻 gdgpescara/app-mod-workshop באמצעות מאגר git משלכם. הדבר נדרש כדי שיהיה לכם צינור עיבוד נתונים משלכם של CI/CD (התחייבות אוטומטית –> פיתוח –> פריסה)
פתרונות לדוגמה:
- המאגר של המחבר: https://github.com/Friends-of-Ricc/app-mod-workshop
- המאגר המקורי של הסדנה, בתיקיות
.solutions/
לכל פרק.
אפשר להשתתף בסדנה הזו מהמחשב המקומי או לחלוטין בדפדפן.
2. הגדרת קרדיט והסתעפות (fork)
מימוש הקרדיט ב-GCP והגדרת סביבת GCP [אופציונלי]
כדי להשתתף בסדנה הזו, צריך חשבון לחיוב עם זכות קרדיט. אם כבר יש לכם חיוב משלכם, אתם יכולים לדלג על השלב הזה.
יוצרים חשבון Google Gmail חדש (*) כדי לקשר אותו לזיכוי ב-GCP. אפשר לבקש מהמורה את הקישור למימוש הזיכוי ב-GCP או להשתמש בו כאן: bit.ly/PHP-Amarcord-credits .
נכנסים לחשבון החדש שנוצר ופועלים לפי ההוראות.
(
) למה צריך חשבון Gmail חדש לגמרי?*
ראינו אנשים שנכשלו בקודלאב כי החשבון שלהם (במיוחד כתובות האימייל שלהם לצורכי עבודה או של תלמידים) נחשף בעבר ל-GCP ומדיניות הארגון הגבילה את היכולת שלהם לעשות זאת. מומלץ ליצור חשבון Gmail חדש או להשתמש בחשבון Gmail קיים (gmail.com) ללא חשיפה קודמת ל-GCP.
לוחצים על הלחצן כדי לממש את הזיכוי.
יש למלא את הפרטים הבאים (שם פרטי ושם משפחה) בטופס הבא, ולאשר את התנאים וההגבלות.
יכול להיות שתצטרכו להמתין כמה שניות עד שחשבון החיוב יופיע כאן: https://console.cloud.google.com/billing
בסיום, פותחים את מסוף Google Cloud ויוצרים פרויקט חדש בלחיצה על בורר הפרויקטים בתפריט הנפתח שבפינה הימנית העליונה, שבו מוצג הכיתוב 'No organization' (ללא ארגון). מופיע בהמשך
יוצרים פרויקט חדש, אם אין לכם פרויקט, כפי שמוצג בצילום המסך שבהמשך. בפינה השמאלית העליונה מופיעה האפשרות 'פרויקט חדש'.
חשוב לקשר את הפרויקט החדש לחשבון לחיוב בתקופת הניסיון ב-GCP באופן הבא.
הכול מוכן לשימוש ב-Google Cloud Platform. אם אתם מתחילים או שאתם פשוט רוצים לעשות הכל בסביבת Cloud, תוכלו לגשת ל-Cloud Shell ולעורך שלו באמצעות הלחצן הבא בפינה הימנית העליונה, כפי שמוצג בהמשך.
מוודאים שהפרויקט החדש מסומן בפינה הימנית העליונה:
לא נבחר (שגיאה):
נבחר (טוב):
יצירת פורק (fork) של האפליקציה מ-GitHub
- נכנסים לאפליקציית הדגמה: https://github.com/gdgpescara/app-mod-workshop
- לוחצים על סמל המזלג 🍴.
- אם אין לכם חשבון GitHub, תצטרכו ליצור חשבון חדש.
- עורכים את הפריטים לפי הצורך.
- קלון של קוד האפליקציה באמצעות
git clone
https://github.com/
YOUR-GITHUB-USER/YOUR-REPO-NAME
- פותחים את תיקיית הפרויקט המשובט באמצעות העורך המועדף עליכם. אם בוחרים ב-Cloud Shell, לוחצים על Open Editor (פתיחת עורך) כפי שמוצג בהמשך.
ב-Google Cloud Shell Editor יש את כל מה שדרוש, כפי שמוצג באיור הבא
אפשר לעשות זאת באופן חזותי בלחיצה על 'פתיחת תיקייה' ובחירת התיקייה, כנראה app-mod-workshop
בתיקיית הבית.
3. מודול 1: יצירת מכונה של SQL
יצירת המכונה של Google Cloud SQL
אפליקציית ה-PHP שלנו תתחבר למסד נתונים של MySQL, ולכן אנחנו צריכים ליצור לה רפליקה ב-Google Cloud כדי להעביר אותה ללא בעיות. Cloud SQL הוא הפתרון המושלם, כי הוא מאפשר להריץ ב-Cloud מסד נתונים מנוהל של MySQL. כך עושים זאת:
- נכנסים לדף Cloud SQL: https://console.cloud.google.com/sql/instances
- לוחצים על 'Create Instance'.
- מפעילים את ה-API (אם צריך). התהליך עשוי להימשך כמה שניות.
- בוחרים באפשרות MySQL.
- (אנחנו מנסים לשלוח לך את הגרסה הזולה ביותר כדי שהיא תימשך זמן רב יותר):
- מהדורה: Enterprise
- הגדרה מוגדרת מראש: development (ניסינו את Sandbox והוא לא עבד בשבילנו)
- Mysql גרסה: 5.7 (וואו, חזרה במנהרת הזמן!)
- מזהה המכונה: בוחרים באפשרות
appmod-phpapp
(אם משנים את הערך הזה, חשוב לזכור לשנות בהתאם גם את הסקריפטים והפתרונות העתידיים). - סיסמה: כל סיסמה שתרצו, אבל חשוב לכתוב אותה כ-CLOUDSQL_INSTANCE_PASSWORD
- אזור: משאירים את אותו אזור שבחרתם בשאר האפליקציה (למשל, תל אביב =
europe-west8
) - זמן פרסום בתחום מוגדר: תחום אחד (אנחנו חוסכים כסף להדגמה)
לוחצים על הלחצן Create Instance כדי לפרוס את מסד הנתונים של Cloud SQL. ⌛ התהליך נמשך כ-10 דקות⌛. בינתיים, ממשיכים לקרוא את המסמך. אפשר גם להתחיל לפתור את המודול הבא ('ארגון האפליקציה בקונטיינרים') כי אין לו יחסי תלות במודול הזה בחלק הראשון (עד שמתקנים את החיבור למסד הנתונים).
הערה המכונה הזו אמורה לעלות לכם כ-7$ ליום. חשוב להקפיד להפעיל אותו מחדש אחרי הסדנה.
יצירת משתמש ומסד נתונים של image_catalog ב-Cloud SQL
פרויקט האפליקציה מגיע עם תיקייה db/
שמכילה שני קובצי SQL:
- 01_schema.sql : מכיל קוד SQL ליצירת שתי טבלאות שמכילות נתונים של משתמשים ותמונות.
- 02_seed.sql: קובץ שמכיל קוד SQL להוספת נתונים לטבלאות שנוצרו בשלבים הקודמים.
הקבצים האלה ישמשו בהמשך, אחרי יצירת מסד הנתונים image_catalog
. כדי לעשות זאת, מבצעים את השלבים הבאים:
- פותחים את המכונה ולוחצים על הכרטיסייה Databases:
- לוחצים על 'יצירת מסד נתונים'.
- קוראים לו
image_catalog
(כמו בהגדרות האפליקציה של PHP).
לאחר מכן יוצרים את משתמש מסד הנתונים. כך נוכל לבצע אימות במסד הנתונים image_catalog.
- עכשיו לוחצים על הכרטיסייה משתמשים.
- לוחצים על 'הוספת חשבון משתמש'.
- משתמש: נוצר אחד:
- שם המשתמש/ת:
appmod-phpapp-user
- סיסמה: בוחרים משהו שקל לזכור או לוחצים על 'יצירה'.
- משאירים את האפשרות Allow any host (%).
- לוחצים על 'הוספה'.
פתיחת מסד הנתונים לכתובות IP מוכרות
חשוב לזכור שכל מסדי הנתונים ב-Cloud SQL נוצרים כ'מבודדים'. צריך להגדיר רשת באופן מפורש כדי שאפשר יהיה לגשת אליה.
- לוחצים על המכונה.
- פותחים את התפריט 'חיבורים'.
- לוחצים על הכרטיסייה Networking.
- לוחצים בקטע 'רשתות מורשות'. עכשיו מוסיפים רשת (כלומר רשת משנה).
- בינתיים, נבחר הגדרות מהירות אבל לא מאובטחות כדי לאפשר לאפליקציה לפעול – כדאי להגביל אותה מאוחר יותר לכתובות ה-IP שאתם סומכים עליהן:
- שם: 'כל העולם – לא מאובטח'.
- רשת:
0.0.0.0/0"
(הערה: זהו החלק הלא מאובטח!) - לוחצים על 'סיום'.
- לוחצים על 'שמירה'.
התוצאה אמורה להיראות כך:
הערה הפתרון הזה הוא פשרה טובה לסיום הסדנה בזמן של O(hours). עם זאת, כדאי לעיין במסמך אבטחה כדי לאבטח את הפתרון בסביבת הייצור.
הגיע הזמן לבדוק את החיבור למסד הנתונים!
נבדוק אם המשתמש image_catalog
שיצרנו מקודם פועל.
נכנסים ל-Cloud SQL Studio בתוך המכונה ומזינים את מסד הנתונים, המשתמש והסיסמה שרוצים לאמת, כפי שמתואר בהמשך:
עכשיו אפשר לפתוח את עורך ה-SQL ולהמשיך לקטע הבא.
ייבוא מסד הנתונים מקוד המקור
משתמשים בעורך SQL כדי לייבא את הטבלאות image_catalog
עם הנתונים שלהן. מעתיקים את קוד ה-SQL מהקבצים במאגר ( 01_schema.sql ואז 02_seed.sql) ומריצים אותם ברצף, אחד אחרי השני.
לאחר מכן אמורות להופיע שתי טבלאות ב-image_catalog, users ו-images, כפי שמוצג בהמשך:
כדי לבדוק את זה, מריצים את הפקודה הבאה בעורך: select * from images;
חשוב גם לרשום את כתובת ה-IP הציבורית של המכונה של Cloud SQL, כי תצטרכו אותה בהמשך. כדי לקבל את כתובת ה-IP, עוברים לדף הראשי של המכונה של Cloud SQL בקטע Overview. (סקירה כללית > התחברות למכונה הזו > כתובת IP ציבורית).
4. מודול 2: אריזה בקונטיינר של אפליקציית PHP
אנחנו רוצים לפתח את האפליקציה הזו לענן.
כלומר, צריך לארוז את הקוד בקובץ ZIP כלשהו שמכיל את כל המידע הדרוש להרצה שלו ב-Cloud.
יש כמה דרכים לארוז את הקוד:
- Docker. פופולרי מאוד, אבל מורכב למדי להגדרה בצורה נכונה.
- Buildpacks. פחות פופולרי, אבל נוטה "לנחש באופן אוטומטי" מה צריך ליצור ומה צריך להריץ. לרוב זה פשוט עובד!
בהקשר של הסדנה הזו, נניח שאתם משתמשים ב-Docker.
אם בחרתם להשתמש ב-Cloud Shell, זה הזמן לפתוח אותו מחדש (לוחצים בפינה הימנית העליונה של מסוף Cloud).
הפקודה הזו אמורה לפתוח מעטפת נוחה בתחתית הדף, שבה צריך ליצור את ההסתעפות של הקוד בשלב ההגדרה.
Docker
אם אתם רוצים לשלוט בדברים, זה הפתרון בשבילכם. כדאי להשתמש באפשרות הזו כשצריך להגדיר ספריות ספציפיות ולהחדיר התנהגויות מסוימות שלא ברורות לכולם (chmod בהעלאות, קובץ הפעלה לא סטנדרטי באפליקציה וכו').
אנחנו רוצים לפרוס את האפליקציה בקונטיינרים ב-Cloud Run, לכן כדאי לעיין במסמכי העזרה הבאים. איך מעבירים אותו מ-PHP 8 ל-PHP 5.7? אולי אפשר להשתמש ב-Gemini לצורך זה. לחלופין, אפשר להשתמש בגרסה הזו שהוגדרה מראש:
הגרסה האחרונה של Dockerfile
זמינה כאן.
כדי לבדוק את האפליקציה שלנו באופן מקומי, אנחנו צריכים לשנות את הקובץ config.php כך שאפליקציית ה-PHP שלנו תתחבר למסד הנתונים של MySQL שזמין ב-Google CloudSQL. על סמך מה שהגדרתם קודם, ממלאים את הריקות:
<?php
// Database configuration
$db_host = '____________';
$db_name = '____________';
$db_user = '____________';
$db_pass = '____________';
try {
$pdo = new PDO("mysql:host=$db_host;dbname=$db_name", $db_user, $db_pass);
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
} catch (PDOException $e) {
die("Errore di connessione: " . $e->getMessage());
}
session_start();
?>
DB_HOST
היא כתובת ה-IP הציבורית של Cloud SQL. אפשר למצוא אותה במסוף SQL:
DB_NAME
לא אמור להשתנות:image_catalog
- הערך של
DB_USER
צריך להיותappmod-phpapp-user
DB_PASS
הוא משהו שבחרתם. מגדירים אותו במירכאות בודדות ומשתמשים בבריחה (escape) לפי הצורך.
כמו כן, אתם יכולים לתרגם את הקטעים הבודדים 🇮🇹 באיטלקית לאנגלית בעזרת Gemini!
בסדר, עכשיו שיש לכם את Dockerfile
והגדרתם את אפליקציית ה-PHP להתחבר למסד הנתונים, ננסה את זה!
מתקינים את Docker אם הוא עדיין לא מותקן ( קישור). אם אתם משתמשים ב-Cloud Shell, אין צורך בכך (כמה מגניב זה?).
עכשיו ננסה ליצור ולהריץ את אפליקציית ה-PHP בקונטיינר באמצעות פקודות ה-build וההרצה המתאימות של Docker.
# Build command - don't forget the final . This works if Dockerfile is inside the code folder:
$ docker build -t my-php-app-docker .
# Local Run command: most likely ports will be 8080:8080
$ docker run -it -p <CONTAINER_PORT>:<LOCAL_MACHINE_PORT> my-php-app-docker
אם הכול פועל כמו שצריך, אמורה להופיע דף האינטרנט הבא כשמחוברים למארח המקומי. האפליקציה פועלת עכשיו ביציאה 8080. לוחצים על הסמל 'תצוגה מקדימה באינטרנט' (דפדפן עם עין) ואז על תצוגה מקדימה ביציאה 8080 (או על 'שינוי יציאה' לכל יציאה אחרת).
בדיקת התוצאה בדפדפן
עכשיו האפליקציה אמורה להיראות כך:
אם תתחברו באמצעות Admin/admin123, אמור להופיע משהו כזה.
נהדר!!! מלבד הטקסט באיטלקית, הכול עובד! 🎉🎉🎉
אם ה-dockerization תקין אבל פרטי הכניסה של מסד הנתונים שגויים, יכול להיות שתקבלו הודעת שגיאה כזו:
כדאי לנסות שוב, כמעט הגעת!
שמירה ב-Artifact Registry [אופציונלי]
עכשיו אמורה להיות לכם אפליקציית PHP בקונטיינר שפועלת ומוכנה לפריסה בענן. בשלב הבא, אנחנו צריכים מקום בענן לאחסון קובץ האימג' של Docker שלנו, ולאפשר גישה לפריסה בשירותי Google Cloud כמו Cloud Run. פתרון האחסון הזה נקרא Artifact Registry, שירות מנוהל של Google Cloud שמיועד לאחסון ארטיפקטים של אפליקציות, כולל קובצי אימג' לקונטיינרים של Docker, חבילות Maven, מודולים של npm ועוד.
נשתמש בלחצן המתאים כדי ליצור מאגר ב-Google Cloud Artifact Registry.
בוחרים שם תקין, את הפורמט ואת האזור שמתאימים לאחסון הארטיפקטים.
חוזרים לתג של סביבת הפיתוח המקומית ומעבירים את קובץ האימג' בקונטיינר של האפליקציה למאגר Artifact Registry שיצרתם. כדי לעשות זאת, מריצים את הפקודות הבאות.
- docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]
- docker push TARGET_IMAGE[:TAG]
התוצאה אמורה להיראות כמו בצילום המסך הבא.
יופי 🎉🎉🎉 עכשיו אפשר לעבור לשלב הבא. לפני כן, כדאי להקדיש 2 דקות לניסיון העלאה/כניסה/יציאה ולהכיר את נקודות הקצה של האפליקציה.תצטרכו אותן בהמשך.
שגיאות אפשריות
אם אתם מקבלים שגיאות בקונטיינרים, נסו להשתמש ב-Gemini כדי להסביר את השגיאה ולתקן אותה. לשם כך, עליכם לספק את הפרטים הבאים:
- קובץ Dockerfile הנוכחי
- השגיאה שהתקבלה
- [אם צריך] קוד ה-PHP שבוצע.
הרשאות העלאה. כדאי לנסות גם את נקודת הקצה /upload.php
ולנסות להעלות תמונה. יכול להיות שתופיע השגיאה הבאה. אם כן, צריך לבצע תיקון chmod/chown
ב-Dockerfile
.
אזהרה: move_uploaded_file(uploads/image (3).png): failed to open stream: Permission denied in /var/www/html/upload.php on line 11
PDOException "could not find driver" (או "Errore di connessione: could not find driver"). מוודאים שב-Dockerfile יש את ספריות ה-PDO המתאימות ל-mysql (pdo_mysql
) כדי להתחבר למסד הנתונים. כאן תוכלו לקבל השראה מפתרונות.
לא ניתן להעביר את הבקשה לקצה העורפי. לא ניתן היה להתחבר לשרת ביציאה 8080. המשמעות היא שאתם חושפים כנראה את היציאה הלא נכונה. חשוב לוודא שחשפתם את היציאה שממנה Apache/Nginx מציעים שירות בפועל. זה לא טריוויאלי. אם אפשר, כדאי להגדיר את היציאה הזו כ-8080 (קל יותר לעבוד עם Cloud Run). אם רוצים לשמור על יציאה 80 (למשל, כי כך רוצה Apache), משתמשים בפקודה אחרת כדי להריץ אותה:
$ docker run -it -p 8080:80 # force 80
# Use the PORT environment variable in Apache configuration files.
# https://cloud.google.com/run/docs/reference/container-contract#port
RUN sed -i 's/80/${PORT}/g' /etc/apache2/sites-available/000-default.conf /etc/apache2/ports.conf
5. מודול 3: פריסת האפליקציה ב-Cloud Run
למה כדאי להשתמש ב-Cloud Run?
שאלה טובה! לפני כמה שנים, בטח הייתם בוחרים ב-Google App Engine.
במילים פשוטות, היום ל-Cloud Run יש סטאק טכנולוגי חדש יותר, קל יותר לפרוס אותו, הוא זול יותר והוא מתכוונן ל-0 כשלא משתמשים בו. הגמישות של Cloud Run מאפשרת להריץ כל קונטיינר ללא שמירת מצב, והוא משולב עם שירותים שונים של Google Cloud. לכן הוא אידיאלי לפריסה של מיקרו-שירותים ואפליקציות מודרניות עם תקורה מינימלית ויעילות מקסימלית.
באופן ספציפי יותר, Cloud Run היא פלטפורמה מנוהלת של Google Cloud שמאפשרת להריץ אפליקציות בקונטיינרים ללא שמירת מצב בסביבה ללא שרת (serverless). המערכת מטפלת באופן אוטומטי בכל התשתית, ומגדילה את הקיבולת מ-0 כדי לעמוד בתנועה הנכנסת ומקטינה אותה כשהיא לא פעילה, כך שהיא יעילה וחסכוני. Cloud Run תומך בכל שפה או ספרייה, כל עוד הם ארוזים בקונטיינר, ומאפשר גמישות רבה בפיתוח. הוא משתלב היטב עם שירותים אחרים של Google Cloud ומתאים לפיתוח מיקרו-שירותים, ממשקי API, אתרים ואפליקציות מבוססות-אירועים, בלי צורך לנהל את תשתית השרתים.
דרישות מוקדמות
כדי לבצע את המשימה הזו, צריך להתקין את gcloud
במחשב המקומי. אם לא, אפשר לעיין בהוראות כאן. אם אתם משתמשים ב-Google Cloud Shell, אין צורך לבצע פעולות.
לפני הפריסה...
אם אתם עובדים בסביבה המקומית, מבצעים אימות ב-Google Cloud באמצעות
$ gcloud auth login –update-adc # not needed in Cloud Shell
הפעולה הזו אמורה לבצע אימות באמצעות התחברות OAuth בדפדפן. חשוב לוודא שנכנסתם ל-Chrome באמצעות אותו משתמש (למשל vattelapesca@gmail.com) שמחובר ל-Google Cloud עם חיוב מופעל.
מפעילים את Cloud Run API באמצעות הפקודה הבאה:
$ gcloud services enable run.googleapis.com cloudbuild.googleapis.com
בשלב הזה, הכול מוכן לפריסה ב-Cloud Run.
פריסת האפליקציה ב-Cloud Run באמצעות gcloud
הפקודה שמאפשרת לפרוס את האפליקציה ב-Cloud Run היא gcloud run deploy
. יש כמה אפשרויות להגדרה כדי להשיג את היעד. אלה הן קבוצת האפשרויות המינימלית (שאפשר לספק דרך שורת הפקודה, או שהכלי ישאל אתכם עליה באמצעות הנחיה אינטראקטיבית):
- שם השירות ב-Cloud Run שרוצים לפרוס לאפליקציה. שירות ב-Cloud Run יחזיר לכם כתובת URL שמספקת נקודת קצה לאפליקציה.
- אזור Google Cloud שבו האפליקציה תפעל. (
--region
REGION) - קובץ אימג' בקונטיינר שמארז את האפליקציה.
- משתני סביבה שהאפליקציה צריכה להשתמש בהם במהלך הביצוע שלה.
- הדגל Allow-Unauthenticated שמאפשר לכולם לגשת לאפליקציה ללא אימות נוסף.
במסמכי העזרה מוסבר איך להחיל את האפשרות הזו על שורת הפקודה. אפשר גם לגלול למטה כדי למצוא פתרון אפשרי.
הפריסה תימשך כמה דקות. אם הכל תקין, במסוף Google Cloud אמור להופיע משהו כזה.
לוחצים על כתובת ה-URL שסופקה על ידי Cloud Run ובודקים את האפליקציה. לאחר האימות, אמור להופיע משהו כזה.
"gcloud run deploy" ללא ארגומנטים
יכול להיות שהבחנתם ש-gcloud run deploy
שואל את השאלות הנכונות וממלא את הרווחים הלבנים שהשארתם. זה מדהים!
עם זאת, בכמה מודולים נוסיף את הפקודה הזו לטריגר של Cloud Build, כך שלא נוכל להשתמש בשאלות אינטראקטיביות. אנחנו צריכים למלא כל אפשרות בפקודה. אתם רוצים ליצור את gcloud run deploy --option1 blah --foo bar --region your-fav-region
הזהב. איך עושים את זה?
- חוזרים על שלבים 2-3-4 עד ש-gcloud מפסיק לשאול שאלות:
- [LOOP]
gcloud run deploy
עם האפשרויות שנמצאו עד כה - [LOOP] systems ask for option X
- [LOOP] מחפשים במסמכים הציבוריים איך להגדיר את X מ-CLI עם הוספת האפשרות
--my-option [my-value]
. - חוזרים לשלב 2, אלא אם הפקודה gcloud מסתיימת בלי שאלות נוספות.
- הפקודה gcloud run deploy BLAH BLAH BLAH פשוט מעולה! שומרים את הפקודה במקום כלשהו, כי תצטרכו אותה בהמשך בשלב Cloud Build.
פתרון אפשרי מופיע כאן. המסמכים מופיעים כאן.
יופי! 🎉🎉🎉 פרסתם את האפליקציה ב-Google Cloud והשלמתם את השלב הראשון בתהליך המודרניזציה.
6. מודול 4: סיסמה נקייה באמצעות Secret Manager
בשלב הקודם הצלחנו לפרוס ולהפעיל את האפליקציה ב-Cloud Run. עם זאת, עשינו זאת באמצעות שיטה לא טובה מבחינת אבטחה: העברת סודות מסוימים בטקסט ללא הצפנה.
מחזור ראשון: מעדכנים את config.php כדי להשתמש ב-ENV
יכול להיות ששמתם לב שהוספנו את הסיסמה של מסד הנתונים ישירות לקוד בקובץ config.php. זה בסדר למטרות בדיקה ולבדוק אם האפליקציה פועלת. אבל אי אפשר לבצע השמירה או להשתמש בקוד כזה בסביבת ייצור. צריך לקרוא את הסיסמה (ופרמטרים אחרים של חיבור למסד נתונים) באופן דינמי ולספק אותה לאפליקציה בזמן הריצה. משנים את הקובץ config.php כך שיקריא את הפרמטרים של מסדי הנתונים ממשתני ENV. אם הבדיקה נכשלת, כדאי להגדיר ערכי ברירת מחדל. זה שימושי במקרה שלא תצליחו לטעון את ENV, כך שהפלט של הדף יגיד לכם אם הוא משתמש בערכי ברירת המחדל. ממלאים את השדות החסרים ומחליפים את הקוד בקובץ config.php.
<?php
// Database configuration with ENV variables. Set default values as well
$db_host = getenv('DB_HOST') ?: 'localhost';
$db_name = getenv('DB_NAME') ?: 'image_catalog';
$db_user = getenv('DB_USER') ?: 'appmod-phpapp-user';
$db_pass = getenv('DB_PASS') ?: 'wrong_password';
// Note getenv() is PHP 5.3 compatible
try {
$pdo = new PDO("mysql:host=$db_host;dbname=$db_name", $db_user, $db_pass);
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
} catch (PDOException $e) {
die("Errore di connessione: " . $e->getMessage());
}
session_start();
?>
מכיוון שהאפליקציה שלכם מוגדרת בקונטיינר, עליכם לספק דרך לספק את משתני ENV לאפליקציה. אפשר לעשות זאת בכמה דרכים:
- בזמן ה-build, בקובץ Dockerfile. מוסיפים לקובץ Dockerfile הקודם את 4 הפרמטרים באמצעות התחביר ENV DB_VAR=ENV_VAR_VALUE. כך תוכלו להגדיר ערכי ברירת מחדל שאפשר לשנות תוך כדי זמן הריצה. לדוגמה, אפשר להגדיר את 'DB_NAME' ו-'DB_USER' רק כאן ולא בשום מקום אחר.
- בזמן הרצה. אפשר להגדיר את המשתנים האלה ב-Cloud Run, גם מ-CLI וגם מממשק המשתמש. זה המקום הנכון להוסיף את כל 4 המשתנים (אלא אם רוצים לשמור את הגדרות ברירת המחדל שהוגדרו ב-Dockerfile).
ב-localhost, מומלץ להעביר את משתני ה-ENV לקובץ .env
(בודקים בתיקייה solutions).
חשוב גם לוודא ש-env . מתווסף ל-.gitignore
: אתם לא רוצים לדחוף את הסודות שלכם ל-GitHub!
echo .env >> .gitignore
לאחר מכן, אפשר לבדוק את המכונה באופן מקומי:
docker run -it -p 8080:8080 --env-file .env my-php-app-docker
עכשיו השגתם את הדברים הבאים:
- האפליקציה תקריא את המשתנה באופן דינמי מה-ENV
- שיפור האבטחה, כי הסרת את הסיסמה של מסד הנתונים מהקוד)
עכשיו אפשר לפרוס גרסה חדשה ב-Cloud Run. נעבור לממשק המשתמש ונגדיר את משתני הסביבה באופן ידני:
- נכנסים לכתובת https://console.cloud.google.com/run
- לוחצים על האפליקציה.
- לוחצים על 'עריכה ופריסה של גרסה חדשה'.
- בכרטיסייה הראשונה 'קונטיינרים', לוחצים על הכרטיסייה התחתונה 'משתנים וסודות'.
- לוחצים על '+ הוספת משתנה' ומוסיפים את כל המשתנים הנדרשים. התוצאה אמורה להיות משהו כזה:
זה מושלם? לא. רוב המפעילים עדיין יכולים לראות את ה-PASS שלכם. אפשר לצמצם את החשיפה הזו באמצעות Google Cloud Secret Manager.
מחזור שני: Secret Manager
הסיסמאות נעלמו מהקוד שלכם: ניצחון! אבל רגע – האם אנחנו כבר בטוחים?
הסיסמאות שלכם עדיין גלויות לכל מי שיש לו גישה למסוף Google Cloud. למעשה, אם תיגשו לקובץ הפריסה של Cloud Run בפורמט YAML, תוכלו לאחזר אותו. לחלופין, אם מנסים לערוך או לפרוס גרסה חדשה של Cloud Run, הסיסמה גלויה בקטע Variables & Secrets (משתנים וסודות), כפי שמוצג בצילום המסך שבהמשך.
Secret Manager של Google Cloud הוא שירות מאובטח ומרכזי לניהול מידע רגיש כמו מפתחות API, סיסמאות, אישורים וסודות אחרים.
בעזרתו אפשר לאחסן סודות, לנהל אותם ולגשת אליהם באמצעות הרשאות מפורטות והצפנה חזקה. Secret Manager משולב עם ניהול זהויות והרשאות הגישה (IAM) של Google Cloud, ומאפשר לכם לקבוע מי יכול לגשת לסודות ספציפיים, וכך להבטיח את אבטחת הנתונים ותאימות לתקנות.
הוא תומך גם ברוטציה אוטומטית של סודות ובניהול גרסאות, ומפשט את ניהול מחזור החיים של סודות ומשפר את האבטחה באפליקציות בשירותי Google Cloud.
כדי לגשת ל-Secret Manager, עוברים מתפריט ההמבורגר לשירותי אבטחה ומאתרים אותו בקטע הגנה על נתונים, כפי שמוצג בצילום המסך שבהמשך.
מפעילים את Secret Manager API לפי התמונה הבאה.
- עכשיו לוחצים על Create a secret (יצירת סוד): ננסה להסביר את זה באופן רציונלי:
- שם:
php-amarcord-db-pass
- ערך הסוד: 'your DB password' (מתעלמים מהחלק 'upload file').
- מוסיפים הערה לקישור הסודי הזה. הוא אמור להיראות כך:
projects/123456789012/secrets/php-amarcord-db-pass
. זהו הסמן הייחודי לסוד (ב-Terraform, ב-Cloud Run ובשירותים אחרים). המספר הוא מספר הפרויקט הייחודי שלכם.
טיפ: מומלץ להשתמש במוסכמות עקביות למתן שמות לסודות, ולהתמקד בצד ימין, לדוגמה: cloud-devrel-phpamarcord-dbpass
- ארגון (עם החברה)
- צוות (בתוך הארגון)
- בקשה (בתוך הצוות)
- שם המשתנה (באפליקציה)
כך תוכלו ליצור ביטויים רגולריים פשוטים כדי למצוא את כל הסודות שלכם באפליקציה אחת.
יצירת גרסה חדשה של Cloud Run
עכשיו, כשיש לנו סוד חדש, אנחנו צריכים להסיר את משתנה הסביבה DB_PASS ולהחליף אותו בסוד החדש. כך:
- גישה ל-Cloud Run באמצעות מסוף Google Cloud
- בוחרים את האפליקציה.
- לוחצים על 'עריכה ופריסה של גרסה חדשה'.
- מאתרים את הכרטיסייה Variables & Secrets (משתנים וסודות).
- לוחצים על הלחצן '+ הפניה לסוד' כדי לאפס את משתנה הסביבה DB_PASS.
- משתמשים באותו 'DB_PASS' עבור הסודות שצוינו, ומשתמשים בגרסה העדכנית ביותר.
בסיום, אמורה להופיע הודעת השגיאה הבאה
נסו להבין איך לפתור את הבעיה. כדי לפתור את הבעיה, צריך להיכנס לקטע IAM & Admin ולשנות את הרשאות ההקצאה. ניפוי באגים מהנה!
אחרי שתמצאו את הבעיה, תוכלו לחזור ל-Cloud Run ולפרוס מחדש גרסה חדשה. התוצאה אמורה להיראות כך:
טיפ: במסוף למפתחים (ממשק המשתמש) יש כלי מצוין לזיהוי בעיות שקשורות להרשאות. כדאי להקדיש זמן כדי לנווט בין כל הקישורים של ישויות Cloud שלכם.
7. מודול 5: הגדרת CI/CD באמצעות Cloud Build
למה כדאי להשתמש בצינור עיבוד נתונים של CI/CD?
עד עכשיו, אמורה להיות לכם אפשרות להקליד את gcloud run deploy
כמה פעמים, אולי לענות על אותה שאלה שוב ושוב.
נמאס לכם לפרוס את האפליקציה באופן ידני באמצעות gcloud run deploy? לא הייתם רוצים שהאפליקציה שלכם תוכל לפרוס את עצמה באופן אוטומטי בכל פעם שאתם דוחפים שינוי חדש למאגר Git?
כדי להשתמש בצינור עיבוד נתונים של CI/CD, צריך שני דברים:
- מאגר Git אישי: למזלכם, כבר יצרתם ענף (fork) של מאגר הסדנה בחשבון GitHub שלכם בשלב 2. אם לא, חוזרים לשלב הזה ומסיימים אותו. המאגר המפצל אמור להיראות כך:
https://github.com/<YOUR_GITHUB_USER>/app-mod-workshop
- Cloud Build. השירות המדהים והזול הזה מאפשר להגדיר אוטומציה של גרסאות build כמעט לכל דבר: Terraform, אפליקציות ב-Docker וכו'.
בקטע הזה נתמקד בהגדרת Cloud Build.
נכנסים ל-Cloud Build
כדי לעשות זאת, נשתמש ב-Cloud Build:
- יצירת קובץ build של המקור (עם Dockerfile). אפשר לחשוב על זה כעל "קובץ ZIP גדול" שמכיל את כל מה שצריך כדי ליצור ולהריץ אותו ('ארטיפקט ה-build').
- דוחפים את הארטיפקט הזה ל-Artifact Registry (AR).
- לאחר מכן, מבצעים פריסה מ-AR ל-Cloud Run לאפליקציה php-amarcord.
- הפעולה הזו תיצור גרסה חדשה ('גרסה מתוקנת') של האפליקציה הקיימת (אפשר לחשוב עליה כשכבה עם הקוד החדש), ואנחנו נגדיר אותה כך שתסיט את התנועה לגרסה החדשה אם הפעולה תצליח.
זו דוגמה לכמה גרסאות build לאפליקציה php-amarcord
שלי:
איך אנחנו עושים את כל זה?
- על ידי יצירה של קובץ YAML מושלם אחד:
cloudbuild.yaml
- על ידי יצירת טריגר של Cloud Build.
- על ידי חיבור למאגר GitHub שלנו דרך ממשק המשתמש של Cloud Build.
יצירת טריגר (ורשומות ב-Connect)
- עוברים לכתובת https://console.cloud.google.com/cloud-build/triggers
- לוחצים על 'יצירת טריגר'.
- הידור:
- שם: משהו בעל משמעות כמו
on-git-commit-build-php-app
- אירוע: Push to branch
- מקור: 'קישור מאגר חדש'
- ייפתח חלון בצד שמאל: 'קישור מאגר'.
- ספק המקור: 'Github' (ראשון)
- "Continue"
- ייפתח חלון ב-GitHub לאימות חוצה. פועלים לפי התהליך ומתאזרים בסבלנות. אם יש לכם הרבה מאגרים, התהליך עשוי להימשך זמן מה.
- 'בחירת מאגר' בוחרים את החשבון או המאגר ומסמנים את החלק 'הבנתי…'.
- אם מופיעה השגיאה: אפליקציית GitHub לא מותקנת באף אחד מהמאגרים שלכם, לוחצים על 'Install Google Cloud Build' (התקנת Google Cloud Build) ופועלים לפי ההוראות.
לוחצים על 'התחברות'.
- בינגו! המאגר מקושר עכשיו.
- חזרה לקטע 'טריגר'…
- הגדרה: זיהוי אוטומטי (*)
- מתקדם: בוחרים את חשבון השירות "[PROJECT_NUMBER]- compute@developer.gserviceaccount.com"
- xxxxx הוא מזהה הפרויקט
- חשבון השירות של Compute Engine שמוגדר כברירת מחדל מתאים לניסוי – אל תשתמשו בו בסביבת הייצור! ( מידע נוסף)
- משאירים את כל השאר כמו שהוא.
- לוחצים על הלחצן 'יצירה'.
(*) זו הדרך הפשוטה ביותר, כי היא בודקת אם יש קובץ Dockerfile או cloudbuild.yaml. עם זאת, האפשרות cloudbuild.yaml
מאפשרת לכם להחליט מה לעשות בכל שלב.
יש לי את הכוח!
עכשיו הטריגר לא יפעל אלא אם תעניקו לחשבון השירות ב-Cloud Build (מהו חשבון שירות? כתובת האימייל של 'רובוט' שפועל בשמכם במשימה מסוימת – במקרה הזה, פיתוח דברים ב-Cloud).
האדמין לא יוכל לבצע פיתוח ופריסה אלא אם תעניקו לו הרשאה לעשות זאת. למזלכם, זה קל!
- עוברים אל Cloud Build > Settings.
- חשבון השירות '[PROJECT_NUMBER]- compute@developer.gserviceaccount.com'
- מסמנים את התיבות הבאות:
- Cloud Run
- Secret Manager
- חשבונות שירות
- Cloud Build
- מסמנים גם את התיבה 'הגדרה כחשבון השירות המועדף'.
איפה קובץ ה-YAML של Cloud Build?
מומלץ מאוד להקדיש זמן ליצירת קובץ YAML משלכם ל-Build ב-Cloud.
עם זאת, אם אין לכם זמן או שאתם לא רוצים להקדיש זמן לכך, תוכלו לקבל השראה מתיקיית הפתרונות הזו: .solutions
עכשיו אפשר לדחוף שינוי ל-GitHub ולראות את התוצאות ב-Cloud Build.
הגדרת Cloud Build יכולה להיות מאתגרת. צפויה התכתבות קצרה:
- בדיקת היומנים בכתובת https://console.cloud.google.com/cloud-build/builds;region=global
- איתור השגיאה.
- תיקון הקוד והפעלה מחדש של git commit / git push.
- לפעמים השגיאה לא נמצאת בקוד, אלא בהגדרה כלשהי. במקרה כזה, אפשר להפעיל build חדש מהממשק המשתמש (cloud build > 'Triggers' > Run).
חשוב לזכור: אם משתמשים בפתרון הזה, עדיין יש עבודה לעשות. לדוגמה, צריך להגדיר את משתני ה-ENV לנקודות הקצה החדשות שנוצרו ל-dev/prod:
תוכל לעשות זאת בשתי דרכים:
- דרך ממשק המשתמש – על ידי הגדרה מחדש של משתני ENV
- באמצעות CLI, על ידי יצירת הסקריפט 'המושלם' בשבילכם. דוגמה אפשר למצוא כאן: gcloud-run-deploy.sh . צריך לשנות כמה דברים, למשל נקודת הקצה ומספר הפרויקט. אפשר למצוא את מספר הפרויקט בדף Cloud Overview.
איך מבצעים commit לקוד ב-GitHub?
מעבר להיקף הסדנה, לא נסביר איך מעבירים את git push
ל-GitHub. עם זאת, אם נתקעתם ב-Cloud Shell, יש שתי דרכים:
- CLI. מוסיפים מפתח SSH באופן מקומי ומוסיפים מחשב מרוחק באמצעות git@github.com:YOUR_USER/app-mod-workshop.git (במקום http)
- VSCode. אם אתם משתמשים בעורך של Cloud Shell, אתם יכולים להשתמש בכרטיסייה Source control (ctrl-shift-G), ללחוץ על 'sync changes' ולפעול לפי ההוראות. אמורה להיות לך אפשרות לאמת את חשבון GitHub ב-VSCode, והפעלת הפקודות pull/push תהיה קלה.
חשוב לזכור להוסיף את הקובץ git add clodubuild.yaml
בין הקבצים האחרים, אחרת הוא לא יפעל.
השוואה בין 'התאמה בין סביבות dev/prod' לעומק לבין 'התאמה בין סביבות dev/prod' לשטח [אופציונלי]
אם מעתיקים את גרסת המודל מכאן, יהיו שתי גרסאות זהות – DEV ו-PROD. זה מגניב ותואמת לכלל 10 של 12 הגורמים לאפליקציה.
עם זאת, אנחנו משתמשים בשתי נקודות קצה שונות באינטרנט כדי שהאפליקציה תצביע על אותה מסד נתונים. זה מספיק לצורך סדנה, אבל בחיים האמיתיים כדאי להקדיש זמן כדי ליצור סביבה ייעודית ל-prod. המשמעות היא שיש לכם שני מסדי נתונים (אחד לפיתוח ואחד בסביבת הייצור), וגם אתם בוחרים איפה הם יהיו לצורך תוכנית התאוששות מאסון או זמינות גבוהה. זה לא עוסק בנושא הסדנה הזו, אבל כדאי לחשוב על זה.
אם יש לכם זמן ליצור גרסה 'עמוקה' של סביבה ייעודית לפריסה, חשוב לזכור את כל המשאבים שצריך להעתיק, כמו:
- מסד נתונים של Cloud SQL (וכנראה גם מכונה של SQL).
- קטגוריה ב-GCS
- פונקציה של Cloud Functions.
- אפשר להשתמש ב-Gemini 1.5 Flash כמודל בפיתוח (זול יותר ומהיר יותר) וב-Gemini 1.5 Pro (חזק יותר).
באופן כללי, בכל פעם שאתם מבצעים פעולה כלשהי באפליקציה, כדאי לחשוב באופן ביקורתי: האם צריך להגדיר את אותו ערך בסביבת הייצור או לא? אם לא, צריך לחזור על הפעולה. כמובן שקל יותר לעשות זאת ב-Terraform, שבו אפשר להוסיף את הסביבה (-dev, -prod) כסיומת למשאבים.
8. מודול 6: מעבר ל-Google Cloud Storage
אחסון
נכון לעכשיו, האפליקציה מאחסנת את המצב בקונטיינר של Docker. אם המכונה תתקלקל, האפליקציה תתפוצץ או פשוט תשלחו גרסה חדשה, תתוזמן גרסה חדשה עם אחסון חדש וריק: 🙈
איך אנחנו מתקנים את זה? יש כמה גישות.
- אחסון תמונות במסד הנתונים. זה מה שעשיתי בסופו של דבר באפליקציית ה-PHP הקודמת שלי. זה הפתרון הפשוט ביותר כי הוא לא מוסיף מורכבות. אבל היא מוסיפה זמן אחזור ועומס למסד הנתונים.
- מעבירים את אפליקציית Cloud Run לפתרון שמתאים לאחסון: GCE + אחסון מתמיד (persistent disk)? אולי GKE + Storage? הערה: ככל שתגדילו את השליטה, כך תאבדו בזריזות.
- עוברים אל GCS. Google Cloud Storage הוא שירות האחסון הטוב ביותר מסוגו ב-Google Cloud, והוא הפתרון הכי טבעי לשימוש בענן. עם זאת, כדי לעשות זאת צריך להשתמש בספריות PHP. האם יש לנו ספריות PHP 5.7 ל-GCS? האם
PHP 5.7
תומך ב-Composer
(נראה שPHP 5.3.2 היא הגרסה המוקדמת ביותר שנתמכת על ידי Composer)? - אולי כדאי להשתמש ב-docker sidecar?
- אפשר גם להשתמש ב-GCS Cloud Run Volume Mounts. זה נשמע מדהים.
🤔 העברת אחסון (פתוח)
[פתרון פתוח] במטלה הזו, אנחנו רוצים שתמצאו פתרון להעברת התמונות באופן שמאפשר לשמור אותן באופן כלשהו.
בדיקת אישור
אני לא רוצה לומר לך מה הפתרון, אבל אני רוצה שזה יקרה:
- מעלים את
newpic.jpg
. הוא מופיע באפליקציה. - משדרגים את האפליקציה לגרסה חדשה.
newpic.jpg
עדיין שם, גלוי.
💡 פתרון אפשרי (התקנת נפח אחסון ב-GCS Cloud Run)
זהו פתרון אלגנטי מאוד שמאפשר לנו לבצע העלאות של קבצים עם מצב (stateful) בלי לגעת בקוד בכלל (מלבד הצגת תיאור של תמונה, אבל זה טריוויאלי ורק לצורך הנאה).
הפעולות האלה אמורות לאפשר לכם לחבר תיקייה מ-Cloud Run ל-GCS, כך:
- כל ההעלאות ל-GCS יוצגו באפליקציה.
- כל ההעלאות לאפליקציה יועלו בפועל ל-GCS
- דברים קסומים יתרחשו באובייקטים שהועלו ל-GCS (פרק 7).
הערה יש לקרוא את האותיות הקטנות של FUSE. זה לא בסדר אם יש בעיה בביצועים.
יצירת קטגוריה ב-GCS
GCS הוא שירות האחסון הנפוץ ביותר ב-Google Cloud. השירות הזה נבדק היטב, וכל שירות ב-GCP שצריך אחסון משתמש בו.
שימו לב ש-Cloud Shell מייצא את PROJECT_ID בתור GOOGLE_CLOUD_PROJECT:
$ export PROJECT_ID=$GOOGLE_CLOUD_PROJECT
#!/bin/bash
set -euo pipefail
# Your Cloud Run Service Name, eg php-amarcord-dev
SERVICE_NAME='php-amarcord-dev'
BUCKET="${PROJECT_ID}-public-images"
GS_BUCKET="gs://${BUCKET}"
# Create bucket
gsutil mb -l "$GCP_REGION" -p "$PROJECT_ID" "$GS_BUCKET/"
# Copy original pictures there - better if you add an image of YOURS before.
gsutil cp ./uploads/*.png "$GS_BUCKET/"
הגדרת Cloud Run לטעינה של הקטגוריה בתיקייה /uploads/
עכשיו נגיע לחלק האלגנטי. יוצרים נפח אחסון php_uploads
ומורים ל-Cloud Run לבצע טעינה של FUSE ב-MOUNT_PATH
(משהו כמו /var/www/html/uploads/
):
#!/bin/bash
set -euo pipefail
# .. keep variables from previous script..
# Uploads folder within your docker container.
# Tweak it for your app code.
MOUNT_PATH='/var/www/html/uploads/'
# Inject a volume mount to your GCS bucket in the right folder.
gcloud --project "$PROJECT_ID" beta run services update "$SERVICE_NAME" \
--region $GCP_REGION \
--execution-environment gen2 \
--add-volume=name=php_uploads,type=cloud-storage,bucket="$BUCKET" \
--add-volume-mount=volume=php_uploads,mount-path="$MOUNT_PATH"
עכשיו חוזרים על השלב הזה לכל נקודות הקצה שרוצים להפנות ל-Cloud Storage.
אפשר לעשות את זה גם דרך ממשק המשתמש
- בכרטיסייה Volumes (נפחים), יוצרים Volume Mounts (חיבור נפח אחסון) שמצביעים לקטגוריה, מסוג Cloud Storage bucket (קטגוריית Cloud Storage), לדוגמה, עם השם php_uploads.
- בקטע Container(s) > Volume Mounts, מחברים את נפח האחסון שיצרתם לנקודת נפח האחסון שהאפליקציה ביקשה. זה תלוי בקובץ dockerfile, אבל יכול להיות שהוא ייראה כך:
var/www/html/uploads/
.
בכל מקרה, אם זה עובד, כשעורכים את הגרסה החדשה של Cloud Run צריך להופיע משהו כזה:
עכשיו בודקים את האפליקציה החדשה על ידי העלאת תמונה חדשה אחת לנקודת הקצה /upload.php
.
התמונות אמורות לעבור בצורה חלקה ב-GCS בלי לכתוב שורת PHP אחת:
מה קרה עכשיו?
קרה משהו קסום מאוד.
אפליקציה ישנה עם קוד ישן עדיין מבצעת את עבודתה. בעזרת סטאק חדש ומעודכן, כל התמונות באפליקציה נמצאות בנוחות בקטגוריה של Cloud עם שמירת מצב. עכשיו השמיים הם הגבול:
- רוצים לשלוח אימייל בכל פעם שמתקבלת תמונה עם תוכן מסוכן או תמונה של עירום? אפשר לעשות זאת בלי לגעת בקוד ה-PHP.
- רוצים להשתמש במודל Gemini Multimodal בכל פעם שמתקבלת תמונה כדי לתאר אותה, ולהעלות את מסד הנתונים עם התיאור שלה? אפשר לעשות זאת בלי לגעת בקוד ה-PHP. לא מאמינים לי? ממשיכים לקרוא פרק 7.
עכשיו יש לנו הזדמנות גדולה.
9. מודול 7: שיפור האפליקציה באמצעות Google Gemini
עכשיו יש לכם אפליקציית PHP חדשה ומדהימה (כמו Fiat 126
מ-2024) עם אחסון ב-Cloud.
מה אפשר לעשות איתה?
דרישות מוקדמות
בפרק הקודם, פתרון לדוגמה איפשר לנו לחבר את התמונות /uploads/
ל-GCS, ובכך למעשה להפריד בין הלוגיקה של האפליקציה לבין אחסון התמונות.
כדי לבצע את התרגיל הזה, צריך:
- השלמת את התרגיל בקטע 6 (אחסון).
- יש לכם קטגוריה ב-GCS עם ההעלאות של התמונות, שבה אנשים מעלים תמונות באפליקציה והתמונות עוברות לקטגוריה שלכם.
הגדרת פונקציית Cloud (ב-Python)
חשבתם פעם איך מטמיעים אפליקציה מבוססת-אירועים? משהו כזה:
- כשהאירוע <event> מתרחש => שולחים אימייל
- כשמתרחש <event> => אם <condition> נכון, מעדכנים את מסד הנתונים.
אירוע יכול להיות כל דבר, החל מרשומות חדשות שזמינות ב-BigQuery, אובייקט חדש שהשתנה בתיקייה ב-GCS או הודעה חדשה שממתינה בתור ב-Pub/Sub.
ב-Google Cloud יש תמיכה במספר פרדיגמות שיעזרו לכם להשיג את המטרה הזו. במיוחד:
- EventArc. איך מקבלים אירועים ב-GCS כלי מצוין ליצירת DAGs ולתזמור פעולות על סמך תנאי 'אם-אז-אחרת' ב-Cloud.
- Cloud Scheduler. למשל, נהדר למשימות cron בחצות בענן.
- Cloud Workflows. בדומה ל-Event Arc, מאפשרת לכם
- פונקציות Cloud Run (שנקראות גם
lambdas
). - Cloud Composer. בעצם, זוהי הגרסה של Google ל-Apache Airflow, שמתאימה גם ל-DAG.
בתרגול הזה נעמיק ב-Cloud Functions כדי להגיע לתוצאה מרשימה למדי. וגם נספק לכם תרגילים אופציונליים.
לתשומת ליבך, קוד לדוגמה מסופק בכפוף ל-.solutions/
הגדרת פונקציה של Cloud (🐍 Python)
אנחנו מנסים ליצור GCF שאפתני מאוד.
- כשנוצרת תמונה חדשה ב-GCS (כנראה שמישהו העלאה אותו לאפליקציה – אבל לא רק)
- .. קוראים ל-Gemini כדי לתאר אותה ולקבל תיאור טקסטואלי של התמונה .. (כדאי לבדוק את ה-MIME ולוודא שמדובר בתמונה ולא בקובץ PDF, MP3 או טקסט)
- .. ועודכן את מסד הנתונים עם התיאור הזה. (יכול להיות שתצטרכו לתקן את מסד הנתונים כדי להוסיף עמודת
description
לטבלהimages
).
תיקון מסד הנתונים להוספת description
לתמונות
- פותחים את Cloud SQL Studio:
- מזינים את שם המשתמש והסיסמה של מסד הנתונים של התמונות
- מזינים את ה-SQL הבא שמוסיף עמודה לתיאור התמונה:
ALTER TABLE images ADD COLUMN description TEXT;
בינגו! עכשיו אפשר לבדוק אם זה עבד:
SELECT * FROM images;
העמודה החדשה של התיאור אמורה להופיע:
כתיבת f(x) של Gemini
הערה הפונקציה הזו נוצרה בעזרת הכלי של Gemini לסיוע בקוד.
הערה כשיוצרים את הפונקציה הזו, יכול להיות שתקבלו שגיאות שקשורות להרשאות IAM. חלק מהן מתועדות בהמשך בקטע 'שגיאות אפשריות'.
- הפעלת ממשקי ה-API
- עוברים לכתובת https://console.cloud.google.com/functions/list
- לוחצים על 'Create Function' (יצירת פונקציה).
- מפעילים את ממשקי ה-API באמצעות האשף של ממשקי ה-API:
אפשר ליצור את GCF דרך ממשק המשתמש או דרך שורת הפקודה. כאן נשתמש בשורת הפקודה.
קוד אפשרי מופיע בקטע .solutions/
- יוצרים תיקייה לאירוח הקוד, למשל 'gcf/'. נכנסים לתיקייה.
- יוצרים קובץ
requirements.txt
:
google-cloud-storage
google-cloud-aiplatform
pymysql
- יוצרים פונקציית Python. קוד לדוגמה: gcf/main.py.
#!/usr/bin/env python
"""Complete this"""
from google.cloud import storage
from google.cloud import aiplatform
import vertexai
from vertexai.generative_models import GenerativeModel, Part
import os
import pymysql
import pymysql.cursors
# Replace with your project ID
PROJECT_ID = "your-project-id"
GEMINI_MODEL = "gemini-1.5-pro-002"
DEFAULT_PROMPT = "Generate a caption for this image: "
def gemini_describe_image_from_gcs(gcs_url, image_prompt=DEFAULT_PROMPT):
pass
def update_db_with_description(image_filename, caption, db_user, db_pass, db_host, db_name):
pass
def generate_caption(event, context):
"""
Cloud Function triggered by a GCS event.
Args:
event (dict): The dictionary with data specific to this type of event.
context (google.cloud.functions.Context): The context parameter contains
event metadata such as event ID
and timestamp.
"""
pass
- מעבירים את הפונקציה. אפשר להשתמש בסקריפט דומה לזה: gcf/push-to-gcf.sh.
הערה 1. חשוב לספק את מקורות ה-ENV עם הערכים הנכונים, או פשוט להוסיף אותם למעלה (GS_BUCKET=blah
, ..):
הערה 2. הפקודה הזו תדחוף את כל הקוד המקומי (.
), לכן חשוב להקפיד להעביר את הקוד בתיקייה ספציפית ולהשתמש ב-.gcloudignore
כמו מקצוענים כדי להימנע מדחיפת ספריות עצומות. ( דוגמה).
#!/bin/bash
set -euo pipefail
# add your logic here, for instance:
source .env || exit 2
echo "Pushing ☁️ f(x)☁ to 🪣 $GS_BUCKET, along with DB config.. (DB_PASS=$DB_PASS)"
gcloud --project "$PROJECT_ID" functions deploy php_amarcord_generate_caption \
--runtime python310 \
--region "$GCP_REGION" \
--trigger-event google.cloud.storage.object.v1.finalized \
--trigger-resource "$BUCKET" \
--set-env-vars "DB_HOST=$DB_HOST,DB_NAME=$DB_NAME,DB_PASS=$DB_PASS,DB_USER=$DB_USER" \
--source . \
--entry-point generate_caption \
--gen2
הערה: בדוגמה הזו, generate_caption
תהיה השיטה שתופעל, ו-Cloud Function תעביר אליה את האירוע ב-GCS עם כל המידע הרלוונטי (שם הקטגוריה, שם האובייקט וכו'). כדאי להקדיש זמן לניפוי באגים של מערך הנתונים של האירוע ב-Python.
בדיקת הפונקציה
בדיקות יחידה
הפונקציה כוללת הרבה חלקים נעים. כדאי לבדוק את כל האפשרויות הבודדות.
דוגמה מופיעה בקובץ gcf/test.py.
ממשק המשתמש של Cloud Functions
כדאי גם להקדיש קצת זמן כדי לבדוק את הפונקציה בממשק המשתמש. כדאי לבדוק כל כרטיסייה, במיוחד את Source
(הכרטיסייה האהובה עלי), Variables
, Trigger
ו-Logs
. תצטרכו להקדיש הרבה זמן לכרטיסייה Logs
כדי לפתור שגיאות (אפשר גם לעיין בשגיאות האפשריות שבתחתית הדף הזה). חשוב גם לבדוק את Permissions
.
בדיקה מקצה לקצה
עכשיו הגיע הזמן לבדוק את הפונקציה באופן ידני.
- נכנסים לאפליקציה.
- צריך להעלות תמונה (לא גדולה מדי, נתקלנו בבעיות עם תמונות גדולות)
- בודקים בממשק המשתמש שהתמונה הועלתה.
- בודקים ב-Cloud SQL Studio שהתיאור עודכן. מתחברים ומריצים את השאילתה הבאה:
SELECT * FROM images
.
וזה עובד! יכול להיות שנעדכן גם את חזית האתר כדי להציג את התיאור הזה.
עדכון PHP כדי להציג [אופציונלי]
הוכחנו שהאפליקציה פועלת. עם זאת, כדאי שהמשתמשים יוכלו לראות את התיאור הזה גם כן.
אין צורך להיות מומחים ב-PHP כדי להוסיף את התיאור ל-index.php
. הקוד הזה אמור לפעול (כן, גם Gemini כתבה אותו בשבילי!):
<?php if (!empty($image['description'])): ?>
<p class="font-bold">Gemini Caption:</p>
<p class="italic"><?php echo $image['description']; ?></p>
<?php endif; ?>
אפשר למקם את הקוד הזה בתוך foreach
לפי טעמכם.
בשלבים הבאים נראה גם גרסה יפה יותר של ממשק המשתמש, בזכות Gemini Code Assist. גרסה יפה יכולה להיראות כך:
מסקנות
הפעלתם פונקציית Cloud על אובייקטים חדשים שמגיעים ל-GCS, והיא יכולה להוסיף הערות לתוכן התמונה כמו שאדם יכול לעשות, ולעדכן את מסד הנתונים באופן אוטומטי. וואו!
מה השלב הבא? אפשר להשתמש באותו היגיון כדי להשיג שתי פונקציות מצוינות.
[אופציונלי] הוספת עוד פונקציות של Cloud Functions [פתוח]
יש כמה תכונות נוספות שאפשר להוסיף.
📩 טריגר אימייל
טריגר לאימייל ששולח לכם אימייל בכל פעם שמישהו שולח תמונה.
- לעיתים קרובות מדי? מוסיפים אילוץ נוסף: תמונה גדולה, או תמונה שתוכן Gemini שלה מכיל את המילים 'עירום/עירום/אלימות'.
- כדאי לבדוק את
EventArc
לצורך כך.
🚫 סינון אוטומטי של תמונות בלתי הולמות
נכון לעכשיו, אדמין אנושי מסמנים תמונות כ'לא הולמות'. רוצים ש-Gemini יעשה את העבודה הקשה וינהל את המרחב המשותף? מוסיפים בדיקה כדי לסמן תוכן בלתי הולם של טריגרים ולעדכן את מסד הנתונים, כפי שלמדנו בפונקציה הקודמת. כלומר, בעצם צריך לקחת את הפונקציה הקודמת, לשנות את ההנחיה ולעדכן את מסד הנתונים על סמך התשובה.
אזהרה. ל-AI גנרטיבי יש פלט בלתי צפוי. חשוב לוודא שה'יצירת הקריאייטיב' מ-Gemini מועברת 'למסילה'. אפשר לבקש תשובה גורפת כמו ציון ביטחון מ-0 עד 1, קובץ JSON וכו'. אפשר לעשות זאת בדרכים רבות, למשל: * שימוש בספריות Python pydantic
, langchain
וכו'. * שימוש בפלט מובנה של Gemini.
טיפ אפשר להשתמש בכמה פונקציות או בהנחיה אחת שמאלצת תשובה בפורמט JSON (היא עובדת מצוין עם 'פלט מובנה של Gemini', כפי שצוין למעלה), כמו:
מה תהיה ההנחיה ליצירת התמונה הזו?
{
"description": "This is the picture of an arrosticino",
"suitable": TRUE
}
אפשר להוסיף להנחיה שדות נוספים כדי לקבל תובנות, למשל: האם יש משהו טוב בזה? זה גרוע? המקום מוכר לך? האם יש טקסט (זיהוי תווים אופטי (OCR) קל יותר מתמיד):
goods
: "It looks like yummie food"bads
: "התמונה נראית כמו מזון לא בריא"OCR
: "Da consumare preferibilmente prima del 10 Novembre 2024"location
: "Pescara, Lungomare"
בדרך כלל עדיף ליצור N פונקציות לN תוצאות, אבל מאוד משתלם ליצור פונקציה אחת שמבצעת 10 פעולות. במאמר הזה של Riccardo מוסבר איך עושים את זה.
שגיאות אפשריות (בעיקר IAM או הרשאות)
כשפיתחתי את הפתרון הזה בפעם הראשונה, נתקלתי בבעיות מסוימות בהרשאות IAM. אצרף אותן כאן כדי להביע אמפתיה ולתת כמה רעיונות לפתרון הבעיות.
שגיאה: not enough permissions for Service Account
- הערה: כדי לפרוס פונקציית GCF שמקשיבה לקטגוריה ב-GCS, צריך להגדיר את ההרשאות המתאימות לחשבון השירות שבו אתם משתמשים במשימה, כפי שמתואר באיור:
יכול להיות שתצטרכו גם להפעיל את ממשקי ה-API של EventArc – כמה דקות לפני שהם יהיו זמינים באופן מלא.
שגיאה: חסר Cloud Run invoker
- תגובה נוספת מהממשק המשתמש לגבי הרשאות GCF היא זו ( Cloud run Invoker role):
אפשר לתקן את השגיאה הזו על ידי הפעלת הפקודה בתמונה, שדומה לפקודה fix-permissions.sh.
הבעיה הזו מתוארת כאן: https://cloud.google.com/functions/docs/securing/authenticating
שגיאה: יש חריגה ממגבלת הזיכרון
בפעם הראשונה שהרצתי אותו, ביומני צוין: "‘Memory limit of 244 MiB exceeded with 270 MiB used. מומלץ להגדיל את מגבלת הזיכרון. מידע נוסף זמין בכתובת https://cloud.google.com/functions/docs/configuring/memory'". שוב, מוסיפים זיכרון RAM ל-GCF. זה קל מאוד לעשות בממשק המשתמש. יכול להיות שיהיו בעיות:
לחלופין, אפשר גם לתקן את סקריפט הפריסה של Cloud Run כדי להגדיל את נפח הזיכרון או את מעבד ה-CPU. הפעולה הזו אורכת קצת יותר זמן.
שגיאה: PubSub Published
יצירת טריגר עם GCF v1 הניבה פעם את השגיאה הבאה:
שוב, אפשר לפתור את הבעיה בקלות על ידי מעבר אל IAM והקצאת התפקיד 'פרסום הודעות ב-Pub/Sub' לחשבון השירות.
שגיאה: לא נעשה שימוש ב-Vertex AI
אם מופיעה השגיאה הזו:
Permission Denied: 403 Vertex AI API has not been used in project YOUR_PROJECT before or it is disabled. כדי להפעיל אותו, עוברים לכתובת https://console.developers.google.com/apis/api/aiplatform.googleapis.com/overview?project=YOR_PROJECT
פשוט צריך להפעיל את ממשקי ה-API של Vertex AI. הדרך הקלה ביותר להפעיל את כל ממשקי ה-API הנדרשים היא:
- https://console.cloud.google.com/vertex-ai
- לוחצים על 'הפעלת כל ממשקי ה-API המומלצים'.
שגיאה: לא נמצא טריגר של EventArc.
אם מופיעה הודעת השגיאה הזו, צריך לפרוס מחדש את הפונקציה.
שגיאה: 400 Service agents are being provisioned
מתבצע הקצאה של 400 סוכני שירות ( https://cloud.google.com/vertex-ai/docs/general/access-control#service-agents). סוכני השירות נדרשים לקריאת הקובץ ב-Cloud Storage שסופק. לכן, אפשר לנסות שוב בעוד כמה דקות.
במקרה כזה, צריך להמתין קצת או לפנות ל-Googler.
10. מודול 8: יצירת יעדי SLO לזמינות
בחלק הזה אנחנו מנסים להשיג את היעדים הבאים:
- יצירת SLI
- יצירת יעדי SLO על סמך יעדי ה-SLI
- יצירת התראות על סמך יעדי SLO
זהו נושא חשוב מאוד לכותב, כי Riccardo עובד בתחום SRE / DevOps ב-Google Cloud.
(פתוח) יצירה של מדדי SLI ו-SLO לאפליקציה הזו
איזו אפליקציה טובה אם אי אפשר לדעת מתי היא לא זמינה?
מהו יעד SLO?
אוי! Google המציאה את היעדים למדידת רמת השירות (SLO)! מידע נוסף זמין במאמרים הבאים:
- ספר SRE – פרק 2 – הטמעת יעדי SLO ( 👉 ספרים נוספים בנושא SRE)
- Art of SLOs ( סרטון מעולה). זוהי הדרכה נהדרת לקבלת מידע נוסף על יצירת יעד SLO מושלם לשירות שלכם.
- קורס בנושא SRE ב-Coursera. השתתפתי ביצירתו!
שלב 1: יצירת SLI/SLO של זמינות
נתחיל ב-SLO של זמינות, כי זה הדבר הכי קל למדוד וכנראה גם החשוב ביותר.
למרבה המזל, Cloud Run כולל תמיכה מובנית ב-SLO, בזכות Istio.
אחרי שהאפליקציה שלכם פועלת ב-Cloud Run, זה קל מאוד לעשות את זה. זה לוקח לי 30 שניות.
- נכנסים לדף Cloud Run.
- לוחצים על האפליקציה או בוחרים בה.
- בוחרים בכרטיסייה
SLOs
. - לוחצים על '+ יצירת SLO'.
- זמינות, מבוססת-בקשה
- המשך
- חודש קלנדרי / 99%.
- לוחצים על 'יצירת SLO'.
שלב 2: הגדרת התראות לגבי יעד ה-SLO הזה
מומלץ ליצור 2 התראות:
- אחת עם קצב צריכה נמוך ('שריפה איטית') כדי לקבל התראה באימייל (הדמיה של כרטיס בעדיפות נמוכה).
- אחת עם קצב צריכה גבוה ('Fastburn') כדי לקבל התראה באמצעות SMS (סימולציה של כרטיס בעדיפות גבוהה או ניידת הודעות)
עוברים אל SLO tab
מהשלב הקודם.
צריך לעשות את זה פעמיים:
- לוחצים על 'יצירת התראה על יעד SLO' (הלחצן 🔔 עם הפלוס בתוכו, שמשמאל)
- משך התקופה למבט לאחור, סף קצב שריפת המזומנים:
- [FAST]. ראשון:
60
דקות /10
x - [SLOW]. שנייה:
720
דק' /2
x - ערוץ התראות: לוחצים על 'ניהול ערוצי התראות'.
- קודם, 'אימייל' -> הוספת כתובת חדשה -> ..
- השנייה, 'SMS' -> הוספת מספר חדש -> אימות בטלפון.
- טיפ: אני אוהב להשתמש באמוג'י בשמות. זה כיף להדגמות.
- בסיום, לוחצים על הסמל X הגדול בפינה השמאלית העליונה.
- בוחרים קודם את הטלפון (מהיר) ואז את האימייל (איטי).
- מוסיפים מסמכי עזרה לדוגמה, כמו:
[PHP Amarcord] Riccardo told me to type sudo reboot or to check documentation in http://example.com/playbooks/1.php but I guess he was joking
.
בינגו!
התוצאה הסופית
נוכל להתייחס לתהליך הזה כסיום אחרי שתגדירו יעד SLO פעיל אחד ו-2 התראות לגבי הזמינות, וההתראות יישלחו לאימייל ולטלפון שלכם.
אם רוצים, אפשר להוסיף זמן אחזור (ומומלץ מאוד לעשות זאת) או אפילו זמן אחזור מורכב יותר. לזמן האחזור, בוחרים זמן אחזור שנראה לכם סביר. אם אתם לא בטוחים, בחרו באפשרות 200ms.
11. השלבים הבאים
השלמת הכול, מה חסר?
כמה דברים שכדאי לחשוב עליהם:
משחק עם Gemini
יש שתי גרסאות של Gemini:
- Vertex AI "הדרך הארגונית", שמשולבת עם GCP, כפי שראינו בפרק 7 (GCF+Gemini). כל תהליכי האימות פועלים בצורה מושלמת, והשירותים מקושרים בצורה מושלמת.
- AI מבית Google 'הדרך של הצרכן'. מקבלים מפתח API של Gemini כאן ומתחילים ליצור סקריפטים קטנים שאפשר לקשר לכל עומס עבודה שכבר קיים (עבודה קניינית, עננים אחרים, localhost וכו'). פשוט מחליפים את מפתח ה-API והקוד מתחיל לפעול כמו קסם.
מומלץ לנסות את (2) בפרויקטים משלכם.
שיפור ממשק המשתמש
אני לא טוב בממשקי משתמש. אבל Gemini כן. אפשר פשוט ליצור דף PHP אחד ולכתוב משהו כזה:
I have a VERY old PHP application. I want to touch it as little as possible. Can you help me:
1. add some nice CSS to it, a single static include for tailwind or similar, whatever you prefer
2. Transform the image print with description into cards, which fit 4 per line in the canvas?
Here's the code:
-----------------------------------
[Paste your PHP page, for instance index.php - mind the token limit!]
אפשר לעשות זאת בקלות תוך פחות מ-5 דקות, באמצעות Cloud Build. :)
התשובה מ-Gemini הייתה מושלמת (כלומר, לא הייתי צריך לשנות כלום):
זוהי הפריסה החדשה באפליקציה האישית של המחבר:
הערה: הקוד מועתק כתמונה כי אנחנו לא רוצים לעודד אתכם להשתמש בקוד, אלא לגרום ל-Gemini לכתוב את הקוד בשבילכם, עם אילוצים משלכם לממשק המשתמש או לחזית הקריאייטיב. תאמינו לי, בסיום תצטרכו לבצע שינויים קטנים מאוד.
אבטחה
אבטחת האפליקציה הזו בצורה נכונה היא לא מטרת הסדנה בת 4 השעות הזו, כי היא תגדיל את משך הסדנה פי 1-2.
עם זאת, הנושא הזה חשוב מאוד! אספנו כמה רעיונות ב-SECURITY
.
12. מעולה!
מזל טוב 🎉🎉🎉 , הצלחת לעדכן את אפליקציית ה-PHP הקודמת שלך באמצעות Google Cloud.
לסיכום, בשיעור ה-Codelab הזה למדתם:
- איך לפרוס מסד נתונים ב-Google Cloud SQL ואיך להעביר אליו את מסד הנתונים הקיים.
- איך מעבירים אפליקציות PHP לקונטיינרים באמצעות Docker ו-Buildpacks ומאחסנים את קובץ האימג' שלהן ב-Google Cloud Artifact Registry
- איך לפרוס אפליקציה בקונטיינרים ב-Cloud Run ולהפעיל אותה באמצעות Cloud SQL
- איך מאחסנים או משתמשים בחשאי בפרמטרים רגישים של הגדרות (כמו סיסמת מסד נתונים) באמצעות Google Secret Manager
- איך מגדירים צינור עיבוד נתונים ל-CI/CD באמצעות Google Cloud Build כדי ליצור ולפרוס באופן אוטומטי את אפליקציית ה-PHP בכל דחיפה של קוד למאגר ב-GitHub.
- איך משתמשים ב-Cloud Storage כדי להעביר את משאבי האפליקציה לענן
- איך משתמשים בטכנולוגיות ללא שרת (serverless) כדי ליצור תהליכי עבודה מדהימים ב-Google Cloud בלי לגעת בקוד של האפליקציה.
- שימוש ביכולות של Gemini לממשק רב-מודלי בתרחיש שימוש מתאים.
- הטמעת עקרונות SRE ב-Google Cloud
זהו מקום מצוין להתחיל בו את המסע שלכם למודרניזציה של אפליקציות באמצעות Google Cloud.
🔁 משוב
אם אתם רוצים לספר לנו על החוויה שלכם בסדנה הזו, אתם יכולים למלא את טופס המשוב הזה.
נשמח לקבל מכם משוב וגם בקשות לשינוי קוד על קטעי קוד שאתם גאים בהם במיוחד.
🙏 תודה
המחבר רוצה להודות ל-Mirko Gilioli ול-Maurizio Ipsale מ-Datatonic על העזרה בכתיבה ובבדיקת הפתרון.