סדנת עיצוב של אפליקציות

1. מבוא

תאריך עדכון אחרון: 1 בנובמבר 2024

איך מבצעים מודרניזציה של אפליקציית PHP ישנה ב-Google Cloud?

(📽️ סרטון מבוא של 7 דקות ל-Codelab הזה)

נניח: הבוס שלכם רוצה שתיקחו אפליקציה ישנה ותחיו אותה. המפתח האחרון עזב את החברה, השפה יצאה משימוש לפני 5 שנים, אבל עדיין יש לאפליקציה ערך עסקי גבוה. שמעתם שהאפליקציה מכילה סיסמאות בטקסט ללא הצפנה בקוד (המפתח היה ממהר לשנות תפקיד ולא ציפה להצלחה של האפליקציה הזו), ושהיא נפרסה באופן ידני בסביבת הייצור. אף אחד לא זוכר איך זה נעשה.

הגיע הזמן אתם לעדכן את האפליקציה בהתאם לטכנולוגיות העדכניות ביותר ולהתאים את האפליקציה ל 12-factor, אבל אתם לא רוצים ללמוד שפה ישנה שלא נתמכת. מה אפשר לעשות?

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

בסדנה הזו תלמדו:

1. מיקום האפליקציה בקונטיינר.
2. מעבר לשירות מנוהל של מסד נתונים ( Cloud SQL).
3. פריסה ב-Cloud Run (חלופה ל-GKE/Kubernetes ללא צורך בניהול).
4. אבטחת האפליקציה באמצעות ניהול זהויות והרשאות גישה (IAM) ו-Secret Manager.
5. הגדרת צינור עיבוד נתונים של CI/CD באמצעות Cloud Build. אפשר לחבר את Cloud Build למאגר Git שמתארח בספקי Git פופולריים כמו GitHub או GitLab, ולהפעיל אותו בכל דחיפה לרמה הראשית, לדוגמה.
6. אירוח התמונות של האפליקציה ב-Cloud Storage. הטעינה מתבצעת באמצעות טעינה, ואין צורך בקוד כדי לשנות את האפליקציה.
7. הצגת הפונקציונליות של AI גנרטיבי באמצעות Gemini, שמנוהלת באמצעות Cloud Functions (ללא שרת).
8. כדאי להכיר את ה-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/ תיקיות, לכל פרק.

ניתן להשלים את הסדנה הזאת במחשב המקומי או לבצע אותה לגמרי בדפדפן.

הערה: האימון הזה מיועד לשני דמויות משתמש: 'משתמשי GCP מתקדמים' (מקומי) ו'מפתחים רגילים' (אינטרנט).

• משתמשים עם התפקיד הזה ב-GCP יכולים להשתמש בתכנות באופן מקומי ב-vscode ולהתקין את gcloud, mysql, php וכן הלאה. סביר להניח שרוב התוכנות כבר מותקנות אצלכם, וכמובן שיש לכם Linux או Mac. התהליך הזה ידרוש יותר זמן, ובוודאות יהיה בו יותר חיכוך. מומלץ להתחיל עם האפשרות הבטוחה (השנייה)
• אם אתם לא משתמשים בהביתה של CLI, אם יש לכם מחשב Windows או אם אתם רוצים להיות בטוחים ויש לכם זמן מועט לפתור התנגשויות מקומיות, עדיף לכם להשתמש ב-Cloud Shell. קל מאוד להשתמש בו. זהו מעטפת בענן עם כל הקוד והסקריפטים הנדרשים שמותקנים מראש (gcloud,‏ skaffold,‏ mysql,‏ python,‏ ruby וכו'). הוא מנהל את האימות מהדפדפן, ותתפלאו כמה קל להשתמש בו. החיסרון היחיד הוא זמן אחזור ארוך יותר, כי הקוד לא מקומי במכונה. עם זאת, אפשר להבחין בשיפור המהירות של הגדרות הפיתוח 'יום 0' ו'יום 1'.

אם אתם לא בטוחים, מומלץ להתחיל עם Cloud Shell. תתפללו כמה התהליך חלק.

2. הגדרת קרדיט והסתעפות (fork)

מימוש הקרדיט ב-GCP והגדרת סביבת GCP [אופציונלי]

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

ליצור חשבון Gmail חדש לגמרי של Google (*) כדי לקשר לקרדיט שלכם ל-GCP. בקשו מהמורה קישור למימוש הזיכוי ל-GCP, או השתמשו בזיכויים כאן: bit.ly/PHP-Amarcord-credits .

נכנסים לחשבון החדש שנוצר ופועלים לפי ההוראות.

(

) למה צריך חשבון Gmail חדש לגמרי?*

ראינו אנשים שנכשלו ב-Codelab כי החשבון שלהם (במיוחד אימיילים של עבודות או סטודנטים) נחשף בעבר ל-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

1. נכנסים לאפליקציית הדגמה: https://github.com/gdgpescara/app-mod-workshop
2. לוחצים על סמל המזלג 🍴.
3. אם אין לכם חשבון GitHub, תצטרכו ליצור חשבון חדש.
4. עורכים את הפריטים לפי הצורך.

5. מעתיקים את קוד האפליקציה באמצעות git clone‏ https://github.com/<YOUR-GITHUB-USER>/<YOUR-REPO-NAME>

הערה: אפשר להריץ את הפקודה git clone באופן מקומי בסביבת VSCode או בשורת הפקודה של Google Cloud Shell.

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

ב-Google Cloud Shell Editor יש את כל מה שצריך, כפי שמוצג באיור הבא

הערה: למה צריך ליצור פורק מקור של מאגר? אין צורך בכך במודולים 2-4, אבל כן במודול Cloud Build כדי ליצור צינור עיבוד נתונים. אתם רוצים שה-build יופעל רק כשאתם תדחוף את השמירה ב-git, ולא אף אחד אחר. לכן צריך מאגר משלכם.

3. מודול 1: יצירת מכונה של SQL

הערה: השלב הזה ידרוש המתנה פעילה של כ-10 דקות. בסיום, אפשר לעבור לתרגול הבא. תכננו את זה כך שתוכלו לנסות לפתור את הבעיה ב-Docker בזמן ש-Google Cloud מפעיל את המכונה.

יצירת המכונה של Google Cloud SQL

אפליקציית ה-PHP שלנו תתחבר למסד נתונים של MySQL, ולכן אנחנו צריכים ליצור לה רפליקה ב-Google Cloud כדי להעביר אותה ללא בעיות. Cloud SQL הוא הפתרון המושלם, כי הוא מאפשר להריץ ב-Cloud מסד נתונים מנוהל של MySQL. אלה השלבים שצריך לבצע:

1. נכנסים לדף Cloud SQL: https://console.cloud.google.com/sql/instances
2. לוחצים על 'יצירת מכונה'
3. מפעילים את ה-API (אם צריך). התהליך עשוי להימשך כמה שניות.
4. בוחרים באפשרות MySQL.
5. (אנחנו מנסים לשלוח לך את הגרסה הזולה ביותר כדי שהיא תימשך זמן רב יותר):

• מהדורה: Enterprise
• הגדרה מוגדרת מראש: development (ניסינו את Sandbox והוא לא עבד בשבילנו)
• Mysql Ver: 5.7 (וואו, ד"ש מהעבר!)

6. מזהה המכונה: בוחרים באפשרות appmod-phpapp (אם משנים את הערך הזה, חשוב לזכור לשנות בהתאם גם את הסקריפטים והפתרונות העתידיים).
7. סיסמה: כל מה שתרצו, אבל חשוב לכתוב אותה כ-CLOUDSQL_INSTANCE_PASSWORD
8. אזור: משאירים את אותו אזור שבחרתם בשאר האפליקציה (למשל, תל אביב = europe-west8)
9. זמן פרסום בתחום מוגדר: תחום אחד (אנחנו חוסכים כסף להדגמה)

לוחצים על הלחצן Create Instance כדי לפרוס מסד נתונים ב-Cloud SQL. ⌛ לוקחת כ-10 דקות כדי להשלים את הניסוי. בינתיים אפשר להמשיך לקרוא את מסמכי התיעוד, ואפשר גם להתחיל לפתור את הבעיה של המודול הבא ('Containerize your PHP App') כי אין לו יחסי תלות במודול הזה בחלק הראשון (עד שמתקנים את חיבור ה-DB).

הערה. המכונה הזו אמורה לעלות לכם כ-7$ ליום. חשוב להקפיד להפעיל את השירות אחרי הסדנה.

יצירת image_catalog DB ו-User ב-Cloud SQL

פרויקט האפליקציה מגיע עם תיקייה db/ שמכילה שני קובצי SQL:

1. 01_schema.sql : מכיל קוד SQL כדי ליצור שתי טבלאות שמכילות נתוני משתמשים ותמונות.
2. 02_seed.sql: מכיל קוד SQL שמכניס את הנתונים לטבלאות הקודמות שנוצרו.

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

1. פותחים את המכונה ולוחצים על הכרטיסייה Databases (מסדי נתונים):
2. לוחצים על 'יצירת מסד נתונים'.
3. קוראים לו image_catalog (כמו בהגדרות האפליקציה של PHP).

לאחר מכן יוצרים את משתמש מסד הנתונים. כך נוכל לבצע אימות במסד הנתונים image_catalog.

1. עכשיו לוחצים על הכרטיסייה משתמשים
2. לוחצים על 'הוספת חשבון משתמש'.
3. משתמש: נוצר אחד:

• שם המשתמש/ת: appmod-phpapp-user
• סיסמה: יש לבחור משהו שאפשר לזכור או ללחוץ על 'יצירה'
• משאירים את האפשרות Allow any host (%).

4. לוחצים על 'הוספה'.

פתיחת ה-DB לכתובות IP ידועות.

שימו לב שכל מסדי הנתונים (DB) ב-Cloud SQL נולדים כ'מבודדים'. צריך להגדיר באופן מפורש רשת שתהיה זמינה ממנה.

1. לוחצים על המופע.
2. פתיחת התפריט 'חיבורים'
3. לוחצים על הכרטיסייה Networking.
4. לוחצים בקטע 'רשתות מורשות'. עכשיו מוסיפים רשת משנה.

• בינתיים, נגדיר את האפשרות ללא אבטחה כדי לאפשר לאפליקציה לפעול:
• שם: 'כל אדם שהוא – לא מאובטח' (חשוב לזכור שהפתרון הזול הזה גם לא מאובטח).
• רשת: ‎"0.0.0.0/0"‎ (הערה: האפשרות הזו לא מאובטחת!)

לוחצים על Save (שמירה).

התוצאה אמורה להיראות כך:

הערה הפתרון הזה הוא פשרה טובה לסיום הסדנה בזמן של O(hours). עם זאת, מומלץ לעיין במסמך אבטחה כדי לאבטח את הפתרון בסביבת הייצור.

הגיע הזמן לבדוק את החיבור למסד הנתונים!

כדי לבדוק אם משתמש image_catalog שיצרנו בעבר פועל, הוא פועל. נכנסים ל-Cloud SQL Studio בתוך המכונה ומזינים את מסד הנתונים, המשתמש והסיסמה שרוצים לאמת, כפי שמתואר בהמשך:

עכשיו, כשאתם נמצאים, אפשר לפתוח את עורך SQL ולהמשיך לחלק הבא.

ייבוא מסד הנתונים מקוד המקור

משתמשים בעורך SQL כדי לייבא את הטבלאות של image_catalog עם הנתונים שלהן. צריך לאחזר את קוד ה-SQL מקובצי ה-SQL במאגר ולהריץ אותם ברצף, אחד אחרי השני. 01_schema.sql ואז 02_seed.sql.

הערה: מתעלמים משגיאת תחביר בכלי לעריכת שאילתות SQL. השאילתות אמורות להתבצע בהצלחה.

אחר כך אמורות להופיע שתי טבלאות ב-image_catalog, שהן משתמשים ו-תמונות כפי שמוצג בהמשך:

כדי לבדוק את זה, מריצים את הפקודה הבאה בעורך: select * from images;

חשוב גם לרשום את כתובת ה-IP הציבורית, כי תצטרכו אותה בהמשך.

4. מודול 2: אריזה בקונטיינר של אפליקציית PHP

אנחנו רוצים לפתח את האפליקציה הזו לענן.

כלומר, צריך לארוז את הקוד בקובץ ZIP כלשהו שמכיל את כל המידע הדרוש להרצה שלו ב-Cloud.

יש כמה דרכים לארוז את הקוד:

• Docker. פופולרי מאוד, אבל מורכב למדי להגדרה בצורה נכונה.
• Buildpacks. פחות פופולרי, אבל נוטה 'לנחש' באופן אוטומטי מה צריך ליצור ומה צריך להריץ. לרוב זה פשוט עובד!

בהקשר של הסדנה הזו, נניח שאתם משתמשים ב-Docker.

Docker

אם אתם רוצים לשלוט בפרטים, זה הפתרון בשבילכם. כדאי להשתמש באפשרות הזו כשצריך להגדיר ספריות ספציפיות ולהחדיר התנהגויות מסוימות שלא ברורות לכולם (chmod בהעלאות, קובץ הפעלה לא סטנדרטי באפליקציה וכו').

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

# Use an official PHP image with Apache
# Pull a suitable php image
FROM __________# Define the env variable for the Apache listening port 8080
ENV __________

# Set working directory inside the container
WORKDIR __________

# Install required PHP extensions: PDO, MySQL, and other dependencies
RUN __________

# Copy all application files into the container
COPY __________

# Configure Apache to listen on port 8080. Use ‘sed' command to change the default listening port.
RUN __________

# When in doubt, always expose to port 8080
EXPOSE __________

# Start Apache in the foreground
CMD __________

בנוסף, כדי לבדוק את האפליקציה שלנו באופן מקומי, עלינו לשנות את הקובץ config.php כך שאפליקציית ה-PHP שלנו יתחברה ל-MYSQL db שזמין ב-Google CloudSQL. על סמך מה שהגדרתם קודם, ממלאים את הריקות.

• Db_host היא כתובת ה-IP הציבורית של Cloud SQL. אפשר למצוא אותה במסוף:

• השדה Db_name לא צריך להשתנות: image_catalog
• הערך של Db_user צריך להיות appmod-phpapp-user
• Db_pass הוא שם שבחרתם. מגדירים אותו במירכאות בודדות ומשתמשים בהן כפי הצורך.

<?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();
?>

בנוסף, אתם יכולים לתרגם את הקטעים הבודדים באיטלקית לאנגלית בעזרת Gemini.

בסדר, עכשיו שיש לכם את קובץ Dockerfile והגדרתם את אפליקציית ה-PHP להתחבר למסד הנתונים, ננסה את זה!

מתקינים את Docker אם הוא עדיין לא מותקן ( קישור). אם אתם משתמשים ב-Cloud Shell, אין צורך בכך (כמה מגניב זה?).

עכשיו ננסה ליצור ולהריץ את אפליקציית ה-PHP בקונטיינר באמצעות פקודות ה-build וההפעלה המתאימות של Docker.

• Docer build -t <IMAGE_TAG_NAME> .
• Docer run -it -p <CONTAINER PORT>:<LOCAL MACHINE PORT> <IMAGE_TAG_NAME>

אם הכול פועל, אמורה להופיע דף האינטרנט הבא כשמחוברים למארח המקומי.

אם אתם משתמשים ב-Cloud Shell, אתם יכולים גם לייצא את היציאה המקומית (למשל, 8080) לדפדפן, באופן הבא:

docker build -t my-php-app-docker app-mod-workshop/ -f Dockerfile

Docer run -it -p 8080:8080 my-php-app-docker

עכשיו אתם יודעים שהאפליקציה פועלת ביציאה 8080. לוחצים על הסמל 'תצוגה מקדימה באינטרנט' (דפדפן עם עין) ואז על תצוגה מקדימה ביציאה 8080 (או על 'שינוי יציאה' לכל יציאה אחרת).

בדיקת התוצאה בדפדפן

עכשיו האפליקציה אמורה להיראות כך:

אם תתחברו באמצעות Admin/admin123, אמור להופיע משהו כזה.

נהדר!!! פועל 🎉🎉🎉

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

כדאי לנסות שוב, כמעט הגעת!

Buildpacks [אופציונלי]

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

• מידע נוסף על BuildPacks ב-GCP זמין בכתובות https://cloud.google.com/docs/buildpacks/build-application ו-כאן.
• התקנה של pack: https://buildpacks.io/docs/for-platform-operators/how-to/integrate-ci/pack/
• buildpacks ב-PHP: https://cloud.google.com/docs/buildpacks/php (שבו מוסבר איך להגדיר את גרסת PHP)
• אפשר לנסות את הפקודה הבאה כדי ליצור את קובץ האימג' של הקונטיינר באופן אוטומטי.
• pack build --builder=gcr.io/buildpacks/builder my-app-with-buildpacks

אמורה להיות לכם קובץ אימג' חדש של Docker בסביבה המקומית. אפשר לנסות להריץ קונטיינר בשביל זה, אבל מכיוון שאין לנו שליטה מלאה על האופן שבו התמונה נוצרה, יכול להיות שהאפליקציה לא תפעל. בכל מקרה, אנחנו מזמינים אותך להתנסות ובמידה שהניסוי יצליח, לשתף את דעתך. תודה!

הערה: עדיין יש בקוד סיסמאות בטקסט ללא הצפנה. הבעיה הזו תטופל במודול 4.

שמירה ב-Artifact Registry [אופציונלי]

הערה: אין צורך בשלב הזה מכיוון ש-Cloud Run מריץ אותו בשבילכם. אפשר לדלג בבטחה. עם זאת, אם אתם רוצים לשלוט בתהליך או לשנות את התהליך באופן כלשהו, מומלץ לבצע את השלב הזה באופן ידני.

עכשיו אמורה להיות לכם אפליקציית 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]

התוצאה אמורה להיראות כמו בצילום המסך הבא.

יופי 🎉🎉🎉 עכשיו אפשר לעבור לשלב הבא.

הערה. כדאי לנסות גם את נקודת הקצה /upload.php ולנסות להעלות תמונה. ייתכן שתופיע ההודעה "ההרשאה נדחתה". אם כן, צריך לבצע תיקון chmod/chown ב-Dockerfile.

5. מודול 3: פריסת האפליקציה ב-Cloud Run

למה כדאי להשתמש ב-Cloud Run?

שאלה טובה! לפני כמה שנים, בטח הייתם בוחרים ב-Google App Engine.

במילים פשוטות, היום ל-Cloud Run יש סטאק טכנולוגי חדש יותר, קל יותר לפרוס אותו, הוא זול יותר והוא מתכוונן ל-0 כשלא משתמשים בו. בגלל הגמישות שלו להריץ כל קונטיינר ללא שמירת מצב והשילוב שלו עם שירותים שונים של Google Cloud, הוא אידיאלי לפריסה של מיקרו-שירותים (microservices) ואפליקציות מודרניות בתקורה מינימלית ויעילות מקסימלית.

באופן ספציפי יותר, 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 עם אותו משתמש (למשל [e-mail]) שמחובר ל-Google Cloud עם חיוב מופעל.

מפעילים את Cloud Run API באמצעות הפקודה הבאה

• $ gcloud services enable run.googleapis.com

בשלב הזה הכול מוכן לפריסה ב-Cloud Run.

פריסת האפליקציה ב-Cloud Run באמצעות gcloud

הפקודה שמאפשרת לפרוס את האפליקציה ב-Cloud Run היא gcloud run deploy. יש כמה אפשרויות להגדרה כדי להשיג את היעד. האפשרויות המינימליות הן:

1. השם של שירות Cloud Run שרוצים לפרוס בשביל האפליקציה. שירות Cloud Run יחזיר כתובת URL שמספקת נקודת קצה לאפליקציה.
2. אזור Google Cloud שבו האפליקציה תפעל.
3. קובץ אימג' בקונטיינר שמארז את האפליקציה.
4. משתני סביבה שהאפליקציה צריכה להשתמש בהם במהלך ההפעלה.
5. הדגל Allow-Unauthenticated שמאפשר לכולם לגשת לאפליקציה ללא אימות נוסף

במסמכי העזרה מוסבר איך להחיל את האפשרות הזו על הפקודה. הפריסה תימשך כמה דקות. אם הכול תקין, אתם אמורים לראות משהו כזה במסוף Google Cloud.

לוחצים על כתובת ה-URL שסופקה על ידי Cloud Run ובודקים את האפליקציה. לאחר האימות, אמור להופיע משהו כזה.

"gcloud running deploy" with "no questions"

יכול להיות שהבחנתם ש-gcloud run deploy שואל את השאלות הנכונות וממלא את הרווחים הלבנים שהשארתם. זה מדהים!

עם זאת, בכמה מודולים נוסיף את הפקודה הזו לטריגר של Cloud Build, כך שלא נוכל לענות על שאלות. אנחנו צריכים למלא כל אפשרות בפקודה. רוצים ליצור את gcloud run deploy --option1 blah --foo bar --region your-fav-region הזהב? איך עושים את זה?

1. חוזרים על שלבים 2-3-4 עד ש-gcloud מפסיק לשאול שאלות:
2. [LOOP] gcloud run deploy עם האפשרויות שנמצאו עד כה
3. [LOOP] מערכות מבקשות אפשרות X
4. [LOOP] מחפשים במסמכים הציבוריים איך להגדיר את X מ-CLI עם הוספת האפשרות --my-option [my-value].
5. חוזרים לשלב 2, אלא אם הפקודה gcloud מסתיימת בלי שאלות נוספות.
6. הפקודה 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') ?: _______;
$db_name = getenv('DB_NAME') ?: 'image_catalog';
$db_user = getenv('DB_USER') ?: 'appmod-phpapp-user';
$db_pass = getenv('DB_PASS') ?: _______;
// 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, בקובץ ה-Docker. מוסיפים לקובץ ה-Docker הקודם את 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

עכשיו השגתם את הדברים הבאים:

1. האפליקציה תקריא את המשתנה באופן דינמי מה-ENV
2. שיפור האבטחה, כי הסרת את הסיסמה של מסד הנתונים מהקוד)

עכשיו אפשר לפרוס גרסה חדשה ב-Cloud Run. נעבור לממשק המשתמש ונגדיר את משתני הסביבה באופן ידני:

• נכנסים לכתובת https://console.cloud.google.com/run
• לוחצים על האפליקציה.
• לוחצים על 'עריכה ופריסה של גרסה חדשה'
• בכרטיסייה הראשונה 'Container(s)', לוחצים על הכרטיסייה התחתונה 'משתנים וסודות'.
• לוחצים על '+ הוספת משתנה' ומוסיפים את כל המשתנים הנדרשים. בסיום התהליך, התוצאה אמורה להיראות כך:

זה מושלם? לא. ה-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 ENV ולהחליף אותו בסוד החדש. כך:

• גישה ל-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 צריך שני דברים:

1. מאגר Git אישי: למזלכם, כבר יצרתם ענף (fork) של מאגר הסדנה בחשבון GitHub שלכם בשלב 2. אם לא, חוזרים לשלב הזה ומסיימים אותו. המאגר המפצל אמור להיראות כך: https://github.com/<YOUR_GITHUB_USER>/app-mod-workshop
2. 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 שלי:

איך אנחנו עושים את כל זה?

1. על ידי יצירה של קובץ YAML מושלם אחד: cloudbuild.yaml
2. יצירת טריגר ב-Cloud Build.
3. על ידי חיבור למאגר GitHub שלנו דרך ממשק המשתמש של Cloud Build.

יצירת טריגר (וחיבור מאגר)

• עוברים לכתובת https://console.cloud.google.com/cloud-build/triggers.
• לוחצים על 'יצירת טריגר'.
• הידור:
• שם: משהו בעל משמעות כמו on-git-commit-build-php-app
• אירוע: דחיפה להסתעפות
• מקור: 'קישור מאגר חדש'
• ייפתח חלון בצד שמאל: 'קישור מאגר'.
• ספק המקור: 'Github' (ראשון)
• "Continue"
• ייפתח חלון ב-GitHub לאימות חוצה. פועלים לפי התהליך ומתאזרים בסבלנות. אם יש לכם הרבה מאגרים, התהליך עשוי להימשך זמן מה.
• 'בחירת מאגר' בוחרים את החשבון או המאגר ומסמנים את החלק 'הבנתי…'.
• אם מופיעה השגיאה: אפליקציית GitHub לא מותקנת באף אחד מהמאגרים שלכם, לוחצים על 'Install Google Cloud Build' (התקנת Google Cloud Build) ופועלים לפי ההוראות.
• לוחצים על 'התחברות'.
• 
• בינגו! המאגר מקושר עכשיו.
• חזרה לקטע 'טריגר'…
• הגדרה: זיהוי אוטומטי (*)
• מתקדם: בוחרים את חשבון השירות "[PROJECT_NUMBER]- [e-mail]"
• xxxxx הוא מזהה הפרויקט
• חשבון השירות של Compute Engine שמוגדר כברירת מחדל מתאים לניסוי – אל תשתמשו בו בסביבת הייצור! ( מידע נוסף)
• להשאיר את כל השאר כפי שהוא.
• לוחצים על הלחצן 'יצירה'.

(*) זו הדרך הפשוטה ביותר, כי היא בודקת אם קיים קובץ Dockerfile או cloudbuild.yaml. עם זאת, האפשרות cloudbuild.yaml מאפשרת לכם להחליט מה לעשות בכל שלב.

יש לי כוח!

עכשיו הטריגר לא יפעל אלא אם תעניקו לחשבון השירות ב-Cloud Build (מהו חשבון שירות? כתובת האימייל של 'רובוט' שפועל בשמכם במשימה מסוימת – במקרה הזה, פיתוח דברים ב-Cloud).

האדמין לא יוכל לבצע פיתוח ופריסה אלא אם תעניקו לו הרשאה לעשות זאת. למרבה המזל, זה קל!

• עוברים אל Cloud Build > Settings.
• חשבון שירות מסוג "[PROJECT_NUMBER]- [e-mail]"
• מסמנים את התיבות הבאות:
• 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.

איך שומרים קוד ל-github?

מעבר להיקף הסדנה, לא נלמד את הדרך הטובה ביותר להעלות את git push ל-GitHub. עם זאת, אם נתקעתם ב-Cloud Shell, יש שתי דרכים:

1. CLI. מוסיפים מפתח SSH באופן מקומי ומוסיפים מחשב מרוחק באמצעות [e-mail]:YOUR_USER/app-mod-workshop.git (במקום http)
2. 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 הגורמים לאפליקציה.

עם זאת, אנחנו משתמשים בשתי נקודות קצה (endpoint) שונות באינטרנט כדי שאפליקציה תפנה לאותו מסד נתונים. זה מספיק לצורך סדנה, אבל בחיים האמיתיים כדאי להקדיש זמן כדי ליצור סביבה ייעודית ל-prod. זה אומר שיש שני מסדי נתונים (אחד למפתחים ואחד ל-prod) וגם לבחור איפה הם נמצאים לצורך התאוששות מאסון (DR) / בזמינות גבוהה. זה לא עוסק בנושא הסדנה הזו, אבל כדאי לחשוב על זה.

אם יש לכם זמן ליצור גרסה 'עמוקה' של סביבה ייעודית ל-production, חשוב לזכור את כל המשאבים שצריך להעתיק, כמו:

• מסד נתונים של Cloud SQL (וכנראה גם מכונה של SQL).
• קטגוריית GCS
• פונקציה של Cloud Functions.
• אפשר להשתמש ב-Gemini 1.5 Flash כמודל בפיתוח (זול יותר, מהיר יותר) וב-Gemini 1.5 Pro (חזק יותר).

באופן כללי, בכל פעם שאתם מבצעים פעולה כלשהי באפליקציה, כדאי לחשוב באופן ביקורתי: האם צריך להגדיר את אותו ערך בסביבת הייצור או לא? אם לא, צריך להשקיע עוד מאמץ. כמובן שקל יותר להשתמש ב-Terraform, כאן אפשר להחדיר את הסביבה (-dev, -prod) כסיומת למשאבים.

8. מודול 6: מעבר ל-Google Cloud Storage

אחסון

נכון לעכשיו, האפליקציה מאחסנת את המצב בקונטיינר של Docker. אם המכונה תתקלקל, האפליקציה תתפוצץ או פשוט תשלחו גרסה חדשה, תתוזמן גרסה חדשה עם אחסון מאפס (=>ריק). 🙈

איך אנחנו מתקנים את זה? יש כמה גישות.

1. אחסון תמונות במסד הנתונים. זה מה שעשיתי עם אפליקציית ה-PHP הקודמת שלי. זה הפתרון הפשוט ביותר כי הוא לא מסובך יותר. אבל היא מוסיפה זמן אחזור ועומס למסד הנתונים.
2. מעבירים את אפליקציית Cloud Run לפתרון ידידותי לאחסון: GCE + דיסק אחסון מתמיד (persistent disk)? אולי GKE + Storage?
3. עוברים אל GCS. Google Cloud Storage הוא שירות האחסון הטוב ביותר מסוגו ב-Google Cloud, והוא הפתרון הכי טבעי לשימוש בענן. עם זאת, כדי לעשות זאת צריך להשתמש בספריות PHP. האם יש לנו ספריות PHP 5.7 ל-GCS? האם PHP 5.7 תומך ב-Composer בכלל (נראה שPHP 5.3.2 היא הגרסה המוקדמת ביותר שנתמכת על ידי Composer)?
4. אולי כדאי להשתמש ב-docker sidecar?
5. אפשר גם להשתמש ב-GCS Cloud Run Volume Mounts. זה נשמע מדהים.

🤔 העברת אחסון (פתוח)

[פתרון פתוח] במטלה הזו, אנחנו רוצים שתמצאו פתרון להעברת התמונות באופן שמאפשר לשמור אותן באופן כלשהו.

מבחן קבלה

אני לא רוצה לספר לך מה הפתרון, אבל אני רוצה שזה יקרה:

1. מעלים את newpic.jpg. הוא מופיע באפליקציה.
2. משדרגים את האפליקציה לגרסה חדשה.
3. newpic.jpg עדיין שם וגלוי.

💡 פתרון אפשרי (התקנת נפח אחסון ב-GCS Cloud Run)

זהו פתרון אלגנטי מאוד שמאפשר לנו לבצע העלאות של קבצים עם מצב (stateful) בלי לגעת בקוד בכלל (מלבד הצגת תיאור של תמונה, אבל זה טריוויאלי ורק לצורך הנאה).

הפעולות האלה אמורות לאפשר לכם לחבר תיקייה מ-Cloud Run ל-GCS, כך:

1. כל ההעלאות ל-GCS יוצגו באפליקציה.
2. בפועל, כל ההעלאות לאפליקציה שלך יועלו ל-GCS
3. דברים קסומים יתרחשו באובייקטים שהועלו ל-GCS (פרק 7).

הערה יש לקרוא את האותיות הקטנות של FUSE. זה לא בסדר אם יש בעיה בביצועים.

יצירת קטגוריה ב-GCS

GCS הוא שירות האחסון הנפוץ ביותר ב-Google Cloud. השירות הזה נבדק היטב, וכל שירות ב-GCP שזקוק לאחסון משתמש בו.

שימו לב שאתם מייצאים את PROJECT_ID ל-Cloud Shell בתור 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.

אפשר להשיג את זה גם דרך ממשק המשתמש

1. בכרטיסייה Volumes (נפחים), יוצרים Volume Mounts (חיבור נפח אחסון) שמצביעים לקטגוריה, מסוג Cloud Storage bucket (קטגוריית Cloud Storage), לדוגמה, עם השם php_uploads.
2. בקטע 'קונטיינרים' > 'טעינות עוצמת קול' טוענות עוצמת הקול שנוצרה כרגע בנקודת עוצמת הקול שהאפליקציה מבקשת. האפשרות הזו תלויה בקובץ ה-Docker, אבל היא עשויה להיראות כך: var/www/html/uploads/ .

בכל מקרה, אם זה עובד, כשעורכים את הגרסה החדשה ב-Cloud Run, אמור להופיע משהו כזה:

עכשיו צריך לבדוק את האפליקציה החדשה בהעלאה של תמונה חדשה אחת לנקודת הקצה (endpoint) של /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)

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

חשבתם פעם איך מטמיעים אפליקציה מבוססת-אירועים? משהו כזה:

• כשהאירוע <event> מתרחש => שולחים אימייל
• כשהאירוע <event> מתרחש => אם התנאי <condition> נכון, מעדכנים את מסד הנתונים.

אירוע יכול להיות כל דבר, החל מרשומות חדשות שזמינות ב-BigQuery, אובייקט חדש שהשתנה בתיקייה ב-GCS או הודעה חדשה שממתינה בתור ב-Pub/Sub.

ב-Google Cloud יש תמיכה במספר פרדיגמות שיעזרו לכם להשיג את המטרה הזו. במיוחד:

• EventArc. איך מקבלים אירועי GCS כלי מצוין ליצירת DAGs ולתזמור פעולות על סמך תנאי 'אם-אז-אחרת' ב-Cloud.
• Cloud Scheduler. למשל, נהדר למשימות cron בחצות בענן.
• Cloud Workflows. בדומה ל-Event Arc,
• Cloud Run Functions (נקרא גם lambdas).
• Cloud Composer. בעצם, זוהי הגרסה של Google ל-Apache Airflow, שמתאימה גם ל-DAG.

בתרגול הזה נעמיק ב-Cloud Functions כדי להגיע לתוצאה מרשימה למדי. וגם נספק לכם תרגילים אופציונליים.

לתשומת ליבך, קוד לדוגמה מסופק בכפוף ל-.solutions/

הגדרת פונקציית Cloud (🐍 Python)

אנחנו מנסים ליצור GCF שאפתני מאוד.

1. כשנוצרת תמונה חדשה ב-GCS. (כנראה שמישהו העלאה אותו לאפליקציה – אבל לא רק)
2. .. צריך לקרוא ל-Gemini כדי לתאר אותה ולקבל תיאור טקסטואלי של התמונה .. (כדאי לבדוק את ה-MIME ולוודא שזו תמונה ולא קובץ PDF,‏ MP3 או טקסט)
3. .. ולעדכן את מסד הנתונים בתיאור הזה. (יכול להיות שתצטרכו לתקן את מסד הנתונים כדי להוסיף עמודת description לטבלה images).

תיקון של מסד הנתונים להוספת description לתמונות

1. פותחים את Cloud SQL Studio:

2. הזנת המשתמש והסיסמה שלכם ל-DB של תמונות
3. מזינים את ה-SQL הבא שמוסיף עמודה לתיאור התמונה:

ALTER TABLE images ADD COLUMN description TEXT;

בינגו! עכשיו אפשר לבדוק אם זה עבד:

SELECT * FROM images;

העמודה החדשה של התיאורים אמורה להופיע:

כותבים את f(x) של Gemini

הערה הפונקציה הזו נוצרה בעזרת הכלי של Gemini לסיוע בקוד.

הערה כשיוצרים את הפונקציה הזו, יכול להיות שתקבלו שגיאות שקשורות להרשאות IAM. חלקם מתועדים למטה בפסקה 'שגיאות אפשריות'.

1. הפעלת ממשקי ה-API
2. עוברים לכתובת https://console.cloud.google.com/functions/list
3. לוחצים על 'Create Function' (יצירת פונקציה).
4. מפעילים את ממשקי ה-API באמצעות האשף של ממשקי ה-API:

אפשר ליצור את GCF דרך ממשק המשתמש או דרך שורת הפקודה. כאן נשתמש בשורת הפקודה.

קוד אפשרי מופיע בקטע .solutions/

1. יוצרים תיקייה לאירוח הקוד, למשל 'gcf/‎'. נכנסים לתיקייה.
2. יוצרים קובץ requirements.txt:

google-cloud-storage
google-cloud-aiplatform
pymysql

3. יוצרים פונקציית 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

4. לוחצים על הפונקציה. אפשר להשתמש בסקריפט דומה לזה: gcf/push-to-gcf.sh.

הערה 1. חשוב לספק את ערכי הסביבה עם הערכים הנכונים, או פשוט להוסיף אותם למעלה (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.

בדיקה מקצה לקצה

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

1. עוברים לאפליקציה ומתחברים.
2. להעלות תמונה (לא גדולה מדי, נתקלנו בבעיות עם תמונות גדולות)
3. בודקים בממשק המשתמש שהתמונה הועלתה.
4. בודקים ב-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 Functions באובייקטים חדשים שנוחתים ב-GCS. הפונקציה יכולה להוסיף הערות לתוכן של התמונה כמו שבן אדם יכול לעשות, ולעדכן את מסד הנתונים באופן אוטומטי. וואו!

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

[אופציונלי] הוספת עוד פונקציות של Cloud Functions [פתוח]

יש כמה תכונות נוספות שאפשר להוסיף.

📩 טריגר אימייל

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

• לעיתים קרובות מדי? מוסיפים אילוץ נוסף: תמונה גדולה, או תמונה שתוכן Gemini שלה מכיל את המילים 'עירום/עירום/אלימות'.
• כדאי לבדוק את זה ב-EventArc.

🚫 ניהול אוטומטי של תמונות בלתי הולמות

נכון לעכשיו, אדמין אנושי מסמנים תמונות כ'לא הולמות'. רוצים ש-Gemini ינהל את המרחב המשותף ויעשה את העבודה הקשה? מוסיפים בדיקה כדי לסמן תוכן בלתי הולם של טריגרים ולעדכן את מסד הנתונים, כפי שלמדנו בפונקציה הקודמת. כלומר, בעצם צריך לקחת את הפונקציה הקודמת, לשנות את ההנחיה ולעדכן את מסד הנתונים על סמך התשובה.

אזהרה. ל-AI גנרטיבי יש פלט בלתי צפוי. מוודאים שה'פלט של נכסי הקריאייטיב' מ-Gemini מועבר 'למסילה'. אפשר לבקש תשובה ודאית, כמו דירוג ביטחון מ-0 עד 1, קובץ JSON וכו'. אפשר לעשות זאת בדרכים רבות, למשל: * שימוש בספריות Python‏ pydantic,‏ langchain וכו'. * שימוש בפלט מובנה של Gemini.

טיפ. אתם יכולים להשתמש בפונקציות MULTIPLE או להגדיר הנחיה יחידה שאוכפת תשובה בפורמט JSON (הוא פועל עם "Gemini Structured Output" (פלט מובנה של 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

1. שימו לב שכדי לפרוס פונקציית GCF שמאזין לקטגוריה של GCS, עליכם להגדיר את ההרשאות המתאימות לחשבון השירות שבו אתם משתמשים לביצוע המשימה. למשל:

יכול להיות שתצטרכו גם להפעיל את ממשקי ה-API של EventArc – כמה דקות לפני שהם יהיו זמינים באופן מלא.

שגיאה: חסר Cloud Run invoker

2. תגובה נוספת מהממשק המשתמש לגבי הרשאות 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 הנדרשים היא:

1. https://console.cloud.google.com/vertex-ai
2. לוחצים על 'הפעלה של כל ממשקי ה-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 לזמינות

בפרק אנחנו מנסים להשיג את המטרה הזו:

1. יצירת SLI
2. יצירת יעדי SLO על סמך ה-SLI
3. יצירת התראות על סמך יעדי SLO

זהו נושא חשוב מאוד לכותב, כי ריצ'ארדו עובד בתחום 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.

• https://cloud.google.com/stackdriver/docs/solutions/slo-monitoring/ui/create-slo

אחרי שהאפליקציה שלכם פועלת ב-Cloud Run, זה קל מאוד לעשות את זה. זה לוקח לי 30 שניות.

• נכנסים לדף Cloud Run.
• לוחצים על האפליקציה או בוחרים בה.
• בוחרים בכרטיסייה SLOs.
• לוחצים על '+ יצירת SLO'.
• זמינות, מבוססת-בקשה
• המשך
• חודש ביומן / 99%.
• לוחצים על 'יצירת SLO'.

שלב 2: הגדרת התראות לגבי יעד ה-SLO הזה

מומלץ ליצור 2 התראות:

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

אם רוצים, אפשר להוסיף זמן אחזור (ומומלץ מאוד לעשות זאת) או אפילו זמן אחזור מורכב יותר. לזמן אחזור, יש לבחור זמן אחזור שסביר להניח שהוא הגיוני. אם יש ספק, כדאי לבחור 200 אלפיות שנייה.

11. השלבים הבאים

השלמת את כל המשימות. מה חסר?

חומר למחשבה:

משחקים עם Gemini

יש שתי דרכים להשתמש ב-Gemini:

1. Vertex AI. "הדרך הארגונית", שמשולבת עם GCP, כפי שבדקנו בפרק 7 (GCF+Gemini). כל תהליכי האימות פועלים בצורה מושלמת, והשירותים מקושרים בצורה מושלמת.
2. AI מבית Google. 'הדרך של הצרכן'. מקבלים מפתח API של Gemini כאן ומתחילים ליצור סקריפטים קטנים שאפשר לקשר לכל עומס עבודה שכבר יש לכם (עבודה קניינית, עננים אחרים, localhost וכו'). פשוט מחליפים את מפתח ה-API והקוד מתחיל לפעול כמו קסם.

אנחנו ממליצים לך לנסות (2) פרויקטים עם חיות מחמד.

הרמת ממשק משתמש (UI)

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

רעיונות נוספים זמינים בSECURITY doc.

12. מעולה!

מזל טוב 🎉🎉🎉 , הצלחת להעביר את אפליקציית ה-PHP הקודמת שלך למודל מודרני באמצעות Google Cloud.

לסיכום, בשיעור ה-Codelab הזה למדתם:

• איך לפרוס מסד נתונים של MySQL ב-Google Cloud SQL ואיך להעביר אליו את מסד הנתונים הקיים.
• איך מעבירים אפליקציות PHP לקונטיינרים באמצעות Docker ו-Buildpacks ומאחסנים את קובץ האימג' שלהן ב-Google Cloud Artifact Registry
• איך לפרוס אפליקציה בקונטיינרים ב-Cloud Run ולהפעיל אותה באמצעות Cloud SQL
• איך לאחסן/להשתמש בסודות של פרמטרים רגישים של הגדרות (כגון סיסמה ל-DB) באמצעות Google Secret Manager
• איך להגדיר את צינור עיבוד הנתונים של CI/CD באמצעות Google Cloud Build כדי ליצור ולפרוס באופן אוטומטי את אפליקציית ה-PHP בכל דחיפת קוד למאגר שלכם ב-GitHub.
• איך להשתמש ב-Cloud Storage כדי לבצע "cloudify" של משאבי האפליקציות שלכם
• איך להשתמש בטכנולוגיות ללא שרת (serverless) כדי לבנות תהליכי עבודה מדהימים על גבי Google Cloud, בלי לגעת בקוד של האפליקציה.
• שימוש ביכולות של Gemini למגוון מכשירים לתרחיש שימוש מתאים.

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

🔁 משוב

אם אתם רוצים לספר לנו על החוויה שלכם בסדנה הזו, אתם יכולים למלא את טופס המשוב הזה.

אנחנו מקבלים בברכה משוב וגם PR לקטעי קוד שאתם גאים בהם במיוחד.

🙏 תודה

המחבר רוצה להודות למירקו ג'יליולי (Mirko Gilioli) ולמאוריציו איפסלה (Maurizio Ipsale) מ-Datatonic על העזרה בכתיבה ובבדיקת הפתרון.