Halaman ini membahas praktik umum untuk komponen tertentu dalam arsitektur Looker dan menjelaskan cara mengonfigurasinya dalam deployment.
Looker memiliki sejumlah dependensi untuk menghosting server, melayani beban kerja ad-hoc dan terjadwal, melacak pengembangan model iteratif, atau sejenisnya. Dependensi tersebut disebut sebagai komponen di halaman ini, dan setiap komponen dibahas secara mendetail di bagian berikut:
- Konfigurasi host
- Konfigurasi JVM
- Opsi startup Looker
- Database internal (backend)
- Layanan Git
- Jaringan
Konfigurasi host
OS dan distribusi
Looker berjalan dengan baik di versi Linux yang paling umum: RedHat, SUSE, dan Debian/Ubuntu. Derivatif dari distribusi ini yang dirancang dan dioptimalkan untuk berjalan di lingkungan tertentu umumnya tidak masalah. Misalnya, distribusi Linux Google Cloud atau AWS kompatibel dengan Looker. Debian/Ubuntu adalah varian Linux yang paling banyak digunakan di komunitas Looker, dan versi ini paling dikenal oleh Dukungan Looker. Cara termudah adalah menggunakan Debian/Ubuntu atau sistem operasi untuk penyedia cloud tertentu yang berasal dari Debian/Ubuntu.
Looker berjalan di Java Virtual Machine (JVM). Saat memilih distribusi, pertimbangkan apakah versi OpenJDK 11 sudah yang terbaru. Distribusi Linux yang lebih lama mungkin dapat menjalankan Looker, tetapi versi dan library Java yang diperlukan Looker untuk fitur tertentu harus diupdate. Jika JVM tidak berisi semua library dan versi Looker yang direkomendasikan, Looker tidak akan berfungsi dengan normal. Looker memerlukan Java HotSpot 1.8 update 161+ atau Java OpenJDK 11.0.12+.
CPU dan memori
Node 4x16 (4 CPU dan RAM 16 GB) sudah cukup untuk sistem pengembangan atau instance Looker pengujian dasar yang digunakan oleh tim kecil. Namun, untuk penggunaan produksi, hal ini biasanya tidak cukup. Berdasarkan pengalaman kami, 16x64 node (16 CPU dan RAM 64 GB) adalah keseimbangan yang baik antara harga dan performa. RAM lebih dari 64 GB dapat memengaruhi performa, karena peristiwa pembersihan sampah memori adalah thread tunggal dan menghentikan semua thread lain untuk dieksekusi.
Penyimpanan disk
Ruang disk sebesar 100 GB biasanya lebih dari cukup untuk sistem produksi.
Pertimbangan cluster
Looker berjalan di JVM Java, dan Java dapat mengalami kesulitan mengelola memori yang lebih besar dari 64 GB. Sebagai aturan umum, jika kapasitas yang diperlukan lebih besar, Anda harus menambahkan 16x64 node tambahan ke cluster, bukan meningkatkan ukuran node di luar 16x64. Kami juga dapat memilih untuk menggunakan arsitektur bercluster untuk meningkatkan ketersediaan.
Dalam cluster, node Looker perlu berbagi bagian tertentu dari sistem file. Data yang dibagikan mencakup hal berikut:
- Model LookML
- Model LookML developer
- Konektivitas server Git
Karena sistem file dibagikan dan menghosting sejumlah repositori Git, penanganan akses serentak dan penguncian file sangat penting. Sistem file harus kompatibel dengan POSIX. Network File System (NFS) diketahui berfungsi dan tersedia dengan mudah di Linux. Anda harus membuat instance Linux tambahan dan mengonfigurasi NFS untuk membagikan disk. NFS default berpotensi menjadi titik kegagalan tunggal, jadi pertimbangkan penyiapan failover atau penyiapan ketersediaan tinggi.
Metadata Looker juga harus dipusatkan, sehingga database internalnya harus dimigrasikan ke MySQL. Ini dapat berupa layanan MySQL atau deployment MySQL khusus. Bagian Database internal (backend) di halaman ini akan membahasnya secara lebih mendetail.
Konfigurasi JVM
Setelan JVM Looker ditentukan di dalam skrip startup Looker. Setelah ada update, Looker harus dimulai ulang agar perubahan dapat diterapkan. Konfigurasi defaultnya adalah sebagai berikut:
java \
-XX:+UseG1GC -XX:MaxGCPauseMillis=2000 \
-Xms$JAVAMEM -Xmx$JAVAMEM \
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \
-Xloggc:/tmp/gc.log ${JAVAARGS} \
-jar looker.jar start ${LOOKERARGS}
Resource
Setelan resource ditentukan dalam skrip startup Looker.
JAVAMEM="2300m" METAMEM="800m"
Alokasi memori untuk JVM harus mempertimbangkan overhead sistem operasi tempat Looker berjalan. Aturan umumnya adalah JVM dapat dialokasikan hingga 60% dari total memori, tetapi ada peringatan yang bergantung pada ukuran mesin. Untuk mesin dengan total memori minimum 8 GB, sebaiknya alokasikan 4-5 GB untuk Java dan 800 MB untuk Meta. Untuk mesin yang lebih besar, proporsi memori yang lebih rendah dapat dialokasikan untuk sistem operasi. Misalnya, untuk mesin dengan total memori 60 GB, sebaiknya alokasikan 36 GB untuk Java dan 1 GB untuk Meta. Penting untuk diperhatikan bahwa alokasi memori Java biasanya harus diskalakan dengan total memori mesin, tetapi Meta sudah cukup pada 1 GB.
Selain itu, karena Looker berbagi resource sistem dengan proses lain seperti Chromium untuk rendering, jumlah memori yang dialokasikan ke Java harus dipilih dalam konteks beban rendering yang diantisipasi dan ukuran mesin. Jika beban rendering diperkirakan rendah, Java dapat dialokasikan bagian yang lebih besar dari total memori. Misalnya, pada mesin dengan total memori 60 GB, Java dapat dialokasikan dengan aman hingga 46 GB, yang lebih tinggi dari rekomendasi umum 60%. Alokasi resource yang tepat untuk setiap deployment akan bervariasi, jadi gunakan 60% sebagai dasar dan sesuaikan sesuai penggunaan.
Pengumpulan sampah
Looker lebih memilih menggunakan pengumpul sampah paling modern yang tersedia untuk versi Java-nya. Secara default, waktu tunggu pengumpulan sampah adalah 2 detik, tetapi hal ini dapat diubah dengan mengedit opsi berikut dalam konfigurasi startup:
-XX:MaxGCPauseMillis=2000
Pada mesin yang lebih besar dengan beberapa core, waktu tunggu pembersihan sampah memori dapat dipersingkat.
Log
Secara default, log pengumpulan sampah Looker disimpan di /tmp/gc.log. Setelan ini dapat diubah dengan mengedit opsi berikut dalam konfigurasi startup:
-Xloggc:/tmp/gc.log
JMX
Pengelolaan Looker mungkin memerlukan pemantauan untuk membantu menyempurnakan penentuan sumber daya. Sebaiknya gunakan JMX untuk memantau penggunaan memori JVM.
Opsi startup Looker
Opsi startup disimpan dalam file bernama lookerstart.cfg. File ini berasal dari skrip shell yang memulai Looker.
Kumpulan thread
Sebagai aplikasi multi-thread, Looker memiliki sejumlah kumpulan thread. Thread pool ini berkisar dari server web inti hingga sublayanan khusus seperti penjadwalan, rendering, dan koneksi database eksternal. Bergantung pada alur kerja bisnis Anda, kumpulan ini mungkin perlu diubah dari konfigurasi default. Secara khusus, ada pertimbangan khusus untuk topologi cluster yang disebutkan di halaman Pola dan praktik arsitektur infrastruktur yang dihosting pelanggan.
Opsi throughput penjadwalan tinggi
Untuk semua node non-scheduler, tambahkan --scheduler-threads=0 ke variabel lingkungan LOOKERARGS di lookerstart.cfg. Tanpa thread penjadwal, tidak ada tugas terjadwal yang akan berjalan di node ini.
Untuk semua node penjadwal khusus, tambahkan --scheduler-threads=<n> ke variabel lingkungan LOOKERARGS di lookerstart.cfg. Looker dimulai dengan 10 thread penjadwal secara default, tetapi jumlah ini dapat ditingkatkan menjadi <n>. Dengan <n> thread penjadwal, setiap node akan dapat menjalankan <n> tugas jadwal serentak. Umumnya, sebaiknya <n> kurang dari 2x jumlah CPU. Host terbesar yang direkomendasikan adalah host dengan 16 CPU dan memori 64 GB, sehingga batas atas thread penjadwal harus kurang dari 32.
Opsi throughput rendering tinggi
Untuk semua node non-render, tambahkan --concurrent-render-jobs=0 ke variabel lingkungan LOOKERARGS di lookerstart.cfg. Tanpa node perender, tidak ada tugas render yang akan berjalan di node ini.
Untuk semua node rendering khusus, tambahkan --concurrent-render-jobs=<n> ke variabel lingkungan LOOKERARGS di lookerstart.cfg. Looker dimulai dengan dua thread rendering secara default, tetapi jumlah ini dapat ditingkatkan menjadi <n>. Dengan <n> thread rendering, setiap node akan dapat menjalankan <n> tugas rendering serentak.
Setiap tugas rendering dapat menggunakan sejumlah besar memori. Anggarkan sekitar 2 GB per tugas render. Misalnya, jika proses Looker inti (Java) dialokasikan 60% dari total memori dan 20% dari memori yang tersisa dicadangkan untuk sistem operasi, maka 20% terakhir akan digunakan untuk tugas render. Pada mesin 64 GB, masih ada 12 GB, yang cukup untuk 6 tugas rendering serentak. Jika node dikhususkan untuk rendering dan tidak disertakan dalam kumpulan load balancer yang menangani tugas interaktif, memori proses Looker inti dapat dikurangi untuk memungkinkan lebih banyak tugas rendering. Di komputer 64 GB, Anda dapat mengalokasikan sekitar 30% (20 GB) untuk proses inti Looker. Dengan mencadangkan 20% untuk penggunaan OS umum, maka tersisa 50% (32 GB) untuk rendering, yang cukup untuk 16 tugas rendering serentak.
Database internal (backend)
Server Looker menyimpan informasi tentang konfigurasi, koneksi database, pengguna, grup, dan peran, folder, Look dan dasbor yang ditentukan pengguna, serta berbagai data lainnya dalam database internal.
Untuk instance Looker mandiri berukuran sedang, data ini disimpan dalam database HyperSQL dalam memori yang disematkan dalam proses Looker itu sendiri. Data untuk database ini disimpan dalam file <looker install directory>/.db/looker.script. Meskipun praktis dan ringan, database ini mengalami masalah performa dengan penggunaan berat. Oleh karena itu, sebaiknya mulai dengan database MySQL jarak jauh. Jika hal ini tidak memungkinkan, sebaiknya lakukan migrasi ke database MySQL jarak jauh setelah file ~/looker/.db/looker.script mencapai 600 MB. Cluster harus menggunakan database MySQL.
Server Looker melakukan banyak operasi baca dan tulis kecil ke database MySQL. Setiap kali pengguna menjalankan Look atau Jelajah, Looker akan memeriksa database untuk memverifikasi bahwa pengguna masih login, pengguna memiliki hak istimewa untuk mengakses data, pengguna memiliki hak istimewa untuk menjalankan Look atau Jelajah, dan sebagainya. Looker juga akan menulis data ke database MySQL, seperti SQL sebenarnya yang dijalankan dan waktu permintaan dimulai dan berakhir. Satu interaksi antara pengguna dan aplikasi Looker dapat menghasilkan 15 atau 20 operasi baca dan tulis kecil ke database MySQL.
MySQL
Server MySQL harus berupa versi 8.0.x, dan harus dikonfigurasi untuk menggunakan encoding utf8mb4. Mesin penyimpanan InnoDB harus digunakan. Petunjuk penyiapan untuk MySQL, serta petunjuk tentang cara memigrasikan data dari database HyperSQL yang ada ke MySQL, tersedia di halaman dokumentasi Memigrasikan database backend Looker ke MySQL.
Saat mengonfigurasi Looker untuk menggunakan MySQL, file YAML yang berisi informasi koneksi harus dibuat. Beri nama file YAML looker-db.yml dan tambahkan setelan -d looker-db.yml di bagian LOOKERARGS pada file lookerstart.cfg.
MariaDB
MySQL memiliki lisensi ganda, tersedia sebagai open source dan sebagai produk komersial. Oracle terus meningkatkan kualitas MySQL, dan MySQL di-fork sebagai MariaDB. Versi MariaDB yang setara dengan MySQL diketahui berfungsi dengan Looker, tetapi tidak dikembangkan atau diuji oleh tim engineering Looker; oleh karena itu, fungsi tidak didukung atau dijamin.
Versi cloud
Jika Anda menghosting Looker di infrastruktur cloud, database MySQL sebaiknya dihosting di infrastruktur cloud yang sama. Tiga vendor cloud utama — Amazon AWS, Microsoft Azure, dan Google Cloud. Penyedia cloud mengelola sebagian besar pemeliharaan dan konfigurasi untuk database MySQL serta menawarkan layanan seperti bantuan dalam mengelola pencadangan dan menyediakan pemulihan cepat. Produk ini diketahui berfungsi dengan baik dengan Looker.
Kueri Aktivitas Sistem
Database MySQL digunakan untuk menyimpan informasi tentang cara pengguna menggunakan Looker. Setiap pengguna Looker yang memiliki izin untuk melihat model Aktivitas Sistem memiliki akses ke sejumlah dasbor Looker bawaan untuk menganalisis data ini. Pengguna juga dapat mengakses Jelajah metadata Looker untuk membuat analisis tambahan. Database MySQL terutama digunakan untuk kueri "operasional" kecil dan cepat. Kueri "analitik" yang besar dan lambat yang dihasilkan oleh model Aktivitas Sistem dapat bersaing dengan kueri operasional ini dan memperlambat Looker.
Dalam kasus ini, database MySQL dapat direplikasi ke database lain. Sistem yang dikelola sendiri dan sistem yang dikelola cloud tertentu menyediakan konfigurasi dasar replikasi ke database lain. Mengonfigurasi replikasi berada di luar cakupan dokumen ini.
Untuk menggunakan replika untuk kueri Aktivitas Sistem, Anda akan membuat salinan file looker-db.yml, misalnya bernama looker-usage-db.yml, mengubahnya agar mengarah ke replika, dan menambahkan setelan --internal-analytics-connection-file looker-usage-db.yml
ke bagian LOOKERARGS pada file lookerstart.cfg.
Kueri Aktivitas Sistem dapat dijalankan terhadap instance MySQL atau database Google BigQuery. Database ini tidak diuji terhadap database lain.
Konfigurasi performa MySQL
Selain setelan yang diperlukan untuk memigrasikan database backend Looker ke MySQL, cluster yang sangat aktif dapat memperoleh manfaat dari penyesuaian dan konfigurasi tambahan. Setelan ini dapat dilakukan pada file /etc/my.cnf, atau melalui konsol Google Cloud untuk instance yang dikelola cloud.
File konfigurasi my.cnf dibagi menjadi beberapa bagian. Perubahan setelan berikut yang dibahas di bagian ini dilakukan di bagian [mysqld].
Menetapkan ukuran kumpulan buffer InnoDB
Ukuran kumpulan buffer InnoDB adalah total RAM yang digunakan untuk menyimpan status file data InnoDB dalam memori. Jika server dikhususkan untuk menjalankan MySQL, innodb_buffer_pool_size harus disetel ke 50%-70% dari total memori sistem.
Jika total ukuran database kecil, Anda dapat menyetel gabungan buffer InnoDB ke ukuran database, bukan 50% atau lebih dari memori.
Untuk contoh ini, server memiliki memori 64 GB; oleh karena itu, kumpulan buffer InnoDB harus berukuran antara 32 GB dan 45 GB. Biasanya, semakin besar semakin baik.
[mysqld] ... innodb_buffer_pool_size=45G
Menetapkan instance kumpulan buffer InnoDB
Jika beberapa thread mencoba menelusuri kumpulan buffer besar, thread tersebut dapat bersaing. Untuk mencegah hal ini, buffer pool dibagi menjadi unit yang lebih kecil yang dapat diakses oleh thread yang berbeda tanpa konflik. Secara default, kumpulan buffer dibagi menjadi 8 instance. Hal ini berpotensi menyebabkan hambatan 8 thread. Meningkatkan jumlah instance buffer pool akan mengurangi kemungkinan terjadinya hambatan. innodb_buffer_pool_instances harus disetel sehingga setiap kumpulan buffer mendapatkan memori minimal 1 GB.
[mysqld] ... innodb_buffer_pool_instances=32
Mengoptimalkan file log InnoDB
Saat transaksi dilakukan, database memiliki opsi untuk memperbarui data dalam file sebenarnya, atau dapat menyimpan detail tentang transaksi dalam log. Jika database mengalami error sebelum file data diperbarui, file log dapat "diputar ulang" untuk menerapkan perubahan. Penulisan ke file log adalah operasi penambahan kecil. Lebih efisien untuk menambahkan ke log pada waktu penerapan, lalu mengelompokkan beberapa perubahan pada file data dan menuliskannya dalam satu operasi IO. Saat file log terisi, database harus menjeda pemrosesan transaksi baru dan menulis semua data yang diubah kembali ke disk.
Sebagai aturan umum, file log InnoDB harus cukup besar untuk memuat transaksi selama 1 jam.
Biasanya ada dua file log InnoDB. Ukuran ini harus sekitar 25% dari buffer pool InnoDB Anda. Untuk contoh database dengan buffer pool 32 GB, total ukuran file log InnoDB harus 8 GB, atau 4 GB per file.
[mysqld] ... innodb_log_file_size=8GB
Mengonfigurasi kapasitas IO InnoDB
MySQL akan membatasi kecepatan penulisan yang dicatat ke disk agar tidak membebani server. Nilai default bersifat konservatif untuk sebagian besar server. Untuk mendapatkan performa terbaik, gunakan utilitas sysbench untuk mengukur kecepatan penulisan acak ke disk data, lalu gunakan nilai tersebut untuk mengonfigurasi kapasitas IO sehingga MySQL akan menulis data lebih cepat.
Pada sistem yang di-hosting di cloud, vendor cloud harus dapat melaporkan performa disk yang digunakan untuk penyimpanan data. Untuk server MySQL yang dihosting sendiri, ukur kecepatan penulisan acak ke disk data dalam operasi I/O per detik (IOPS). Utilitas Linux sysbench adalah salah satu cara untuk mengukurnya. Gunakan nilai tersebut untuk innodb_io_capacity_max, dan nilai setengah hingga tiga perempat dari nilai tersebut untuk innodb_io_capacity. Jadi, dalam contoh berikut, kita akan melihat nilai jika mengukur 800 IOPS.
[mysqld] ... innodb_io_capacity=500 innodb_io_capacity_max=800
Mengonfigurasi thread InnoDB
MySQL akan membuka setidaknya satu thread untuk setiap klien yang dilayani. Jika banyak klien terhubung secara bersamaan, hal itu dapat menyebabkan sejumlah besar thread diproses. Hal ini dapat menyebabkan sistem menghabiskan lebih banyak waktu untuk menukar daripada memproses.
Penetapan tolok ukur harus dilakukan untuk menentukan jumlah thread yang ideal. Untuk menguji, tetapkan jumlah thread antara jumlah CPU (atau inti CPU) di sistem dan 4x jumlah CPU. Untuk sistem 16-core, nilai ini kemungkinan antara 16 dan 64.
[mysqld] ... innodb_thread_concurrency=32
Ketahanan transaksi
Nilai transaksi 1 memaksa MySQL menulis ke disk untuk setiap transaksi. Jika server mengalami error, transaksi tidak akan hilang, tetapi performa database akan terpengaruh. Menyetel nilai ini ke 0 atau 2 dapat meningkatkan performa, tetapi akan berisiko kehilangan transaksi data selama beberapa detik.
[mysqld] ... innodb_flush_log_at_trx_commit=1
Menetapkan metode flush
Sistem operasi biasanya melakukan buffering penulisan ke disk. Karena MySQL dan OS sama-sama melakukan buffering, ada penalti performa. Mengurangi metode flush satu lapisan buffering dapat meningkatkan performa.
[mysqld] ... innodb_flush_method=O_DIRECT
Mengaktifkan satu file per tabel
Secara default, MySQL akan menggunakan satu file data untuk semua data. Setelan innodb_file_per_table akan membuat file terpisah untuk setiap tabel, yang meningkatkan performa dan pengelolaan data.
[mysqld] ... innodb_file_per_table=ON
Menonaktifkan statistik pada metadata
Setelan ini menonaktifkan pengumpulan statistik pada tabel metadata internal, sehingga meningkatkan performa baca.
[mysqld] ... innodb_stats_on_metadata=OFF
Menonaktifkan cache kueri
Cache kueri tidak digunakan lagi, jadi menyetel query_cache_size dan query_cache_type ke 0 akan menonaktifkannya.
[mysqld] ... query_cache_size=0 query_cache_type=0
Memperbesar buffer gabungan
join_buffer digunakan untuk melakukan penggabungan dalam memori. Meningkatkannya dapat meningkatkan operasi tertentu.
[mysqld] ... join_buffer_size=512KB
Memperbesar ukuran tabel sementara dan heap maksimum
tmp_table_size dan max_heap_table_size menetapkan default yang wajar untuk tabel dalam memori sementara, sebelum dipaksa ke disk.
[mysqld ... tmp_table_size=32MB max_heap_table_size=32MB
Menyesuaikan cache terbuka tabel
Setelan table_open_cache menentukan ukuran cache yang menyimpan deskriptor file untuk tabel terbuka. Setelan table_open_cache_instances memecah cache menjadi sejumlah bagian yang lebih kecil. Ada potensi pertentangan thread di table_open_cache, jadi membaginya menjadi bagian-bagian yang lebih kecil akan membantu meningkatkan serentak.
[mysqld] ... table_open_cache=2048 table_open_cache_instances=16
Layanan Git
Looker dirancang untuk bekerja dengan layanan Git guna menyediakan pengelolaan versi file LookML. Layanan hosting Git utama didukung, termasuk GitHub, GitLab, dan Bitbucket. Penyedia layanan Git menawarkan nilai tambah tambahan seperti GUI untuk melihat perubahan kode dan dukungan untuk alur kerja seperti permintaan pull dan persetujuan perubahan. Jika diperlukan, Git dapat dijalankan di server Linux biasa.
Jika layanan hosting Git tidak sesuai untuk deployment Anda karena aturan keamanan, banyak penyedia layanan ini menawarkan versi yang dapat dijalankan di lingkungan Anda sendiri. Khususnya GitLab, umumnya dihosting sendiri dan dapat digunakan sebagai produk open source tanpa biaya lisensi atau sebagai produk berlisensi yang didukung. GitHub Enterprise tersedia sebagai layanan yang dihosting sendiri dan merupakan produk komersial yang didukung.
Bagian berikut mencantumkan nuansa untuk penyedia layanan yang paling umum.
GitHub/GitHub Enterprise
Halaman dokumentasi Menyiapkan dan menguji koneksi Git menggunakan GitHub sebagai contoh.
GitLab/gitlab.com
Lihat postingan Komunitas Looker Menggunakan GitLab untuk kontrol versi di Looker untuk mengetahui langkah-langkah penyiapan GitLab yang mendetail. Jika repositori Anda berada dalam subgrup, subgrup ini dapat ditambahkan ke URL repositori menggunakan format HTTPS atau SSH:
https://gitlab.com/accountname/subgroup/reponame git@gitlab.com:accountname/subgroup/reponame.git
Selain itu, ada tiga cara berbeda untuk menyimpan kunci SSH yang dibuat Looker di GitLab: sebagai kunci SSH pengguna, sebagai kunci deployment repositori, atau sebagai kunci deployment bersama global. Penjelasan yang lebih mendalam dapat ditemukan dalam dokumentasi GitLab.
Google Cloud Sumber
Lihat Postingan Komunitas Menggunakan Cloud Source Repositories untuk kontrol versi di Looker untuk mengetahui langkah-langkah penyiapan Git dengan Cloud Source Repositories.
Bitbucket Cloud
Lihat Postingan Komunitas Menggunakan Bitbucket untuk kontrol versi di Looker untuk mengetahui langkah-langkah penyiapan Git dengan Bitbucket Cloud. Mulai Agustus 2021, Bitbucket Cloud tidak mendukung rahasia di webhook web untuk men-deploy.
Bitbucket Server
Untuk menggunakan pull request dengan Bitbucket Server, Anda mungkin perlu menyelesaikan langkah-langkah berikut:
- Saat Anda membuka pull request, Looker akan otomatis menggunakan nomor port default (7999) di URL. Jika menggunakan nomor port kustom, Anda harus mengganti nomor port di URL secara manual.
- Anda harus memanggil webhook deployment project untuk menyinkronkan cabang produksi di Looker dengan cabang utama repositori.
Difusi Phabricator
Lihat Postingan Komunitas Menyiapkan Phabricator dan Looker untuk kontrol versi untuk mengetahui langkah-langkah menyiapkan Git dengan Phabricator.
Jaringan
Koneksi masuk
Aplikasi web Looker
Secara default, Looker memproses permintaan HTTPS di port 9999. Looker menggunakan sertifikat yang ditandatangani sendiri dengan CN self-signed.looker.com. Server Looker juga dapat dikonfigurasi untuk melakukan hal berikut:
- Menerima koneksi HTTP dari proxy/load balancer penghentian SSL, dengan flag startup
--ssl-provided-externally-by=<s>. Nilai harus ditetapkan ke alamat IP proxy, atau ke nama host yang dapat diselesaikan secara lokal ke alamat IP proxy. Looker hanya akan menerima koneksi HTTP dari alamat IP ini. - Gunakan sertifikat SSL yang disediakan pelanggan, dengan tanda peluncuran
--ssl-keystore=<s>.
Looker API
Looker API memproses di port 19999. Jika penginstalan memerlukan akses ke API, load balancer harus memiliki aturan penerusan yang diperlukan. Pertimbangan SSL yang sama berlaku seperti pada aplikasi web utama. Sebaiknya gunakan port yang berbeda dari aplikasi web.
Load balancer
Load balancer sering digunakan untuk menerima permintaan HTTPS di port 443 menggunakan sertifikat pelanggan, lalu meneruskan permintaan ke node server Looker di port 9999 menggunakan sertifikat yang ditandatangani sendiri atau HTTP. Jika load balancer menggunakan sertifikat yang ditandatangani sendiri Looker, load balancer tersebut harus dikonfigurasi untuk menerima sertifikat tersebut.
Koneksi yang tidak ada aktivitas dan waktu tunggu
Saat pengguna memulai permintaan besar di Looker, hal itu dapat menghasilkan kueri yang mahal untuk dijalankan di database. Jika pengguna membatalkan permintaan tersebut dengan cara apa pun — seperti menutup tutup laptop, memutuskan koneksi dari jaringan, atau menutup tab tersebut di browser — Looker ingin mengetahui dan menghentikan kueri database tersebut.
Untuk menangani situasi ini, saat aplikasi web klien membuat permintaan untuk menjalankan kueri database, browser akan membuka koneksi socket menggunakan permintaan HTTP yang berjalan lama ke server Looker. Koneksi ini akan tetap terbuka dan tidak aktif. Socket ini akan terputus jika aplikasi web klien dihentikan atau terputus dengan cara apa pun. Server akan melihat pemutusan koneksi tersebut dan membatalkan kueri database terkait.
Load balancer sering kali mendeteksi koneksi terbuka yang tidak aktif ini dan menghentikannya. Agar Looker dapat berjalan secara efektif, load balancer harus dikonfigurasi untuk memungkinkan koneksi ini tetap terbuka selama kueri terpanjang yang mungkin dijalankan pengguna. Sebaiknya tetapkan waktu tunggu minimal 60 menit.
Koneksi keluar
Server Looker dapat memiliki akses keluar yang tidak dibatasi ke semua resource, termasuk internet publik. Hal ini menyederhanakan banyak tugas, seperti menginstal Chromium, yang memerlukan akses ke repositori paket untuk distribusi Linux.
Berikut adalah koneksi keluar yang mungkin perlu dilakukan Looker.
Koneksi database internal
Secara default, MySQL memproses koneksi pada port 3306. Node Looker harus dapat memulai koneksi ke MySQL di port ini. Bergantung pada cara repositori dihosting, Anda mungkin perlu melewati firewall.
Layanan eksternal
Server telemetri dan lisensi Looker tersedia menggunakan HTTPS di internet publik. Traffic dari node Looker ke ping.looker.com:443 dan license.looker.com:443 mungkin perlu ditambahkan ke daftar yang diizinkan.
Koneksi data warehouse
Database yang dihosting di cloud mungkin memerlukan koneksi menggunakan internet publik. Misalnya, jika Anda menggunakan BigQuery, accounts.google.com:443 dan www.googleapis.com:443 mungkin perlu ditambahkan ke daftar yang diizinkan. Jika database berada di luar infrastruktur Anda sendiri, hubungi host database Anda untuk mengetahui detail jaringan.
Layanan SMTP
Secara default, Looker mengirim email keluar menggunakan SendGrid. Hal ini mungkin memerlukan penambahan smtp.sendgrid.net:587 ke daftar yang diizinkan. Setelan SMTP dapat diubah dalam konfigurasi untuk menggunakan handler email yang berbeda juga.
Hub tindakan, server tindakan, dan webhook
Banyak tujuan penjadwal, khususnya webhook dan yang diaktifkan di panel Admin Looker, melibatkan pengiriman data menggunakan permintaan HTTPS.
- Untuk webhook, tujuan ini ditentukan saat runtime oleh pengguna, dan mungkin bertentangan dengan tujuan membatasi koneksi keluar dengan firewall.
- Untuk hub tindakan, permintaan ini dikirim ke
actions.looker.com. Detailnya dapat ditemukan dalam dokumentasi konfigurasi Hub Tindakan Looker kami. - Untuk server tindakan lainnya, permintaan ini dikirim ke domain yang ditentukan dalam konfigurasi server tindakan oleh administrator di panel Admin Looker.
Proxy server
Jika internet publik tidak dapat diakses secara langsung, Looker dapat dikonfigurasi untuk menggunakan server proxy untuk permintaan HTTP(S) dengan menambahkan baris seperti berikut ke lookerstart.cfg:
JAVAARGS="-Dhttp.proxyHost=myproxy.example.com -Dhttp.proxyPort=8080 -Dhttp.nonProxyHosts=127.0.0.1|localhost -Dhttps.proxyHost=myproxy.example.com -Dhttps.proxyPort=8080"
Perhatikan bahwa komunikasi antar-node terjadi melalui HTTPS, jadi jika Anda menggunakan server proxy dan instance Anda dikelompokkan, biasanya Anda perlu menambahkan IP/nama host untuk semua node dalam cluster ke argumen Dhttp.nonProxyHosts.
Komunikasi antar-node
ID host internal
Dalam cluster, setiap node harus dapat berkomunikasi dengan node lainnya. Untuk mengizinkannya, nama host atau alamat IP setiap node ditentukan dalam konfigurasi startup. Saat node dimulai, nilai ini akan ditulis ke repositori MySQL. Anggota cluster lainnya kemudian dapat merujuk ke nilai tersebut untuk berkomunikasi dengan node ini. Untuk menentukan nama host atau alamat IP dalam konfigurasi startup, tambahkan -H node1.looker.example.com ke variabel lingkungan LOOKERARGS di lookerstart.cfg.
Karena nama host harus unik per node, file lookerstart.cfg harus unik di setiap instance. Sebagai alternatif untuk mengodekan nama host atau alamat IP secara permanen, perintah hostname -I atau hostname --fqdn dapat digunakan untuk menemukannya saat runtime. Untuk mengimplementasikannya, tambahkan -H $(hostname -I) atau -H $(hostname --fqdn) ke variabel lingkungan LOOKERARGS di lookerstart.cfg.
Port internal
Selain port 9999 dan 19999, yang masing-masing digunakan untuk server web dan API, node cluster akan berkomunikasi satu sama lain melalui layanan message broker, yang menggunakan port 1551 dan 61616. Port 9999 dan 19999 harus terbuka untuk traffic pengguna akhir, tetapi 1551 dan 61616 harus terbuka di antara node cluster.