從 Looker (原始版本) 自助遷移至 Looker (Google Cloud Core)

本文概述將現有 Looker 執行個體從 Looker (原始版本) 環境遷移至 Looker (Google Cloud Core) 的技術步驟。

Looker (Google Cloud Core) 是與 Google Cloud 平台深度整合的部署環境。Looker (Google Cloud Core) 託管於 Google Cloud 基礎架構，可直接透過 Google Cloud 控制台管理，並與 Google Cloud的其他多項產品、服務和功能深度整合。

Looker (Google Cloud Core) 不支援從 Looker (原始) 執行個體遷移至啟用 FIPS 的 Looker (Google Cloud Core) 執行個體，因為 Looker (原始) 執行個體不支援 FIPS 法規遵循。

事前準備

  1. 請參閱下列說明文件，熟悉 Google Cloud 原則和工具：
  2. 請洽詢帳戶代表，瞭解遷移作業和 Looker (原始版本) 執行個體是否符合資格。如果執行個體符合資格，且您已升級現有的 Looker (原始版本) 合約，將 Looker (Google Cloud Core) 納入涵蓋範圍，即可按照本文中的步驟遷移執行個體。

  3. 如要取得準備遷移作業所需的權限，請要求管理員在 Looker (Google Cloud Core) 執行個體所在的 Google Cloud 專案中，授予您下列 IAM 角色：

    • 建立 Looker (Google Cloud Core) 執行個體：Looker 管理員 (roles/looker.admin)。
    • 在 Google Cloud 專案中指派 IAM 角色：專案 IAM 管理員 (roles/resourcemanager.projectIamAdmin)。
    • 建立 Cloud Storage bucket：Storage 管理員 (roles/storage.admin)。

    如要進一步瞭解如何授予角色，請參閱「管理專案、資料夾和組織的存取權」。

    您或許也能透過自訂角色或其他預先定義的角色，取得必要權限。

  4. 如要管理 Looker (原始) 執行個體，為遷移作業做好準備，您必須在該執行個體中具備 Admin Looker 角色。

  5. 建立新的「空白」Looker (Google Cloud Core) 執行個體。

    請務必為新的 Looker (Google Cloud Core) 執行個體選取適當的版本、網路連線類型 (公開安全連線或私人連線) 和其他設定屬性 (CMEK、VPC-SC)，確保執行個體具備必要功能。Looker (Google Cloud Core) 的部分功能取決於所選版本或所選網路類型。

    請將執行個體留空，不要填入任何資料，例如模型檔案、使用者、連線、探索、資訊主頁或資料夾。在匯入步驟中，系統會抹除所有設定或內容，並替換為遷移作業中的資料。

    不過，透過 Google Cloud 控制台指定的 Looker (Google Cloud Core) 設定屬性，或只能在建立執行個體時指定的屬性，不會在遷移過程中遭到覆寫。

總覽

遷移程序大致包含下列步驟。

  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 Core) 之間有少數功能差異。請詳閱這些差異，確保 Looker (Google Cloud Core) 的功能符合您的持續需求。

  • 遷移作業會複製所有正式環境模式專案和內含的模型檔案，但不會複製個別使用者擁有的開發模式專案。為確保開發模式檔案在遷移過程中順利轉移，您必須先將所有開發模式專案中的檔案提交至 Git 存放區，再啟動遷移作業。

  • Looker (Google Cloud Core) 僅支援 Google OAuth、SAML 和 OpenID Connect 驗證方式。

    • 如果 Looker (原始) 執行個體使用其他驗證方式 (例如電子郵件和密碼、LDAP 等)，您必須將所有使用者轉換為 Looker (Google Cloud Core) 支援的驗證方式。如要避免在轉換使用者時建立重複的使用者帳戶，請參閱「排解電子郵件變更時重複的 Looker 帳戶問題」。
    • 如果 Looker (原始) 執行個體已使用 Google OAuth，系統會轉移所有使用者記錄，但您仍須在 Looker (Google Cloud Core) 執行個體的專案中，為使用者手動建立 IAM 權限。
    • 如果 Looker (原始服務) 執行個體使用 SAML，請務必將「SAML 驗證」管理面板頁面上的「使用下列項目合併使用者」設定設為「Google」或「OIDC」，以免測試 SAML 驗證時發生錯誤。
    • 如果 Looker (原始) 執行個體使用 OIDC，請務必將「OpenID Connect 驗證」管理面板頁面的「使用以下項目合併使用者」設定設為「Google」或「SAML」，以免測試 OpenID Connect 驗證時發生錯誤。
    • 如果您使用外部身分識別資訊提供者，請務必將識別資訊提供者中的回呼網址更新為 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 (Google Cloud Core) 這兩個 Looker 執行個體會並行運作一段時間。任何自動執行的活動 (例如快訊和排定的資料傳送，以及存取後端資料庫的背景活動) 都可能重複。為避免重複活動，請刪除 Looker (原始版本) 或 Looker (Google Cloud Core) 執行個體中的自動快訊和排程。

從 Looker (原始) 執行個體匯出資料

從 Looker (原始) 執行個體匯出資料需要兩個步驟：

  1. 建立儲存遷移資料的位置。
  2. 開始匯出。

如要瞭解匯出作業包含和不包含哪些資料，請參閱「一次性匯入或匯出 Looker (Google Cloud Core) 執行個體資料」說明文件。

建立儲存遷移資料的位置

在您建立 Looker (Google Cloud Core) 執行個體的 Google Cloud 專案中，執行下列所有操作。

  1. 建立新的 Cloud Storage bucket (例如 <bucket-name>)。
    • 這個 bucket 將用於儲存遷移資料。
    • 請按照「建立 bucket」說明文件頁面的指示操作。
    • 請注意，<bucket-name> 在所有 Google Cloud中必須是唯一的。建議您在 bucket 名稱前方加上專屬 ID，例如專案 ID。
  2. 決定 Cloud Storage bucket 內資料夾的名稱 (例如 <folder-name>)，但先不要建立資料夾。在匯出要求期間指定資料夾名稱。系統會在匯出程序中自動建立。
  3. 在 Cloud KMS 中建立金鑰環和金鑰 (例如 <kms_keyring_id> 和 <kms-key-id>)。
  4. 建立專門用於遷移作業的新服務帳戶 (例如 <export-service-account>)。

  5. 授予 <export-service-account> 兩項特定 IAM 角色：

  6. 建立與 <export-service-account> 相關聯的服務帳戶金鑰，並下載 JSON 金鑰檔案。

要求匯出

確認執行個體已準備好遷移、建立「空白」Looker (Google Cloud Core) 執行個體，並建立遷移資料的儲存位置後，請在 Looker (原始版) 執行個體的「管理面板」中，前往「匯出」頁面輸入下列資訊：

  • 您建立的 Cloud Storage bucket 名稱。
  • Cloud Storage 資料夾名稱：匯出期間，系統會自動建立這個名稱的資料夾。匯出完成後，匯出檔案會顯示在您建立的 Cloud Storage bucket 中，位於這個資料夾內有時間戳記的子資料夾。
  • KMS 金鑰名稱。
  • 包含服務帳戶金鑰的 JSON 文字。

在「匯出」頁面輸入資訊後，按一下「要求匯出」即可開始匯出。

匯出程序需要幾分鐘到幾小時。匯出完成後，Cloud Storage bucket 和資料夾中會顯示多個匯出檔案 (非人類可讀格式)。這些檔案是下列匯入步驟的輸入內容。

將資料匯入新的「空白」Looker (Google Cloud Core) 執行個體

匯出執行個體資料後，即可匯入 Looker (Google Cloud Core) 執行個體。

請按照「將資料從 Cloud Storage 匯入 Looker (Google Cloud Core) 執行個體」頁面的操作說明，將指令指向匯出檔案所在的 bucket 和資料夾。

匯入作業需要幾分鐘到幾小時才能完成。完成後，Looker (Google Cloud Core) 執行個體會重新啟動，並包含所有已遷移的資料。

完成 Looker (Google Cloud Core) 執行個體的設定

此時，Looker 管理員可以前往執行個體網址並登入執行個體，完成設定。

遷移程序會盡可能複製 Looker (原始) 執行個體設定。不過，部分項目無法遷移，或是在 Looker (Google Cloud Core) 中的運作方式略有不同，必須調整。

以下列出一些需要特別注意的事項：

一般設定 (位於 Looker「管理」面板)

「一般設定」中的大部分選項 (以及「管理」面板中的其他設定) 不會自動複製，因為這些設定在 Looker (Google Cloud Core) 中通常不同，或不存在相同形式。請務必仔細檢查並設定所有設定，確保符合您選擇的 Looker (Google Cloud Core) 設定。如要進一步瞭解 Looker (Google Cloud Core) 的設定，請參閱「透過 Looker 管理 Looker (Google Cloud Core) 執行個體」和「透過 Google Cloud 控制台管理 Looker (Google Cloud Core) 執行個體」說明文件頁面。

使用者

Looker (Google Cloud Core) 僅支援 Google OAuth、SAML 和 OpenID Connect 驗證方式。

如果 Looker (原始) 執行個體也設定了 Google OAuth，系統會複製使用者記錄和屬性 (前提是這些記錄和屬性在兩個執行個體中，都與相同的 Google ID 和電子郵件地址相關聯)。專案 IAM 管理員必須在執行個體所在的 Google Cloud 專案中，為每位使用者授予 Looker 管理員或 Looker 執行個體使用者 IAM 角色。

如果 Looker (原始) 執行個體已設定 SAML 或 OpenID Connect，請確認驗證方式的「Merge users using」(合併使用者) 欄位僅指出 Looker (Google Cloud Core) 支援的驗證方式。

如果 Looker (原始) 執行個體的部分使用者是透過 Looker (Google Cloud Core) 不支援的機制 (例如 LDAP 或電子郵件和密碼) 驗證，則必須重新建立這些使用者帳戶，並轉換為支援的驗證方式。

如要避免在轉換使用者時建立重複的使用者帳戶，或排解遷移期間建立重複帳戶的問題，請參閱「排解電子郵件變更時重複 Looker 帳戶的問題」。

資料庫連線

Looker (Google Cloud Core) 支援的資料庫方言與 Looker (原始版) 略有不同。資料庫連線的所有設定屬性 (包括連線字串和密碼，如適用) 都會複製。不過，Looker (Google Cloud Core) 的網路拓撲不同，可能導致資料庫連線無法立即運作。舉例來說，如果資料庫是透過 Looker (原始) 執行個體專用的防火牆或通道存取，您可能需要重新設定防火牆或通道。請測試每個連線，並視需要重新建立。

使用 OAuth 的資料庫連線

從 Looker (原始版本) 遷移至 Looker (Google Cloud Core) 時，不會保留個別使用者資料庫連線至 BigQuery 或 Snowflake 的 OAuth 存取權或更新權杖。遷移完成後，如果 Looker (Google Cloud Core) 使用者查看的探索或資訊主頁，參照了 OAuth 資料庫連線，系統會提示他們重新驗證 OAuth。使用者也可以前往「帳戶」頁面，在「OAuth 連線憑證」標題下方，為每個資料庫選取「登入」，重新驗證資料庫。如果自動排程或快訊是由單一使用者擁有，且參照 OAuth 連線，則在該使用者以 OAuth 憑證登入前，這些排程或快訊都會中斷。

Git 存放區連線

如果執行個體使用裸 Git 存放區，應該不需修改就能運作 (複製，但不共用)。不過，如果執行個體連線至遠端存放區，這些連線可能需要驗證並重新啟用，就像資料庫連線一樣。

其他網路設定

Looker 執行個體可能會有其他類型的網路連線，包括傳入和傳出連線 (例如私人連線、Action Hub、Marketplace、電子郵件等)。這些網路連線也必須經過驗證。

用於存取 Looker (Google Cloud Core) 執行個體的網址

Looker (Google Cloud Core) 執行個體會隨附隨機指派的主要網址。如需透過特定網址存取執行個體，可以設定自訂網域。

時間表和快訊

如果 Looker (原始) 和 Looker (Google Cloud Core) 執行個體同時運作，可能會產生重複的排定動作和快訊，並執行重複的背景作業，存取連結的資料庫。請盡快在其中一個執行個體停用這些活動。

如果自動排程或快訊由單一使用者擁有，且參照該使用者的個別 OAuth 連線，則在該使用者以 OAuth 憑證登入前，這些排程或快訊都會中斷。

維護期間

與 Looker (原始版) 不同，您可以為 Looker (Google Cloud Core) 指定維護政策。

Elite 系統活動

遷移作業不會複製 Elite 系統活動資料。Looker (Google Cloud Core) 執行個體會從新的記錄開始。

自訂網域

您可以為 Looker (Google Cloud Core) 執行個體建立自訂網域。你必須設定 DNS 記錄，確保 SSL 憑證部署作業順利完成。此外，啟用自訂網域並設定驗證方式後，請務必將驗證用戶端中的回呼網址更新為自訂網域。無法使用 looker.com 網域為 Looker (Google Cloud Core) 建立自訂網域。

如要使用 Looker (原始版本) 執行個體的自訂網址，為 Looker (Google Cloud Core) 執行個體建立自訂網域，請在遷移完成後，且確認 Looker (Google Cloud Core) 執行個體已可使用時，再設定自訂網域。啟用自訂網域後，使用者前往執行個體網址時，會看到 Looker (Google Cloud Core) 執行個體，而非 Looker (原始版本) 執行個體。

請等到 Looker (Google Cloud Core) 執行個體可供使用、DNS 記錄已更新，且自訂網域已啟用後，再設定 SAML 或 OpenID Connect。

書籤

如果您在 Looker (原始版) 執行個體中使用自訂網址 (不使用 looker.com 網域)，則在 Looker (Google Cloud Core) 執行個體中建立自訂網域時，只要使用與 Looker (原始版) 執行個體相同的網址，這項遷移程序就會保留使用者的書籤。

啟用自訂網域後，Looker (原始版本) 內容的書籤 (例如 https://www.yourcustomdomain.com/dashboard/123) 會指向 Looker (Google Cloud Core) 執行個體中的內容。(注意：Looker (Google Cloud Core) 的 企業版 和 Embed 版本在網址中使用英數字元內容標記，而非數字 Content ID，但含有內容 ID 的書籤仍會正確重新導向至相同內容。)

這項程序不適用於使用 looker.com 網域的 Looker (原始版) 網址。

本清單並非詳盡無遺。在確認遷移完成前，請測試執行個體中所有對您最重要的部分。

遷移完成後，如果您確定不需要再次匯出，可以刪除先前建立的 <export-service-account>，這樣一來，共用的 JSON 金鑰就會失效。

停用 Looker (原始版) 執行個體

遷移後的 Looker (Google Cloud Core) 執行個體運作正常後，您可以將執行個體的網址傳送給使用者，並指示他們開始存取該執行個體，並停止存取 Looker (原始版本) 執行個體。

疑難排解

以下各節可協助您解決匯入或匯出期間的問題。

匯出時發生的問題

如果匯出 Looker (原始服務) 資料時發生問題，管理面板的「匯出」頁面會顯示「錯誤」狀態。點選「ERROR」狀態，即可查看錯誤訊息。

常見的錯誤來源如下：

  • Cloud Storage bucket、KMS 金鑰或 <export-service-account> 無效。
  • <export-service-account> 缺少必要權限。

建議您先確認這些物件的狀態，再提交匯出要求。

匯入期間的問題

如果匯入作業在四小時後仍未完成 (如果來源執行個體非常大，可能需要更長時間)，或因錯誤而結束，您可能需要向 Cloud Customer Care 提交票證來解決問題。這項作業中，客戶可直接查看的診斷資訊相對較少。

後續步驟