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

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

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

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

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

1. הקצאת שרת

כדי ליצור שרת תיוג חדש במופע של App Engine:

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

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

פותחים את Google Tag Manager.
בשורת החשבון, לוחצים על סמל האפשרויות הנוספות > Create Container (יצירת מאגר).
יוצרים קונטיינר שרת חדש.
לוחצים על לחצן הבחירה 'הקצאה ידנית של שרת תיוג'. שימו לב להגדרות הקונטיינר. תצטרכו אותו כדי להקצות את השרת.

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

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

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

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

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

פותחים את Cloud Shell.
מגדירים את פרויקט GCP ב-Cloud Shell. מחליפים את project ID במזהה הפרויקט ב-GCP שציינתם קודם:
```
gcloud config set project project ID
```
יוצרים את שרת התיוג באמצעות סקריפט של המעטפת. מגדירים את סוג הפריסה כ-testing.

טיפ: אם אתם לא בטוחים מה להזין בהנחיות, תוכלו להקליד ? כדי לקבל עזרה.
```
bash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"
```

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

פותחים את Google Tag Manager.
בדף ניהול > הגדרות מאגר התגים, לוחצים על הוספת כתובת אתר. אם אתם לא יודעים מהו כתובת ה-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 בקשות לשנייה. הביצועים תלויים במספר התגים ובפעולות שהם מבצעים.

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

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

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

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

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

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

בפלטפורמת Google Cloud, פותחים את Logs Router. מוודאים שנמצאים בפרויקט שמתאים למזהה המאגר:
בשביל Type: Cloud Logging bucket או Name: _Default, בוחרים את האפשרויות הנוספות ולוחצים על Edit Sink.
בקטע Sink destination, בוחרים את הקטגוריה של היומנים _Default.
בקטע בחירת יומנים שייכללו ב-sink, מוסיפים שורה חדשה. מזינים את הכלל הבא במסנן ההכללה הקיים:
```
NOT LOG_ID("appengine.googleapis.com/nginx.request") AND NOT
LOG_ID("appengine.googleapis.com/request_log")
```
כדי להשבית גם את הרישום ביומן ממאזן העומסים, מוסיפים שורה חדשה ומזינים את הכלל הבא במסנן ההכללה הקיים:
```
NOT LOG_ID("requests")
```
הערה: הפעולה הזו משביתה את כל הרישום ביומן של מאזן העומסים, כולל בקשות שלא נשלחות לקונטיינר השרת.
מעדכנים את Sink כדי להחיל את השינויים. מעכשיו, הבקשות מ-App Engine לא ייכללו ברישום ביומן.
מוודאים שאין בקשות חדשות ביומנים של Logs Explorer.

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

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

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

ב-GCP, פותחים את Logs Explorer.
חפשו הודעות לא רצויות ביומן שמקורן בתגים. לדוגמה:

תג עשוי לשלוח את היומנים הבאים:
```
const logToConsole = require('logToConsole');

logToConsole('Custom message: ' + data.param1);
logToConsole('An important message to keep around!');
data.gtmOnSuccess()
```
מחפשים את הודעות היומן המתאימות בשדה textPayload:

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

בפלטפורמת Google Cloud, פותחים את Logs Router. מוודאים שנמצאים בפרויקט שמתאים למזהה המאגר:
בשורה Type: Cloud Logging bucket, Name: _Default, בוחרים בתפריט הנפתח ואז לוחצים על Edit Sink.
בקטע Sink destination, בוחרים את הקטגוריה של היומנים _Default.
בקטע בחירת יומנים שייכללו ב-sink, מוסיפים שורה חדשה. מזינים את הכלל הבא למסנן ההכללה הקיים:
```
NOT textPayload:"Custom message:"
```
ביומני המסוף, מחליפים את הטקסט Custom message: במחרוזת משנה מיומן המסוף שרוצים להשבית. כדי ליצור מסננים מורכבים יותר, אפשר להשתמש בשפת השאילתות של הרישום ביומן.
מעדכנים את Sink כדי להחיל את השינויים. צריך להחריג מהיומן את ההודעה התואמת logToConsole.
מוודאים שאין הודעות חדשות ביומן המסוף בכלי לניהול יומנים.

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

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

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

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

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

פותחים את Google Tag Manager.
לוחצים על מאגר התגים בצד השרת שרוצים להפנות לשרת התיוג.
פותחים את הגדרות מאגר התגים בצד השרת בכרטיסייה Admin > הגדרות קונטיינר.
לוחצים על הוספת כתובת URL ומדביקים את כתובת ה-URL של השרת.
שומרים וחוזרים לסביבת העבודה.

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, יופיע סמל לצד הלחצן תצוגה מקדימה, שמאפשר לבחור את כתובת ה-URL שרוצים להציג בתצוגה המקדימה.

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

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

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

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

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

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

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

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

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

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

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