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

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

  • הקצאת שרת תיוג ב-Google Cloud Platform (GCP) App Engine.
  • שדרוג שרת התיוג לטיפול בתנועה בזמן אמת.
  • להגדיל או להקטין את מספר השרתים שמריצים את הקונטיינר של 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. בשורת החשבון, לוחצים על 'אפשרויות נוספות' > יצירת מאגר תגים.

  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. בקטע Admin (ניהול) > Container Settings (הגדרות מאגר תגים), לוחצים על Add URL (הוספת כתובת URL). אם לא ידוע לכם מהי כתובת ה-URL של השרת, מריצים את הפקודה הבאה ב-Cloud Shell:

    gcloud app browse

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

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

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

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

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

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

מומלץ להפעיל לפחות 3 שרתים, כדי לצמצם את הסיכון לאובדן נתונים במקרה של הפסקה זמנית בשירות. עם זאת, אפשר לבחור להפעיל פחות (או יותר) שרתים. אנחנו צופים שהתאמה לעומס (autoscaling) ב-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 Platform, פותחים את Logs Router. ודאו שאתם נמצאים בפרויקט שתואם למזהה מאגר התגים:
    צילום מסך של בורר הפרויקטים ב-GCP, עם מזהה מאגר לדוגמה של Tag Manager.
  2. בשדה Type: Cloud Logging bucket, בשורה Name: _Default, בוחרים בתפריט האפשרויות הנוספות ולוחצים על Edit Sink.
  3. בקטע Sink destination (יעד Sink), בוחרים באפשרות Log bucket _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 Platform, פותחים את Logs Router. ודאו שאתם נמצאים בפרויקט שתואם למזהה מאגר התגים:
    צילום מסך של בורר הפרויקטים ב-GCP, עם מזהה מאגר לדוגמה של Tag Manager.
  2. בשדה Type: Cloud Logging bucket, בשורה Name: _Default, בוחרים בתפריט האפשרויות הנוספות ולוחצים על Edit Sink.
  3. בקטע Sink destination (יעד Sink), בוחרים באפשרות Log bucket _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 > Container Settings (הגדרות קונטיינר).

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

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

5. אימות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    1. בסרגל הניווט השמאלי במסוף Google Cloud, נכנסים לדף IAM & Admin.
    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. ליד החלק העליון של הדף, לוחצים על תיבת הטקסט Filter table ומזינים Compute Engine API. לוחצים על התוצאה היחידה.
    3. מוודאים שכל הסטטוסים של המכסות נמצאים בטווח המגבלה או שמופיע סימן אישור ירוק.
    4. מחפשים את האפשרות CPU ולוחצים עליה. חשוב לוודא שהשימוש הנוכחי ומספר המכונות שנפרסות עדיין יהיו מתחת למגבלה של אזור הפריסה.