העברה בשירות עצמי מ-Looker (מקורי) אל Looker (Google Cloud Core)‎

במסמך הזה מפורטים השלבים הטכניים להעברת מופע Looker קיים מסביבת Looker (המקורית) אל Looker (Google Cloud Core).

‫Looker (Google Cloud core) היא סביבת פריסה שמשולבת באופן עמוק עם פלטפורמת Google Cloud . ‫Looker (ליבת Google Cloud) מתארח בתשתית של Google Cloud . אפשר לנהל אותו ישירות דרך Google Cloud המסוף, והוא משולב באופן מלא עם הרבה מהמוצרים, השירותים והיכולות האחרים של Google Cloud.

ב-Looker ‏ (שירות הליבה של Google Cloud) אין תמיכה במיגרציה ממופע Looker (מקורי) למופע Looker ‏ (שירות הליבה של Google Cloud) עם תמיכה ב-FIPS, כי מופעי Looker (מקורי) לא תומכים בתאימות ל-FIPS.

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

  1. מומלץ לעיין במסמכים הבאים כדי להכיר את Google Cloud העקרונות והכלים:
  2. כדי לברר אם מכונת Looker (המקורית) שלכם עומדת בדרישות להעברה, אפשר לפנות לאיש הקשר האחראי לחשבון שלכם. אם המופע שלכם עומד בדרישות, ושדרגתם את החוזה הקיים של Looker (original) כך שיכלול את Looker (Google Cloud core), תוכלו להשלים את השלבים במאמר הזה כדי להעביר את המופע.

  3. כדי לקבל את ההרשאות שדרושות לכם כדי להתכונן להעברה, בקשו מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט Google Cloud שבו ימוקם מופע Looker (Google Cloud core):

    • יצירת מופע של Looker (Google Cloud Core): אדמין של Looker‏ (roles/looker.admin).
    • הקצאת תפקידי IAM ב Google Cloud פרויקט: אדמין IAM בפרויקט (roles/resourcemanager.projectIamAdmin).
    • יוצרים קטגוריה של Cloud Storage: אדמין לניהול נפח האחסון (roles/storage.admin).

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

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

  4. כדי לנהל את המכונה (המקורית) של Looker בהכנה להעברה, צריכה להיות לכם הרשאת אדמין ב-Looker במכונה הזו.

  5. יוצרים מופע חדש של Looker (Google Cloud core)‎ שהוא 'ריק'.

    חשוב לבחור את המהדורה המתאימה, את סוג החיבור לרשת (חיבורים ציבוריים מאובטחים או חיבורים פרטיים) ואת מאפייני ההגדרה האחרים (CMEK,‏ VPC-SC) עבור מופע Looker (Google Cloud core) החדש, כדי לוודא שיש לו את היכולות הנדרשות. חלק מהתכונות ב-Looker (Google Cloud core) תלויות במהדורה שנבחרה או בסוג הרשת שנבחרה.

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

    עם זאת, מאפייני ההגדרה של Looker (Google Cloud core) שצוינו דרך Google Cloud המסוף, או שאפשר לציין רק במהלך יצירת המופע, לא נדרסים במהלך תהליך ההעברה.

סקירה כללית

באופן כללי, תהליך ההעברה מורכב מהשלבים הבאים:

  1. מוודאים שהמופע המקורי של Looker מוכן להעברה.
  2. מייצאים את הנתונים ממופע Looker (מקורי).
  3. מייבאים את הנתונים למופע החדש והריק של Looker (Google Cloud core).
  4. משלימים את ההגדרה של מופע Looker (Google Cloud Core)‎.
  5. להוציא משימוש את מופע Looker (המקורי).

בקטעים הבאים מוסבר בהרחבה על כל אחד מהשלבים האלה.

מוודאים שמופע Looker (מקורי) מוכן להעברה

כדי שתוכלו להעביר את מופע Looker (המקורי) שלכם, הוא צריך לעמוד בדרישות המוקדמות הבאות:

  • מופע Looker (מקורי) צריך להיות מנוהל על ידי Google (כלומר, לא מתארח אצל הלקוח) ולהתארח ב- Google Cloud או ב-Amazon Web Services.

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

בנוסף, לפני ההעברה צריך לבצע את הפעולות הבאות:

  • יש קבוצה קטנה של הבדלים בתכונות בין Looker (המקורי) לבין Looker (הליבה של Google Cloud). כדאי לעיין בהבדלים האלה כדי לוודא שהתכונות ב-Looker (Google Cloud core) עונות על הצרכים שלכם.

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

  • ‫Looker (Google Cloud Core) תומך רק בשיטות האימות Google OAuth,‏ SAML ו-OpenID Connect.

    • אם מופעלת במופע של Looker (מקורי) שיטת אימות אחרת (לדוגמה, אימייל וסיסמה, LDAP וכו'), תצטרכו להמיר את כל המשתמשים לשיטת אימות שנתמכת על ידי Looker (Google Cloud core).
    • אם מופע Looker (מקורי) כבר משתמש ב-Google OAuth, כל רשומות המשתמשים יועברו, אבל עדיין תצטרכו ליצור הרשאות IAM באופן ידני למשתמשים בפרויקט של מופע Looker (Google Cloud core).
    • אם מופעל SAML במופע Looker (מקורי), צריך להגדיר את ההגדרה 'מיזוג משתמשים באמצעות' בדף אימות SAML בלוח הבקרה לאדמין לערך Google או OIDC כדי למנוע שגיאה כשבודקים את אימות SAML.
    • אם מופע Looker (מקורי) שלכם משתמש ב-OIDC, ההגדרה Merge users using בדף OpenID Connect authentication בלוח הבקרה Admin צריכה להיות מוגדרת ל-Google או ל-SAML כדי למנוע שגיאה כשמבצעים test the OpenID Connect authentication.
    • אם אתם משתמשים בספק זהויות חיצוני, אתם צריכים לעדכן את כתובת ה-URL של הקריאה החוזרת בספק הזהויות לכתובת ה-URL של Looker (Google Cloud core) כדי לאפשר אימות במופע החדש של Looker (Google Cloud core).
    • אם מופע Looker (Google Cloud core) שלכם ישתמש ב-SAML או ב-OpenID Connect כשיטת אימות, מומלץ להגדיר גם Google OAuth, שמשמש כשיטת אימות לגיבוי עבור Looker (Google Cloud core).
    • אם אתם מתכוונים להשתמש בדומיין בהתאמה אישית במופע של Looker (Google Cloud core), אל תגדירו SAML או OpenID Connect למופע עד שהדומיין בהתאמה אישית יופעל.

  • במהלך ההעברה, שתי מכונות Looker – אחת של Looker (המקורית) ואחת של Looker (הליבה של Google Cloud) – יפעלו במקביל למשך תקופה מסוימת. כל פעילות אוטומטית שמתבצעת (כמו התראות ומסירות מתוזמנות של נתונים, וגם פעילות ברקע שמתבצעת גישה למסדי נתונים בעורף המערכת) עשויה להיות כפולה. כדי למנוע פעילות כפולה, מוחקים התראות אוטומטיות ותזמונים במופע Looker (מקורי) או במופע Looker (ליבת Google Cloud).

ייצוא הנתונים מהמופע המקורי של Looker

ייצוא הנתונים ממופעי Looker (מקורי) מתבצע בשני שלבים:

  1. יצירת מקום לאחסון נתוני ההעברה.
  2. מתחילים את הייצוא.

במאמר ייבוא או ייצוא נתונים חד-פעמיים למופע של Looker (Google Cloud core) מוסבר אילו נתונים נכללים בייצוא ואילו לא.

יצירת מקום לאחסון נתוני ההעברה

מבצעים את כל הפעולות הבאות באותו Google Cloud פרויקט שבו יצרתם את מופע Looker (Google Cloud core).

  1. יוצרים קטגוריה חדשה ב-Cloud Storage (לדוגמה, <bucket-name>).
    • הבאקט הזה ישמש לאחסון נתוני ההעברה.
    • פועלים לפי ההוראות בדף התיעוד בנושא יצירת מאגרי מידע.
    • שימו לב: הערך של <bucket-name> חייב להיות ייחודי בכל Google Cloud. מומלץ להוסיף קידומת לשם של מאגר האחסון עם מזהה ייחודי, כמו מזהה הפרויקט.
  2. בוחרים שם לתיקייה בתוך קטגוריית Cloud Storage (לדוגמה, <folder-name>). לא יוצרים את התיקייה בשלב הזה. מציינים את שם התיקייה במהלך בקשת הייצוא. הוא ייווצר אוטומטית במהלך תהליך הייצוא.
  3. יוצרים אוסף מפתחות ומפתח ב-Cloud KMS (לדוגמה, <kms_keyring_id> ו-<kms-key-id>).
  4. יוצרים חשבון שירות חדש במיוחד לצורך ההעברה (לדוגמה, <export-service-account>).

  5. מקצים את שני תפקידי ה-IAM הספציפיים הבאים: <export-service-account>

  6. יוצרים מפתח לחשבון שירות שמשויך ל-<export-service-account> ומורידים את קובץ מפתח ה-JSON.

שליחת בקשה לייצוא

אחרי שמוודאים שהמופע מוכן להעברה, יוצרים מופע 'ריק' של Looker (Google Cloud core) ויוצרים מקום לאחסון נתוני ההעברה, מזינים את הפרטים הבאים בדף Export בחלונית Admin של מופע Looker (original):

  • השם של הקטגוריה של Cloud Storage שיצרתם.
  • שם התיקייה ב-Cloud Storage – תיקייה עם השם הזה תיצור באופן אוטומטי במהלך הייצוא. כשהייצוא יסתיים, קובצי הייצוא יופיעו בתיקיית משנה עם חותמת זמן בתוך התיקייה הזו בקטגוריה של Cloud Storage שיצרתם.
  • שם מפתח ה-KMS.
  • טקסט ה-JSON שמכיל את המפתח של חשבון השירות.

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

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

מייבאים את הנתונים למופע החדש והריק של Looker (Google Cloud core)

אחרי שתייצאו את נתוני המופע, תוכלו לייבא אותם למופע Looker (Google Cloud core).

פועלים לפי ההוראות בדף ייבוא הנתונים מ-Cloud Storage למופע של Looker (Google Cloud core), ומפנים את הפקודות לקטגוריה ולתיקייה שבהן קובצי הייצוא ממוקמים.

פעולת הייבוא נמשכת בין דקות לשעות. בסיום, מופעלת מחדש אינטס Looker (Google Cloud core) עם כל הנתונים שהועברו.

השלמת ההגדרה של מכונת Looker (Google Cloud Core)

בשלב הזה, אדמינים ב-Looker יכולים לעבור אל כתובת ה-URL של המכונה ולהיכנס למכונה כדי להשלים את ההגדרה.

תהליך ההעברה מעתיק כמה שיותר מהגדרות המופע של Looker (המקורי). עם זאת, יש פריטים שלא ניתן להעביר, או שהם פועלים בצורה שונה ב-Looker (Google Cloud core), ולכן צריך לבצע בהם שינויים.

הנה כמה פריטים שחשוב לשים לב אליהם במיוחד:

הגדרות כלליות (בחלונית אדמין ב-Looker)

רוב האפשרויות בהגדרות כלליות (ובשאר ההגדרות בלוח הניהול) לא מועתקות באופן אוטומטי, כי הן בדרך כלל שונות או לא קיימות באותו פורמט ב-Looker (Google Cloud core). חשוב לבדוק ולהגדיר בקפידה את כל ההגדרות בהקשר של ההגדרה שבחרתם ב-Looker (Google Cloud core). מידע נוסף על ההגדרות ב-Looker (Google Cloud core) זמין בדפי התיעוד בנושא ניהול מופע של Looker (Google Cloud core) מ-Looker וניהול מופע של Looker (Google Cloud core) מ Google Cloud המסוף.

משתמשים

‫Looker (Google Cloud Core) תומך רק בשיטות האימות Google OAuth,‏ SAML ו-OpenID Connect.

אם מופעלת גם במופע Looker (המקורי) מערכת OAuth של Google, רשומות המשתמשים והמאפיינים שלהם יועתקו (בתנאי שהם משויכים לאותו מזהה Google וכתובת אימייל בשני המופעים). אדמין IAM של הפרויקט צריך להקצות לכל משתמש את תפקיד ה-IAM של אדמין Looker או של משתמש במופע Looker בפרויקט Google Cloud שבו נמצא המופע.

אם מופע Looker (מקורי) הוגדר ל-SAML או ל-OpenID Connect, צריך לוודא שבשדה מיזוג משתמשים באמצעות של שיטת האימות מצוינות רק שיטות אימות שנתמכות על ידי Looker (Google Cloud core).

אם חלק מהמשתמשים במופע Looker (מקורי) עברו אימות באמצעות מנגנון שלא נתמך ב-Looker (Google Cloud core) (כמו LDAP או אימייל/סיסמה), יהיה צורך ליצור מחדש את חשבונות המשתמשים האלה ולהמיר אותם לשיטת אימות נתמכת.

חיבורים למסד נתונים

‫Looker (Google Cloud Core)‎ תומך בקבוצה שונה במקצת של ניבים של מסדי נתונים בהשוואה ל-Looker (Original)‎. כל מאפייני ההגדרה של חיבורי מסד הנתונים (כולל מחרוזת החיבור והסיסמה, אם רלוונטי) מועתקים. עם זאת, יכול להיות שהטופולוגיה השונה של הרשת ב-Looker (Google Cloud core) תמנע את הפעולה המיידית של חיבורי מסד הנתונים. לדוגמה, אם יש גישה למסדי הנתונים דרך חומות אש או מנהרות שספציפיים למופע Looker (מקורי), יכול להיות שתצטרכו להגדיר מחדש את חומות האש או המנהרות. מומלץ לבדוק כל חיבור ולבסס אותו מחדש אם צריך.

חיבורים למסד נתונים באמצעות OAuth

במיגרציה מ-Looker (מקורי) ל-Looker (ליבת Google Cloud), לא נשמרים אסימוני גישה או אסימוני רענון של OAuth לחיבורי מסד נתונים של משתמשים פרטיים אל BigQuery או אל Snowflake. אחרי ההעברה, משתמשי Looker (Google Cloud core) יתבקשו לבצע אימות מחדש של OAuth כשהם יצפו בנתוני Explore או בלוח בקרה שמפנים לחיבור מסד נתונים של OAuth. המשתמשים יכולים גם לבצע אימות מחדש למסדי הנתונים שלהם. לשם כך הם צריכים לעבור לדף Account ולבחור באפשרות Log in לכל מסד נתונים בקטע OAuth Connection Credentials. כל ההתראות או התזמונים האוטומטיים שנמצאים בבעלות של משתמש יחיד ומתייחסים לחיבור OAuth יפסיקו לפעול עד שהמשתמש יתחבר באמצעות פרטי הכניסה שלו ל-OAuth.

חיבורים למאגרי Git

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

הגדרת רשת אחרת

יכול להיות שמופע Looker יכלול סוגים אחרים של חיבורי רשת, נכנסים ויוצאים (למשל, בהקשר של חיבורים פרטיים, Action Hub, Marketplace, אימייל וכו'). צריך גם לאמת את חיבורי הרשת האלה.

כתובת ה-URL לגישה למופע של Looker (Google Cloud Core)‎

למופע Looker ‏ (Google Cloud Core)‎ יש כתובת URL ראשית שמוקצית באופן אקראי. אם צריך לגשת למופע באמצעות כתובת URL ספציפית, אפשר להגדיר דומיין בהתאמה אישית.

לוחות זמנים והתראות

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

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

חלונות זמן לתחזוקה

בניגוד ל-Looker (מקורי), אפשר לציין מדיניות תחזוקה ל-Looker (Google Cloud Core).

פעילות במערכת Elite

נתוני הפעילות של Elite System לא מועתקים כחלק מההעברה. ההיסטוריה של מופע Looker (ליבת Google Cloud) תתחיל מחדש.

דומיין מותאם אישית

אתם יכולים ליצור דומיין מותאם אישית למופע של Looker (Google Cloud core). כדי להבטיח את הפריסה של אישור ה-SSL, צריך להגדיר את רשומות ה-DNS. בנוסף, אחרי שמפעילים את הדומיין המותאם אישית ומגדירים את שיטת האימות, צריך לעדכן את כתובת ה-URL של הקריאה החוזרת בלקוח האימות לדומיין המותאם אישית. אי אפשר ליצור דומיינים בהתאמה אישית ל-Looker (Google Cloud core) באמצעות דומיין looker.com.

אם רוצים ליצור דומיין מותאם אישית למופע של Looker (Google Cloud core) באמצעות כתובת URL מותאמת אישית של מופע Looker (מקורי), צריך להגדיר את הדומיין המותאם אישית אחרי השלמת ההעברה ואחרי שמוודאים שהמופע של Looker (Google Cloud core) מוכן לשימוש. אחרי שמפעילים את הדומיין המותאם אישית, המשתמשים יראו את המכונה של Looker (Google Cloud core) ולא את המכונה של Looker (המקורית) כשהם יבקרו בכתובת ה-URL של המכונה.

אל תגדירו SAML או OpenID Connect למופע Looker (Google Cloud core) עד שהמופע יהיה מוכן לשימוש, רשומות ה-DNS יעודכנו והדומיין המותאם אישית יופעל.

סימניות

אם אתם משתמשים בכתובת URL בהתאמה אישית במופע Looker (מקורי) (שלא משתמש בדומיין looker.com), תהליך ההעברה הזה ישמור על הסימניות של המשתמשים אם תיצרו דומיין בהתאמה אישית למופע Looker (Google Cloud core) באמצעות אותה כתובת URL כמו במופע Looker (מקורי).

אחרי שמפעילים את הדומיין המותאם אישית, סימניות לתוכן Looker (מקורי), כמו https://www.yourcustomdomain.com/dashboard/123, יפנו אל התוכן במופע Looker (Google Cloud Core). (הערה: מהדורות Enterprise ו-Embed של Looker (ליבת Google Cloud) משתמשות ב-slugs של תוכן אלפאנומריים בכתובות ה-URL שלהן במקום במזהי תוכן מספריים, אבל סימנייה עם מזהה תוכן עדיין תפנה מחדש לתוכן הנכון).

אי אפשר להשתמש בתהליך הזה עם כתובות URL של Looker (המקורי) שמשתמשות בדומיין looker.com.

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

אחרי שההעברה מסתיימת ומוודאים שלא יהיה צורך בייצוא נוסף, אפשר למחוק את <export-service-account> שיצרתם קודם, וכך מפתח ה-JSON ששותף עבורו לא יהיה יותר שימושי.

הוצאה משימוש של מופע Looker (original)‎

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

פתרון בעיות

הקטעים הבאים יכולים לעזור לכם לפתור בעיות במהלך ייבוא או ייצוא.

בעיות במהלך הייצוא

אם יש בעיה בייצוא הנתונים שלכם מ-Looker (המקורי), הסטטוס ERROR יופיע בדף Export בחלונית Admin. אם לוחצים על הסטטוס שגיאה, מוצגת הודעת שגיאה.

הנה כמה מהסיבות הנפוצות לשגיאות:

  • קטגוריה של Cloud Storage, מפתח ה-KMS או <export-service-account> לא תקינים.
  • ל-<export-service-account> חסרות ההרשאות הנדרשות.

מומלץ לאשר את הסטטוס של האובייקטים האלה לפני ששולחים את בקשת הייצוא.

בעיות במהלך הייבוא

אם פעולת הייבוא לא מסתיימת אחרי ארבע שעות (או יותר, אם מופע המקור היה גדול מאוד), או אם היא נכשלת עם שגיאה, יכול להיות שתצטרכו לפתוח כרטיס תמיכה ב-Cloud Customer Care כדי לפתור את הבעיה. יש מעט אבחונים שגלויים ישירות ללקוחות עבור הפעולה הזו.

מה השלב הבא?