Migrasi mandiri dari Looker (asli) ke Looker (Google Cloud core)

Dokumen ini menguraikan langkah-langkah teknis untuk memigrasikan instance Looker yang ada dari lingkungan Looker (asli) ke Looker (Google Cloud core).

Looker (Google Cloud core) adalah lingkungan deployment yang terintegrasi secara mendalam dengan platform Google Cloud . Looker (Google Cloud core) dihosting di infrastruktur Google Cloud ; Anda dapat mengelolanya langsung melalui konsol Google Cloud ; dan memiliki integrasi mendalam dengan banyak produk, layanan, dan kemampuan Google Cloudlainnya.

Looker (Google Cloud core) tidak mendukung migrasi dari instance Looker (asli) ke instance Looker (Google Cloud core) yang mengaktifkan FIPS, karena instance Looker (asli) tidak mendukung kepatuhan FIPS.

Sebelum memulai

  1. Pahami prinsip dan alat Google Cloud dengan meninjau dokumentasi berikut:
  2. Hubungi perwakilan akun Anda terkait migrasi dan apakah instance Looker (asli) Anda memenuhi syarat. Jika instance Anda memenuhi syarat, dan jika Anda telah mengupgrade kontrak Looker (original) yang ada untuk mencakup Looker (Google Cloud core), Anda dapat menyelesaikan langkah-langkah dalam dokumen ini untuk memigrasikan instance Anda.
  3. Untuk mendapatkan izin yang Anda perlukan guna mempersiapkan migrasi, minta administrator untuk memberi Anda peran IAM berikut pada project Google Cloud tempat instance Looker (Google Cloud core) akan berada:

    • Membuat instance Looker (Google Cloud core): Looker Admin (roles/looker.admin).
    • Menetapkan peran IAM dalam project Google Cloud Anda: Project IAM Admin (roles/resourcemanager.projectIamAdmin).
    • Membuat bucket Cloud Storage: Storage Admin (roles/storage.admin).

    Untuk mengetahui informasi selengkapnya tentang pemberian peran, lihat Mengelola akses ke project, folder, dan organisasi.

    Anda mungkin juga bisa mendapatkan izin yang diperlukan melalui peran khusus atau peran bawaan lainnya.

  4. Untuk mengelola instance Looker (asli) sebagai persiapan migrasi, Anda harus memiliki peran Looker Admin di instance tersebut.
  5. Buat instance Looker (Google Cloud core) "kosong" yang baru.

    Pastikan untuk memilih edisi, jenis koneksi jaringan (koneksi aman publik atau koneksi pribadi), dan atribut konfigurasi lainnya (CMEK, VPC-SC) yang tepat untuk instance Looker (Google Cloud core) baru Anda guna memastikan instance tersebut memiliki kemampuan yang diperlukan. Beberapa fitur di Looker (Google Cloud core) bergantung pada edisi yang dipilih atau jenis jaringan yang dipilih.

    Biarkan instance "kosong"; jangan isi dengan data apa pun seperti file model, pengguna, koneksi, Explore, dasbor, atau folder. Selama langkah impor, setelan atau konten apa pun akan dihapus dan diganti dengan data dari migrasi.

    Namun, atribut konfigurasi Looker (Google Cloud core) yang ditentukan melalui konsol Google Cloud , atau yang hanya dapat ditentukan selama pembuatan instance, tidak akan ditimpa selama proses migrasi.

Ringkasan

Secara umum, proses migrasi terdiri dari langkah-langkah berikut.

  1. Pastikan instance Looker (asli) Anda siap untuk migrasi.
  2. Ekspor data dari instance Looker (asli) Anda.
  3. Impor data ke instance Looker (Google Cloud core) "kosong" yang baru.
  4. Selesaikan penyiapan instance Looker (Google Cloud core).
  5. Hentikan penggunaan instance Looker (asli).

Bagian berikut memberikan detail tentang setiap langkah ini.

Memastikan instance Looker (asli) Anda siap untuk migrasi

Instance Looker (asli) Anda harus memenuhi prasyarat berikut agar memenuhi syarat untuk migrasi:

  • Instance Looker (original) Anda harus dikelola oleh Google (dengan kata lain, tidak dihosting oleh pelanggan) dan dihosting di Google Cloud atau Amazon Web Services.
  • Instance Looker (asli) Anda harus menggunakan versi dalam satu rilis bulanan dari versi Looker (Google Cloud core) saat ini. Untuk menemukan versi Looker (Google Cloud core) saat ini, lihat catatan rilis Looker dan temukan pengumuman deployment terbaru.

Selain itu, lakukan aktivitas berikut sebelum migrasi:

  • Ada sedikit perbedaan fitur antara Looker (asli) dan Looker (Google Cloud core). Tinjau perbedaan ini untuk memastikan bahwa fitur di Looker (Google Cloud core) memenuhi kebutuhan Anda yang terus berkembang.

  • Migrasi menyalin semua project Mode Produksi dan file model yang ada di dalamnya, tetapi tidak menyalin project Mode Pengembangan milik masing-masing pengguna. Untuk memastikan bahwa file Mode Pengembangan ditransfer melalui migrasi, Anda harus meng-commit semua file di semua project Mode Pengembangan ke repositori Git sebelum memulai migrasi.

  • Looker (Google Cloud core) hanya mendukung metode autentikasi Google OAuth, SAML, dan OpenID Connect.

    • Jika instance Looker (asli) Anda menggunakan metode autentikasi yang berbeda (misalnya, email dan sandi, LDAP, dll.), Anda harus mengonversi semua pengguna ke metode autentikasi yang didukung oleh Looker (Google Cloud core). Untuk mencegah pembuatan akun pengguna duplikat saat Anda mengonversi pengguna, lihat Memecahkan masalah akun Looker duplikat saat perubahan email.
    • Jika instance Looker (asli) Anda sudah menggunakan Google OAuth, semua data pengguna akan ditransfer, tetapi Anda tetap harus membuat izin IAM secara manual untuk pengguna dalam project instance Looker (Google Cloud core) Anda.
    • Jika instance Looker (asli) Anda menggunakan SAML, setelan Merge users using di halaman panel Admin SAML authentication harus ditetapkan ke Google atau OIDC untuk menghindari error saat Anda menguji autentikasi SAML.
    • Jika instance Looker (asli) Anda menggunakan OIDC, setelan Merge users using di halaman panel Admin OpenID Connect authentication harus ditetapkan ke Google atau SAML untuk menghindari error saat Anda menguji autentikasi OpenID Connect.
    • Jika menggunakan penyedia identitas eksternal, Anda harus memperbarui URL callback di penyedia identitas ke URL Looker (Google Cloud core) untuk mengizinkan autentikasi ke instance Looker (Google Cloud core) baru.
    • Jika instance Looker (Google Cloud core) Anda akan menggunakan SAML atau OpenID Connect sebagai metode autentikasi, sebaiknya siapkan juga Google OAuth, yang berfungsi sebagai metode autentikasi cadangan untuk Looker (Google Cloud core).
    • Jika Anda akan menggunakan domain kustom dengan instance Looker (Google Cloud core), jangan siapkan SAML atau OpenID Connect untuk instance tersebut hingga domain kustom diaktifkan.
  • Selama migrasi, dua instance Looker—satu Looker (asli), satu Looker (Google Cloud core)—akan berjalan secara paralel selama jangka waktu tertentu. Setiap aktivitas otomatis yang terjadi (seperti pemberitahuan dan pengiriman data terjadwal, serta aktivitas latar belakang yang mengakses database backend) dapat diduplikasi. Untuk menghindari aktivitas duplikat, hapus pemberitahuan dan jadwal otomatis di instance Looker (asli) atau Looker (Google Cloud core).

Mengekspor data dari instance Looker (asli) Anda

Mengekspor data dari instance Looker (asli) memerlukan dua langkah:

  1. Buat tempat untuk menyimpan data migrasi.
  2. Memulai ekspor.

Lihat dokumentasi Impor atau ekspor data satu kali untuk instance Looker (Google Cloud core) guna mempelajari data apa saja yang disertakan dan tidak disertakan dalam ekspor.

Membuat tempat untuk menyimpan data migrasi

Lakukan semua operasi berikut di project Google Cloud yang sama tempat Anda membuat instance Looker (Google Cloud core).

  1. Buat bucket Cloud Storage baru (misalnya, <bucket-name>).
    • Bucket ini akan digunakan untuk menyimpan data migrasi.
    • Ikuti petunjuk di halaman dokumentasi Membuat bucket.
    • Perhatikan bahwa <bucket-name> harus unik di semua Google Cloud. Sebaiknya beri awalan pada nama bucket dengan ID unik, seperti project ID Anda.
  2. Tentukan nama untuk folder di dalam bucket Cloud Storage (misalnya, <folder-name>). Jangan buat folder sekarang. Tentukan nama folder selama permintaan ekspor. Set data ini akan dibuat secara otomatis selama proses ekspor.
  3. Buat key ring dan kunci di Cloud KMS (misalnya, <kms_keyring_id> dan <kms-key-id>).
  4. Buat akun layanan baru khusus untuk migrasi (misalnya, <export-service-account>).
  5. Berikan dua peran IAM khusus kepada <export-service-account>:

  6. Buat kunci akun layanan yang terkait dengan <export-service-account>, dan download file kunci JSON.

Meminta ekspor

Setelah memastikan bahwa instance Anda siap untuk migrasi, membuat instance Looker (Google Cloud core) "kosong", dan membuat tempat untuk menyimpan data migrasi, masukkan informasi berikut ke halaman Export di panel Admin instance Looker (asli) Anda:

  • Nama bucket Cloud Storage yang Anda buat.
  • Nama folder Cloud Storage - folder dengan nama ini akan otomatis dibuat selama ekspor. Setelah ekspor selesai, file ekspor akan muncul di subfolder yang diberi stempel waktu dalam folder ini di bucket Cloud Storage yang Anda buat.
  • Nama kunci KMS.
  • Teks JSON yang berisi kunci akun layanan.

Setelah Anda memasukkan informasi di halaman Ekspor, klik Minta Ekspor untuk memulai ekspor.

Proses ekspor memerlukan waktu beberapa menit hingga beberapa jam. Setelah ekspor selesai, Anda akan melihat beberapa file ekspor (dalam format yang tidak dapat dibaca manusia) di bucket dan folder Cloud Storage Anda. File ini adalah input untuk langkah impor berikut.

Mengimpor data ke instance Looker (Google Cloud core) "kosong" yang baru

Setelah data instance diekspor, Anda dapat mengimpornya ke instance Looker (Google Cloud core).

Ikuti petunjuk di halaman Mengimpor data dari Cloud Storage ke instance Looker (Google Cloud core), dengan mengarahkan perintah ke bucket dan folder tempat file ekspor ditempatkan.

Operasi impor memerlukan waktu beberapa menit hingga beberapa jam. Setelah selesai, instance Looker (Google Cloud core) Anda akan dimulai ulang, dengan semua data yang dimigrasikan.

Menyelesaikan penyiapan instance Looker (Google Cloud core)

Pada tahap ini, admin Looker dapat membuka URL instance dan login ke instance untuk menyelesaikan penyiapan.

Proses migrasi menyalin sebanyak mungkin konfigurasi instance Looker (asli). Namun, beberapa item tidak dapat dimigrasikan, atau berfungsi agak berbeda di Looker (Google Cloud core), dan harus disesuaikan.

Beberapa item yang diketahui memerlukan perhatian khusus meliputi:

Setelan Umum (di panel Admin Looker)

Sebagian besar opsi untuk General Settings (dan setelan lainnya di seluruh panel Admin) tidak disalin secara otomatis, karena cenderung berbeda atau tidak ada dalam bentuk yang sama di Looker (Google Cloud core). Anda harus meninjau dan mengonfigurasi semua setelan dengan cermat dalam konteks konfigurasi Looker (Google Cloud core) yang Anda pilih. Lihat halaman dokumentasi Mengelola instance Looker (Google Cloud core) dari Looker dan Mengelola instance Looker (Google Cloud core) dari konsol Google Cloud untuk mengetahui informasi selengkapnya tentang setelan di Looker (Google Cloud core).

Pengguna

Looker (Google Cloud core) hanya mendukung metode autentikasi Google OAuth, SAML, dan OpenID Connect.

Jika instance Looker (asli) juga dikonfigurasi untuk Google OAuth, data pengguna dan atributnya akan disalin (selama dikaitkan dengan ID Google dan alamat email yang sama di kedua instance). Project IAM Admin harus memberikan peran IAM Looker Admin atau Looker Instance User kepada setiap pengguna di project Google Cloud tempat instance berada.

Jika instance Looker (asli) dikonfigurasi untuk SAML atau OpenID Connect, pastikan kolom Merge users using untuk metode autentikasi hanya menunjukkan metode autentikasi yang didukung oleh Looker (Google Cloud core).

Jika beberapa pengguna instance Looker (orisinal) melakukan autentikasi melalui mekanisme yang tidak didukung di Looker (Google Cloud core) (seperti LDAP atau email dan sandi), akun pengguna tersebut harus dibuat ulang dan dikonversi ke metode autentikasi yang didukung.

Untuk mencegah pembuatan akun pengguna duplikat saat Anda mengonversi pengguna, atau untuk memecahkan masalah akun duplikat yang dibuat selama migrasi, lihat Memecahkan masalah akun Looker duplikat saat perubahan email.

Koneksi database

Looker (Google Cloud core) mendukung kumpulan dialek database yang sedikit berbeda dengan Looker (asli). Semua properti konfigurasi untuk koneksi database (termasuk string koneksi dan sandi, jika ada) akan disalin. Namun, topologi jaringan yang berbeda di Looker (Google Cloud core) dapat mencegah koneksi database langsung berfungsi. Misalnya, jika database diakses melalui firewall atau tunnel yang khusus untuk instance Looker (asli), Anda mungkin perlu mengonfigurasi ulang firewall atau tunnel tersebut. Anda harus menguji setiap koneksi dan membuat ulang koneksi jika perlu.

Koneksi database menggunakan OAuth

Migrasi dari Looker (asli) ke Looker (Google Cloud core) tidak mempertahankan akses OAuth atau token refresh untuk koneksi database pengguna individu ke BigQuery atau Snowflake. Setelah migrasi, pengguna Looker (Google Cloud core) akan diminta untuk mengautentikasi ulang OAuth saat mereka melihat Explore atau dasbor yang merujuk ke koneksi database OAuth. Pengguna juga dapat mengautentikasi ulang ke database mereka dengan membuka halaman Akun dan memilih Login untuk setiap database di bagian judul Kredensial Koneksi OAuth. Setiap jadwal atau pemberitahuan otomatis yang dimiliki oleh satu pengguna dan merujuk ke koneksi OAuth akan rusak hingga pengguna tersebut login dengan kredensial OAuth-nya.

Koneksi repositori Git

Jika instance menggunakan repositori Git kosong, repositori tersebut akan berfungsi tanpa modifikasi (disalin, tetapi tidak dibagikan). Namun, jika instance terhubung ke repositori jarak jauh, koneksi ini mungkin perlu diverifikasi dan diaktifkan kembali, seperti koneksi database.

Konfigurasi jaringan lainnya

Instance Looker mungkin memiliki jenis koneksi jaringan lain, baik masuk maupun keluar (misalnya, dalam konteks koneksi pribadi, Hub Tindakan, Marketplace, email, dll.). Koneksi jaringan ini juga harus diverifikasi.

URL untuk mengakses instance Looker (Google Cloud core)

Instance Looker (Google Cloud core) dilengkapi dengan URL utama yang ditetapkan secara acak. Jika instance perlu diakses melalui URL tertentu, Anda dapat mengonfigurasi domain kustom.

Jadwal dan pemberitahuan

Jika instance Looker (asli) dan Looker (Google Cloud core) aktif secara bersamaan, instance tersebut dapat menghasilkan tindakan terjadwal dan pemberitahuan duplikat, serta melakukan operasi latar belakang duplikat yang mengakses database yang terhubung. Aktivitas ini harus dinonaktifkan di salah satu instance sesegera mungkin.

Setiap jadwal atau pemberitahuan otomatis yang dimiliki oleh satu pengguna dan merujuk ke koneksi OAuth individual pengguna tersebut akan rusak hingga pengguna tersebut login dengan kredensial OAuth-nya.

Masa pemeliharaan

Tidak seperti di Looker (asli), kebijakan pemeliharaan dapat ditentukan untuk Looker (Google Cloud core).

Aktivitas Sistem Elite

Data Elite System Activity tidak disalin sebagai bagian dari migrasi. Instance Looker (Google Cloud core) akan dimulai dengan histori baru.

Domain kustom

Anda dapat membuat domain kustom untuk instance Looker (Google Cloud core). Anda harus menetapkan data DNS untuk memastikan deployment sertifikat SSL. Selain itu, pastikan untuk memperbarui URL callback di klien autentikasi Anda ke domain kustom setelah domain kustom diaktifkan dan metode autentikasi disiapkan. Domain kustom tidak dapat dibuat untuk Looker (Google Cloud core) menggunakan domain looker.com.

Jika Anda ingin membuat domain kustom untuk instance Looker (Google Cloud core) menggunakan URL kustom instance Looker (asli), domain kustom harus disiapkan setelah migrasi selesai dan setelah Anda mengonfirmasi bahwa instance Looker (Google Cloud core) siap digunakan. Setelah domain kustom diaktifkan, pengguna Anda akan melihat instance Looker (Google Cloud core) dan bukan instance Looker (asli) saat mereka membuka URL instance.

Jangan siapkan SAML atau OpenID Connect untuk instance Looker (Google Cloud core) hingga instance siap digunakan, data DNS telah diperbarui, dan domain kustom telah diaktifkan.

Bookmark

Jika Anda menggunakan URL kustom di instance Looker (orisinal) (yang tidak menggunakan domain looker.com), proses migrasi ini akan mempertahankan bookmark pengguna jika Anda membuat domain kustom untuk instance Looker (Google Cloud core) menggunakan URL yang sama dengan instance Looker (orisinal).

Setelah domain kustom diaktifkan, bookmark ke konten Looker (asli) seperti https://www.yourcustomdomain.com/dashboard/123 akan mengarah ke konten dalam instance Looker (Google Cloud core). (Catatan: Looker (Google Cloud core) edisi Enterprise dan Embed menggunakan slug konten alfanumerik di URL-nya, bukan Content ID numerik, tetapi bookmark dengan Content ID akan tetap dialihkan dengan benar ke konten yang sama.)

Proses ini tidak dapat digunakan dengan URL Looker (asli) yang menggunakan domain looker.com.

Ini bukan merupakan daftar lengkap. Uji semua aspek instance yang paling penting bagi Anda, sebelum menganggap migrasi selesai.

Setelah migrasi selesai dan Anda yakin tidak memerlukan ekspor lain, Anda dapat menghapus <export-service-account> yang Anda buat sebelumnya, yang akan membuat kunci JSON yang dibagikan untuknya tidak berguna.

Menonaktifkan instance Looker (asli)

Setelah instance Looker (Google Cloud core) yang dimigrasikan berfungsi dengan baik, Anda dapat mengirimkan URL untuk instance kepada pengguna dan menginstruksikan mereka untuk mulai mengaksesnya dan berhenti mengakses instance Looker (asli).

Pemecahan masalah

Bagian berikut dapat membantu Anda menyelesaikan masalah selama impor atau ekspor.

Masalah selama ekspor

Jika ada masalah dengan ekspor data Looker (asli), status ERROR akan muncul di halaman Export di panel Admin. Mengklik status ERROR akan menampilkan pesan error.

Sumber error yang umum adalah sebagai berikut:

  • Bucket Cloud Storage, kunci KMS, atau <export-service-account> tidak valid.
  • <export-service-account> tidak memiliki izin yang diperlukan.

Sebaiknya konfirmasi status objek ini sebelum mengirimkan permintaan ekspor.

Masalah selama impor

Jika operasi impor tidak selesai setelah empat jam (atau mungkin lebih jika instance sumber sangat besar), atau jika keluar karena error, Anda mungkin perlu membuka tiket dengan Cloud Customer Care untuk menyelesaikan masalah tersebut. Ada relatif sedikit diagnostik yang dapat dilihat langsung oleh pelanggan untuk operasi ini.

Apa langkah selanjutnya?