Halaman ini membahas praktik umum untuk komponen tertentu dari 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. Turunan distribusi ini yang dirancang dan dioptimalkan untuk berjalan di lingkungan tertentu biasanya tidak masalah. Misalnya, distribusi Linux Google Cloud atau AWS kompatibel dengan Looker. Debian/Ubuntu adalah variasi Linux yang paling banyak digunakan di komunitas Looker, dan ini adalah versi yang 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 yang terbaru. Jika JVM tidak berisi semua library dan versi Looker yang direkomendasikan, Looker tidak akan berfungsi secara normal. Looker memerlukan Java HotSpot 1.8 update 161+ atau Java OpenJDK 11.0.12+.
CPU dan memori
Node 4x16 (4 CPU dan 16 GB RAM) sudah cukup untuk sistem pengembangan atau instance Looker pengujian dasar yang digunakan oleh tim kecil. Namun, untuk penggunaan produksi, hal ini biasanya tidak memadai. Berdasarkan pengalaman kami, node 16x64 (16 CPU dan 64 GB RAM) adalah keseimbangan yang baik antara harga dan performa. RAM lebih dari 64 GB dapat memengaruhi performa, karena peristiwa pembersihan sampah memiliki 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 dalam mengelola memori yang lebih besar dari 64 GB. Sebagai aturan umum, jika kapasitas tambahan diperlukan, Anda harus menambahkan node 16x64 tambahan ke cluster, bukan meningkatkan ukuran node di luar 16x64. Kita juga dapat memilih untuk menggunakan arsitektur cluster 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 sesuai dengan POSIX. Network File System (NFS) diketahui berfungsi dan tersedia dengan Linux. Anda harus membuat instance Linux tambahan dan mengonfigurasi NFS untuk membagikan disk. NFS default berpotensi menjadi titik tunggal kegagalan, jadi pertimbangkan penyiapan failover atau penyiapan ketersediaan tinggi.
Metadata Looker juga perlu dipusatkan, sehingga database internalnya harus dimigrasikan ke MySQL. Ini dapat berupa layanan MySQL atau deployment MySQL khusus. Bagian Database internal (backend) di halaman ini menjelaskan lebih mendetail.
Konfigurasi JVM
Setelan JVM Looker ditentukan di dalam skrip startup Looker. Setelah update, Looker harus dimulai ulang agar perubahan dapat ditampilkan. 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 umum adalah JVM dapat dialokasikan hingga 60% dari total memori, tetapi ada pengecualian 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 diskalakan dengan total memori mesin, tetapi Meta seharusnya cukup dengan 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 diperkirakan dan ukuran mesin. Jika beban rendering diperkirakan rendah, Java dapat dialokasikan lebih banyak dari total memori. Misalnya, pada mesin dengan total memori 60 GB, Java dapat dialokasikan dengan aman ke 46 GB, yang lebih tinggi dari rekomendasi umum 60%. Alokasi resource yang tepat untuk setiap deployment bervariasi, jadi gunakan 60% sebagai dasar pengukuran dan sesuaikan sesuai penggunaan.
Pembersihan sampah memori
Looker lebih memilih menggunakan garbage collector paling modern yang tersedia untuk versi Java-nya. Secara default, waktu tunggu pembersihan sampah adalah 2 detik, tetapi ini dapat diubah dengan mengedit opsi berikut di konfigurasi startup:
-XX:MaxGCPauseMillis=2000
Pada mesin yang lebih besar dengan beberapa core, waktu tunggu pembersihan sampah memori dapat dipersingkat.
Log
Secara default, log pembersihan sampah Looker disimpan di /tmp/gc.log. Hal ini dapat diubah dengan mengedit opsi berikut di konfigurasi startup:
-Xloggc:/tmp/gc.log
JMX
Mengelola Looker mungkin memerlukan pemantauan untuk membantu meningkatkan kualitas sumber daya. Sebaiknya gunakan JMX untuk memantau penggunaan memori JVM.
Opsi startup Looker
Opsi startup disimpan dalam file bernama lookerstart.cfg. File ini bersumber dari skrip shell yang memulai Looker.
Kumpulan thread
Sebagai aplikasi multi-thread, Looker memiliki sejumlah kumpulan thread. ThreadPool 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-penjadwal, 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 ini dapat ditingkatkan menjadi <n>. Dengan <n> thread penjadwal, setiap node akan dapat menjalankan <n> tugas jadwal serentak. Secara umum, sebaiknya pertahankan <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 render khusus, tambahkan --concurrent-render-jobs=<n> ke variabel lingkungan LOOKERARGS di lookerstart.cfg. Looker dimulai dengan dua thread render secara default, tetapi ini dapat ditingkatkan menjadi <n>. Dengan <n> thread render, setiap node akan dapat menjalankan <n> tugas render serentak.
Setiap tugas render dapat menggunakan memori dalam jumlah yang signifikan. Anggarankan sekitar 2 GB per tugas render. Misalnya, jika proses Looker inti (Java) dialokasikan 60% dari total memori dan 20% memori yang tersisa dicadangkan untuk sistem operasi, maka 20% terakhir akan digunakan untuk tugas render. Pada mesin 64 GB, sisa memorinya adalah 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 render. Pada mesin 64 GB, Anda dapat mengalokasikan sekitar 30% (20 GB) untuk proses inti Looker. Dengan mencadangkan 20% untuk penggunaan OS umum, maka akan tersisa 50% (32 GB) untuk rendering, yang cukup untuk 16 tugas render serentak.
Database internal (backend)
Server Looker menyimpan informasi tentang konfigurasinya sendiri, 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 yang berat. Oleh karena itu, sebaiknya mulai dengan database MySQL jarak jauh. Jika 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 Tampilan 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 Tampilan 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 versi 8.0.x, dan harus dikonfigurasi untuk menggunakan encoding utf8mb4. Mesin penyimpanan InnoDB harus digunakan. Petunjuk penyiapan untuk MySQL, serta petunjuk 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 harus dibuat yang berisi informasi koneksi. Beri nama file YAML looker-db.yml dan tambahkan setelan -d looker-db.yml di bagian LOOKERARGS file lookerstart.cfg.
MariaDB
MySQL memiliki lisensi ganda, tersedia sebagai open source dan sebagai produk komersial. Oracle terus meningkatkan MySQL, dan MySQL diambil alih sebagai MariaDB. Versi MySQL yang setara dengan MariaDB diketahui berfungsi dengan Looker, tetapi tidak dikembangkan untuk atau diuji oleh tim engineer Looker; oleh karena itu, fungsinya tidak didukung atau dijamin.
Versi cloud
Jika Anda menghosting Looker di infrastruktur cloud, sebaiknya hosting database MySQL 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 membantu 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" yang kecil dan cepat. Kueri "analitis" yang besar, lambat, dan dihasilkan oleh model Aktivitas Sistem dapat bersaing dengan kueri operasional ini dan memperlambat Looker.
Dalam hal ini, database MySQL dapat direplikasi ke database lain. Sistem yang dikelola sendiri dan sistem tertentu yang dikelola cloud menyediakan konfigurasi dasar replikasi ke database lain. Konfigurasi 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 file lookerstart.cfg.
Kueri Aktivitas Sistem dapat dijalankan pada instance MySQL atau database Google BigQuery. Database tersebut 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 dibuat ke 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 ditetapkan ke 50%-70% dari total memori sistem.
Jika total ukuran database kecil, Anda dapat menetapkan kumpulan 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 antara 32 GB dan 45 GB. Semakin besar biasanya semakin baik.
[mysqld] ... innodb_buffer_pool_size=45G
Menetapkan instance kumpulan buffer InnoDB
Jika beberapa thread mencoba menelusuri kumpulan buffer yang besar, thread tersebut dapat bersaing. Untuk mencegah hal ini, kumpulan buffer 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 bottleneck 8 thread. Meningkatkan jumlah instance kumpulan buffering akan mengurangi kemungkinan bottleneck. innodb_buffer_pool_instances harus ditetapkan agar setiap kumpulan buffer mendapatkan memori minimal 1 GB.
[mysqld] ... innodb_buffer_pool_instances=32
Mengoptimalkan file log InnoDB
Saat transaksi di-commit, 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. Menulis ke file log adalah operasi tambahan kecil. Menambahkan ke log pada waktu commit, lalu menggabungkan beberapa perubahan ke file data dan menulisnya dalam satu operasi IO akan lebih efisien. 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 menampung transaksi selama 1 jam.
Biasanya ada dua file log InnoDB. Jumlahnya harus sekitar 25% dari kumpulan buffer InnoDB Anda. Untuk contoh database dengan buffer pool 32 GB, file log InnoDB harus berjumlah total 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 performa terbaik, gunakan utilitas sysbench untuk mengukur kecepatan tulis acak ke disk data, lalu gunakan nilai tersebut untuk mengonfigurasi kapasitas IO sehingga MySQL akan menulis data lebih cepat.
Pada sistem yang dihosting cloud, vendor cloud harus dapat melaporkan performa disk yang digunakan untuk penyimpanan data. Untuk server MySQL yang dihosting sendiri, ukur kecepatan operasi tulis acak ke disk data dalam operasi IO 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 minimal satu thread untuk setiap klien yang ditayangkan. Jika banyak klien terhubung secara bersamaan, hal itu dapat menyebabkan pemrosesan thread dalam jumlah besar. Hal ini dapat menyebabkan sistem menghabiskan lebih banyak waktu untuk melakukan swap daripada pemrosesan.
Benchmarking harus dilakukan untuk menentukan jumlah thread yang ideal. Untuk menguji, tetapkan jumlah thread antara jumlah CPU (atau core 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. Menetapkan 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 operasi tulis ke disk. Karena MySQL dan OS 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, sehingga menyetel query_cache_size dan query_cache_type ke 0 akan menonaktifkannya.
[mysqld] ... query_cache_size=0 query_cache_type=0
Memperbesar buffer join
join_buffer digunakan untuk melakukan join dalam memori. Meningkatkannya dapat meningkatkan operasi tertentu.
[mysqld] ... join_buffer_size=512KB
Memperbesar tabel sementara dan ukuran heap maksimum
tmp_table_size dan max_heap_table_size menetapkan setelan default yang wajar untuk tabel sementara dalam memori, 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 membagi cache menjadi sejumlah bagian yang lebih kecil. Ada potensi pertentangan thread di table_open_cache, sehingga membaginya menjadi bagian yang lebih kecil akan membantu meningkatkan konkurensi.
[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. GitLab, khususnya, biasanya 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 mendetail untuk GitLab. Jika repositori Anda berada dalam subgrup, subgrup tersebut 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 di dokumentasi GitLab.
Google Cloud Source
Lihat Postingan Komunitas Menggunakan Cloud Source Repositories untuk kontrol versi di Looker untuk mengetahui langkah-langkah menyiapkan Git dengan Cloud Source Repositories.
Bitbucket Cloud
Lihat Postingan Komunitas Menggunakan Bitbucket untuk kontrol versi di Looker untuk mengetahui langkah-langkah menyiapkan Git dengan Bitbucket Cloud. Mulai Agustus 2021, Bitbucket Cloud tidak mendukung secret di webhook deployment.
Bitbucket Server
Untuk menggunakan permintaan pull dengan Bitbucket Server, Anda mungkin perlu menyelesaikan langkah-langkah berikut:
- Saat Anda membuka permintaan pull, 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 membuka 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 guna 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 load balancer/proxy penghentian SSL, dengan flag startup
--ssl-provided-externally-by=<s>. Nilai harus ditetapkan ke alamat IP proxy, atau ke nama host yang dapat di-resolve secara lokal ke alamat IP proxy. Looker hanya akan menerima koneksi HTTP dari alamat IP ini. - Gunakan sertifikat SSL yang disediakan pelanggan, dengan flag startup
--ssl-keystore=<s>.
Looker API
Looker API memproses 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 balancers
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 menggunakan sertifikat yang ditandatangani sendiri oleh Looker, load balancer 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 mungkin mahal untuk dijalankan di database. Jika pengguna membatalkan permintaan tersebut dengan cara apa pun — seperti dengan menutup 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 soket menggunakan permintaan HTTP yang berumur panjang ke server Looker. Koneksi ini akan terbuka dan tidak ada aktivitas. Soket 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 melihat koneksi tidak ada aktivitas yang terbuka ini dan menghentikannya. Agar dapat menjalankan Looker secara efektif, load balancer harus dikonfigurasi agar koneksi ini tetap terbuka selama kueri terpanjang yang mungkin dijalankan pengguna. Sebaiknya gunakan 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 di 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 lisensi dan telemetri 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. Tindakan ini mungkin memerlukan penambahan smtp.sendgrid.net:587 ke daftar yang diizinkan. Setelan SMTP juga dapat diubah dalam konfigurasi untuk menggunakan pengendali email yang berbeda.
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 firewall koneksi keluar.
- Untuk hub tindakan, permintaan ini dikirim ke
actions.looker.com. Detailnya dapat ditemukan di dokumentasi konfigurasi Looker Action Hub. - 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 dijangkau 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 antarnode terjadi melalui HTTPS, jadi jika Anda menggunakan server proxy dan instance Anda dikelompokkan, Anda biasanya ingin menambahkan IP/nama host untuk semua node dalam cluster ke argumen Dhttp.nonProxyHosts.
Komunikasi antarnode
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 melakukan hardcoding nama host atau alamat IP, perintah hostname -I atau hostname --fqdn dapat digunakan untuk menemukannya saat runtime. Untuk menerapkannya, 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 saling berkomunikasi melalui layanan broker pesan, 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.