הגדרת תיוג בצד השרת באמצעות App Engine

במדריך הזה נסביר איך:

  • הקצאת שרת תיוג ב-App Engine של Google Cloud Platform ‏ (GCP).
  • משדרגים את שרת התיוג כדי לטפל בתנועה בזמן אמת.
  • מגדילים או מקטינים את מספר השרתים שבהם מפעילים את מאגר התגים של Google Tag Manager.
  • חשוב לעדכן את הגרסה של שרת התיוג אחרי הקצאת השרת.

דרישות מוקדמות

  1. צריך חשבון GCP. אם אין לכם חשבון, יוצרים חשבון GCP חדש.
  2. צריך חשבון לחיוב ב-GCP. אם אין לכם חשבון כזה, יוצרים חשבון לחיוב ב-GCP (נדרש התפקיד 'יצירת חשבון לחיוב').
  3. צריך את התפקידים 'יצירת פרויקטים' ו'משתמש בחשבון לחיוב'. מידע נוסף על הוספת תפקידים

1. הקצאת שרת

כדי ליצור שרת חדש לתיוג במכונה של App Engine, צריך:

  • יצירת מאגר תגים חדש בצד השרת ב-Tag Manager
  • יצירת פרויקט חדש ב-Google Cloud (GCP)
  • הקצאה של שרת תיוג חדש ב-App Engine
  • מוסיפים את כתובת ה-URL של שרת התיוג החדש למאגר התגים בצד השרת של Tag Manager.

יצירת מאגר תגים בצד השרת של Google Tag Manager

  1. פותחים את Google Tag Manager.

  2. בשורת החשבון, לוחצים על סמל האפשרויות הנוספות > Create Container (יצירת מאגר).

  3. יוצרים קונטיינר שרת חדש.

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

יצירת פרויקט GCP חדש

כדי ליצור פרויקט GCP חדש לשרת התיוג:

  1. פותחים את מסוף Google Cloud.

  2. יוצרים פרויקט חדש ב-GCP.

  3. נותנים שם לפרויקט. מומלץ להשתמש במזהה הקונטיינר למען הנוחות. השם הזה משמש רק ב-GCP.

  4. שימו לב למזהה הפרויקט ב-GCP, כי תצטרכו אותו כדי ליצור את שרת התיוג.

הקצאה של שרת תיוג חדש

כדי ליצור את שרת התיוג:

  1. פותחים את Cloud Shell.

  2. מגדירים את פרויקט GCP ב-Cloud Shell. מחליפים את project ID במזהה הפרויקט ב-GCP שציינתם קודם:

    gcloud config set project project ID

  3. יוצרים את שרת התיוג לפי סקריפט המעטפת. מגדירים את סוג הפריסה כ-testing.

    bash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"

מוסיפים ל-Tag Manager את כתובת ה-URL של שרת התיוג

  1. פותחים את Google Tag Manager.

  2. בדף ניהול > הגדרות מאגר התגים, לוחצים על הוספת כתובת אתר. אם אתם לא יודעים מהו כתובת ה-URL של השרת, מריצים את הפקודה הבאה ב-Cloud Shell:

    gcloud app browse

    תוצאה: הגדרתם שרת תיוג והקציתם לו הגדרות אישיות testing. עכשיו אפשר לבדוק תיוג בצד השרת.

הגדרת השרת הראשונית (testing)

הגדרת הבדיקה מתאימה לבדיקה של המוצר באמצעות שליחת כמויות קטנות של תנועה לצורך בדיקה ושימוש בתכונה 'תצוגה מקדימה' ב-Tag Manager. ההגדרה הזו היא סוג מכונה F1 ב-App Engine בסביבה הרגילה, וברוב המקרים לא תחויבו.

2. שימוש ב-App Engine בסביבת ייצור

בהגדרה production, כל שרת עולה כ-40 $לחודש (USD). כל שרת הוא מכונה של App Engine עם 1vCPU, 0.5GB זיכרון, 10GB דיסק בסביבה הגמישה.

במאמר ניהול העלויות ב-App Engine מוסבר איך מגדירים התראות בחיוב ואיך מבינים את החיוב ב-App Engine. מומלץ מאוד להגדיר התראה בחיוב.

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

כדי להגדיר את שרת התיוג:

  1. פותחים את Cloud Shell של Google Cloud Platform.
  2. מגדירים את פרויקט Cloud Platform ב-Cloud Shell. מחליפים את project ID במזהה הפרויקט ב-GCP שציינתם קודם: 
    gcloud config set project project ID
  3. כדי להגדיר מחדש את שרת התיוג לסביבת ייצור, מריצים את סקריפט ההגדרה שבהמשך. מבצעים את המשימות הבאות: 
    bash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"
    1. משנים את סוג הפריסה ל-production.
    2. מגדירים שרתים נוספים כדי לשרת את התנועה בסביבת הייצור. מומלץ להשתמש לפחות בשלושה שרתים.

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

רישום ביומן של בקשות

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

כדי להשבית את הרישום ביומן של בקשות ב-App Engine:

  1. בפלטפורמת Google Cloud, פותחים את Logs Router. צריך לוודא שהפרויקט נמצא בפרויקט התואם למזהה מאגר התגים:
    צילום מסך של בורר הפרויקט ב-GCP, שבו מוצג מזהה מאגר תגים לדוגמה ב-Tag Manager.
  2. בשביל Type: Cloud Logging bucket או Name: _Default, בוחרים את האפשרויות הנוספות ולוחצים על Edit Sink.
  3. בקטע Sink destination, בוחרים את הקטגוריה של היומנים _Default.

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

    NOT LOG_ID("appengine.googleapis.com/nginx.request") AND NOT
LOG_ID("appengine.googleapis.com/request_log")

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

    NOT LOG_ID("requests")

  6. מעדכנים את Sink כדי להחיל את השינויים. מעכשיו, הבקשות מ-App Engine לא ייכללו ברישום ביומן.

  7. מוודאים שאין בקשות חדשות ביומנים של Logs Explorer.

רישום ביומן של מסוף

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

מזהים יומני מסוף לא רצויים:

  1. ב-GCP, פותחים את Logs Explorer.

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

    תג עשוי לשלוח את היומנים הבאים:

    const logToConsole = require('logToConsole');

logToConsole('Custom message: ' + data.param1);
logToConsole('An important message to keep around!');
data.gtmOnSuccess()

    מחפשים את הודעות היומן התואמות בשדה textPayload:
    צילום מסך של GCP Logs Explorer, שבו מוצגים יומנים לדוגמה.

כדי להשבית את ההודעה ביומן המסוף:

  1. בפלטפורמת Google Cloud, פותחים את Logs Router. צריך לוודא שהפרויקט נמצא בפרויקט התואם למזהה מאגר התגים:
    צילום מסך של בורר הפרויקטים ב-GCP, שבו מוצג מזהה מאגר לדוגמה ב-Tag Manager.
  2. בשורה Type: Cloud Logging bucket, Name: _Default, בוחרים בתפריט הנפתח ואז לוחצים על Edit Sink.
  3. בקטע Sink destination, בוחרים את הקטגוריה של היומנים _Default.

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

    NOT textPayload:"Custom message:"

    ביומני המסוף, מחליפים את הטקסט Custom message: במחרוזת משנה מיומן המסוף שרוצים להשבית. למסננים מפורטים יותר, אפשר להשתמש בשפת שאילתת הרישום ביומן.

  5. מעדכנים את Sink כדי להחיל את השינויים. צריך להחריג את הודעת logToConsole התואמת ברישום ביומן.

  6. מוודאים שלא מופיעות ב-Logs Explorer הודעות חדשות ביומן של המסוף.

3. מיפוי הפריסה לדומיין המותאם אישית

פריסת ברירת המחדל של תיוג בצד השרת מתארחת בדומיין של App Engine. מומלץ לשנות את הפריסה כך שתשתמש בתת-דומיין של האתר.

ממפים את תת-הדומיין של האתר לשרת התיוג.

4. הוספת כתובת ה-URL של השרת ל-Google Tag Manager

עכשיו, כשיש לכם שרת, עליכם לוודא שמערכת Google Tag Manager יודעת שהיא צריכה להשתמש בשרת שלכם.

  1. פותחים את Google Tag Manager.

  2. לוחצים על מאגר התגים בצד השרת שרוצים להפנות לשרת התיוג.

  3. פותחים את הגדרות מאגר התגים בצד השרת בכרטיסייה Admin > הגדרות קונטיינר.

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

  5. לוחצים על שמירה וחוזרים לסביבת העבודה.

5. אימות

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

הצגת תצוגה מקדימה של כמה כתובות URL

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

אם סיפקתם כמה כתובות URL, כל הנתיבים (המחרוזת אחרי שם הדומיין) חייבים להתאים.

Works לא פועל
כתובת URL 1: example.com/abc
כתובת URL 2: example2.com/abc		 כתובת URL 1: example.com/abc
כתובת URL 2: example2.com/def

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

עדכון הגרסה של שרת התיוג

עדכונים חדשים לשרת התיוג כוללים תיקונים לפגיעויות באבטחה ותכונות חדשות. כאשר Tag Manager מודיע לכם לבצע עדכון, מומלץ לעדכן לפחות את שרת התיוג של כל גרסה ראשית (למשל, שדרוג מגרסה 1.x.x ל-x.x).

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

כדי לעדכן את שרת התיוג:

  1. פותחים את Cloud Shell של Google Cloud Platform.
  2. מגדירים את הפרויקט ב-Cloud Platform ב-Cloud Shell. מחליפים את project ID במזהה הפרויקט ב-GCP שציינתם קודם: 
    gcloud config set project project ID
  3. מריצים את סקריפט ההגדרה עם אותן הגדרות שבהן השתמשתם קודם. ההגדרות הקיימות מוגדרות כברירת מחדל. 
    bash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"

כדי לוודא שהעדכון בוצע בהצלחה:

  1. במאגר השרת, לוחצים על הלחצן Preview כדי להתחיל סשן ניפוי באגים חדש ולשלוח בקשה בכרטיסייה נפרדת.
  2. ב-Summary, בוחרים בכרטיסייה Console ומוודאים שאין הודעות שמבקשות לעדכן את שרת התיוג.

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

פתרון בעיות של זמן קצוב לתפוגה בפריסה בסביבת הייצור

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

  1. לחשבונות השירות יש הרשאות שגויות – חשבונות השירות של Compute Engine ו-App Engine אחראים לפריסה ולתחזוקה של פריסת הייצור. כברירת מחדל, הם מוגדרים מראש עם ההרשאות המתאימות. עם זאת, במקרים מסוימים, המדיניות של הארגון עלולה להיות שגויה.

    1. נכנסים לדף IAM &Admin בסרגל הניווט הימני במסוף Google Cloud.
    2. מחפשים את חשבון השירות של Compute Engine‏ <project_number>-compute@developer.gserviceaccount.com ואת חשבון השירות של App Engine‏ <project_name>@appspot.gserviceaccount.com.
    3. שני חשבונות השירות חייבים לכלול את התפקיד Editor. אם לאחד מהחשבונות אין את התפקיד Editor, מעדכנים את התפקיד בלחיצה על סמל העיפרון שמשמאל לחשבון, לוחצים על התפריט הנפתח של התפקיד הקיים, גוללים למעלה לראש הרשימה ולוחצים על Project ואז על Editor.

  2. מכסה לא מספיקה – הפריסה בסביבת הייצור צורכת מכסה של Compute Engine. אם אין מספיק מכסה בפרויקט, יכול להיות שהפריסה תסתיים תוך זמן קצר במהלך הקצאת המשאבים.

    1. עוברים לדף IAM & Admin בסרגל הניווט הימני במסוף Google Cloud, ולוחצים על הכרטיסייה Quotas בסרגל הניווט הימני.
    2. בחלק העליון של הדף, לוחצים על תיבת הטקסט סינון הטבלה ומקלידים Compute Engine API. לוחצים על התוצאה היחידה.
    3. מוודאים שכל הסטטוסים של המכסות בטווח המגבלה או שיש להם סימן וי ירוק.
    4. מאתרים את האפשרות מעבדים ולוחצים עליה. מוודאים שהשימוש הנוכחי ועוד מספר המכונות שנפרסות עדיין נמוכים מהמגבלה באזור הפריסה.