הגדרת תיוג בצד השרת באמצעות Cloud Run

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

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

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

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

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

אפשר להקצות שירות Cloud Run באופן אוטומטי ב-Google Tag Manager או באופן ידני ב-Google Cloud.

עריכת הגדרות השירות

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

פותחים את Cloud Run.
בוחרים את השירות שרוצים לשנות.
לוחצים על עריכה ופריסה של גרסה חדשה.
מבצעים את השינויים ולוחצים על פריסה.

עלות Cloud Run

בהגדרת Cloud Run הזו, כל שרת עולה בערך 45 $לחודש. כל שרת הוא מכונת Cloud Run עם 1 vCPU וזיכרון בנפח 0.5GB, שפועלת לפי מודל התמחור של הקצאת מעבד תמיד.

מומלץ להריץ לפחות 2 מופעים כדי להפחית את הסיכון לאובדן נתונים במקרה של הפסקת פעולה של השרת. עם זאת, אתם יכולים לבחור להפעיל פחות (או יותר) שרתים. אנחנו מצפים ששינוי גודל אוטומטי של 2 עד 10 שרתים יטפל ב-35 עד 350 בקשות בשנייה, אבל הביצועים ישתנו בהתאם למספר התגים ולפעולות שהתגים האלה מבצעים.

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

אומדן עלויות ב-Cloud Run

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

אופציונלי: מעבר מ-App Engine

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

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

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

לפני שמתחילים:

יצירת מאזן עומסים
רושמים את BACKEND_NAME שבחרתם.

כדי להוסיף עוד אזורים לפריסה:

מחליפים את REGION באזור שבו שרת התצוגה המקדימה נפרס. יכול להיות שהשדה הזה כבר ימולא אם פעלתם לפי האפשרויות של שורת הפקודה כדי להקצות את שרת התצוגה המקדימה והתיוג.
מחליפים את CONTAINER_CONFIG במחרוזת ההגדרות של מאגר התגים מ-Tag Manager. יכול להיות שהשדה הזה כבר ימולא אם פעלתם לפי האפשרויות של שורת הפקודה כדי להקצות את שרת התיוג והתצוגה המקדימה.
מחליפים את NEW_REGION באזור החדש שבו רוצים לפרוס את שרת התיוג.
מחליפים את BACKEND_NAME בשם שבחרתם בזמן הקצאת משאבים למאזן העומסים.
אופציונלי: כדי להוסיף עוד אזור, מחליפים את המשתנה NEW_REGION ומריצים מחדש את קטע הקוד.

    gcloud run deploy "server-side-tagging" \
    --region NEW_REGION \
    --image gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable \
    --platform managed \
    --ingress all \
    --min-instances 2 \
    --max-instances 10 \
    --timeout 60 \
    --allow-unauthenticated \
    --no-cpu-throttling \
    --update-env-vars PREVIEW_SERVER_URL="$(
      gcloud run services describe server-side-tagging-preview \--region "REGION" \
      --format="value(status.url)")",CONTAINER_CONFIG="CONTAINER_CONFIG" && \

    gcloud compute network-endpoint-groups create server-side-tagging-neg \
    --region=NEW_REGION \
    --network-endpoint-type=SERVERLESS \
    --cloud-run-service="server-side-tagging" && \

    gcloud compute backend-services add-backend --global "BACKEND_NAME" \
    --network-endpoint-group-region=NEW_REGION \
    --network-endpoint-group=server-side-tagging-neg

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

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

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

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

ב-Google Cloud Platform, פותחים את Logs Router. מוודאים שאתם נמצאים בפרויקט שתואם למזהה מאגר התגים:
בשורה Type: Cloud Logging bucket, Name: _Default, לוחצים על סמל האפשרויות הנוספות ואז על Edit Sink.
בקטע יעד להעברה, בוחרים את קטגוריית היומנים _Default.
בקטע בחירת יומנים שיכללו ב-Sink, מוסיפים שורה חדשה. מזינים את הכלל הבא למסנן ההכללה הקיים:
```
NOT LOG_ID("run.googleapis.com/requests")
```
כדי להשבית גם את הרישום ביומן של מאזן העומסים, מוסיפים שורה חדשה ומזינים את הכלל הבא למסנן ההכללה הקיים:
```
NOT LOG_ID("requests")
```
הערה: הפעולה הזו תשבית את כל הרישום ביומן של מאזן העומסים, כולל בקשות שלא נשלחות למאגר השרתים.
לוחצים על עדכון יעד כדי להחיל את השינויים. עכשיו הבקשות לא ייכללו ברישום ביומן.
מוודאים שלא מופיעות בקשות חדשות ביומנים של 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 Platform, פותחים את Logs Router. מוודאים שאתם נמצאים בפרויקט שתואם למזהה מאגר התגים:
בשורה Type: Cloud Logging bucket, Name: _Default, לוחצים על סמל האפשרויות הנוספות ואז על Edit Sink.
בקטע יעד להעברה, בוחרים את קטגוריית היומנים _Default.
בקטע בחירת יומנים שיכללו ב-Sink, מוסיפים שורה חדשה. מזינים את הכלל הבא למסנן ההכללה הקיים:
```
NOT textPayload:"Custom message:"
```
במקום הטקסט Custom message: ביומני המסוף, מחליפים אותו במחרוזת משנה מיומן המסוף שרוצים להשבית. כדי להשתמש במסננים מורכבים יותר, אפשר להיעזר בשפת השאילתות של רישום ביומן.
לוחצים על עדכון יעד כדי להחיל את השינויים. ההודעה התואמת logToConsole צריכה להיות מוחרגת מהרישום ביומן.
מוודאים שלא מופיעות הודעות חדשות ביומן המסוף בLogs Explorer.

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

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

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

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

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

4. אימות

אחרי שמגדירים את שרת התיוג, צריך לוודא שהוא פועל כמצופה. בסביבת העבודה ב-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 Run.
בוחרים את השירות שרוצים לעדכן.
לוחצים על עריכה ופריסה של גרסה חדשה.
מוודאים שכתובת ה-URL של תמונת המאגר Container image URL מוגדרת ל-gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable ולוחצים על Deploy (פריסה).

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

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

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