דף זה תורגם על ידי Cloud Translation API.

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

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

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

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

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

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

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

עריכת תצורת השירות

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

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

עלות Cloud Run

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

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

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

מחשבון Cloud Run

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

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

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

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

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

תג עשוי לשלוח את היומנים הבאים:
```
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.
מוודאים שאין הודעות חדשות ביומן המסוף בכלי לניהול יומנים.

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

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

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

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

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

4. אימות

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

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

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

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

פותחים את Cloud Run.
בוחרים את השירות שרוצים לעדכן.
לוחצים על עריכה ופריסה של גרסה חדשה.
מוודאים שכתובת ה-URL של קובץ האימג' בקונטיינר מוגדרת כ-gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable ולוחצים על פריסה.

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

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

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