Saya sarankan Anda membaca transkrip laporan Alexander Sigachev Service Discovery dalam sistem terdistribusi menggunakan Konsul sebagai contoh.
Service Discovery dibuat agar dengan biaya minimal Anda dapat menghubungkan aplikasi baru ke lingkungan kami yang sudah ada. Dengan menggunakan Service Discovery, kita dapat secara maksimal memisahkan kontainer buruh pelabuhan atau layanan virtual dari lingkungan tempat ia berjalan.
Saya menyambut semuanya! Saya Alexander Sigachev, saya bekerja di Inventos. Dan hari ini saya akan memperkenalkan Anda pada konsep seperti Service Discovery. Mari kita lihat Service Discovery menggunakan Konsul sebagai contoh.
Masalah apa yang dipecahkan oleh Service Discovery? Service Discovery dibuat agar dengan biaya minimal Anda dapat menghubungkan aplikasi baru ke lingkungan kami yang sudah ada. Dengan menggunakan Service Discovery, kita dapat secara maksimal memisahkan kontainer buruh pelabuhan atau layanan virtual dari lingkungan tempat ia berjalan.
Seperti apa bentuknya? Dalam contoh klasik di web, ini adalah front end yang menerima permintaan pengguna. Kemudian mengarahkannya ke backend. Dalam contoh ini, penyeimbang beban ini menyeimbangkan dua backend.
Di sini kita melihat bahwa kita meluncurkan aplikasi ketiga. Oleh karena itu, ketika aplikasi dimulai, aplikasi tersebut mendaftar ke Service Discovery. Service Discovery memberi tahu penyeimbang beban. Penyeimbang beban mengubah konfigurasinya secara otomatis dan backend baru dioperasikan. Dengan cara ini, backend dapat ditambahkan, atau sebaliknya, dikecualikan dari pekerjaan.
Apa lagi yang nyaman untuk dilakukan dengan Service Discovery? Service Discovery dapat menyimpan konfigurasi nginx, sertifikat, dan daftar server backend yang aktif.
Service Discovery juga memungkinkan Anda mendeteksi kegagalan dan mendeteksi kegagalan. Apa skema yang mungkin untuk mendeteksi kegagalan?
- Aplikasi yang kami kembangkan ini secara otomatis memberi tahu Service Discovery bahwa masih berfungsi.
- Service Discovery, pada bagiannya, melakukan survei terhadap ketersediaan aplikasi.
- Atau kami menggunakan skrip atau aplikasi pihak ketiga yang memeriksa ketersediaan aplikasi kami dan memberi tahu Service Discovery bahwa semuanya baik-baik saja dan dapat berfungsi, atau, sebaliknya, semuanya buruk dan contoh aplikasi ini perlu dikecualikan dari penyeimbangan.
Masing-masing skema dapat digunakan tergantung pada software apa yang kita gunakan. Misalnya kita baru saja mulai mengembangkan proyek baru, maka kita dapat dengan mudah memberikan skema ketika aplikasi kita memberi tahu Service Discovery. Atau kita dapat menghubungkan bahwa Service Discovery sedang memeriksa.
Jika kita mewarisi aplikasi atau dikembangkan oleh orang lain, maka opsi ketiga cocok ketika kita menulis sebuah handler, dan semua ini masuk ke dalam pekerjaan kita secara otomatis.
Ini adalah salah satu contohnya. Penyeimbang beban dalam bentuk nginx di-boot ulang. Ini adalah utilitas opsional yang disediakan dengan Konsul. Ini adalah templat konsul. Kami menjelaskan aturannya. Kami mengatakan bahwa kami menggunakan template (Golang Template Engine). Ketika peristiwa terjadi, ketika pemberitahuan bahwa perubahan telah terjadi, peristiwa itu dibuat ulang dan perintah “muat ulang” dikirim ke Service Discovery. Contoh paling sederhana adalah ketika nginx dikonfigurasi ulang oleh suatu peristiwa dan dimulai ulang.
Apa itu Konsul?
-
Pertama-tama, ini adalah Penemuan Layanan.
-
Ini memiliki mekanisme pemeriksaan ketersediaan - Pemeriksaan Kesehatan.
-
Ini juga memiliki Toko KV.
-
Dan itu didasarkan pada kemampuan menggunakan Multi Datacenter.
Untuk apa semua ini digunakan? Di KV Store kita dapat menyimpan contoh konfigurasi. Pemeriksaan Kesehatan kita dapat memeriksa layanan lokal dan memberi tahu. Multi Datacenter digunakan agar peta layanan dapat dibangun. Misalnya, Amazon memiliki beberapa zona dan merutekan lalu lintas dengan cara yang paling optimal sehingga tidak ada permintaan yang tidak perlu antar pusat data, yang dikenakan biaya secara terpisah dari lalu lintas lokal dan, karenanya, memiliki latensi yang lebih sedikit.
Mari kita pahami sedikit tentang istilah-istilah yang digunakan di Konsul.
- Konsul adalah layanan yang ditulis dalam Go. Salah satu kelebihan program Go adalah 1 file biner yang baru saja Anda unduh. Diluncurkan dari mana saja dan Anda tidak memiliki ketergantungan apa pun.
- Kemudian, dengan menggunakan kunci tersebut, kita dapat memulai layanan ini baik dalam mode klien atau mode server.
- Selain itu, atribut "pusat data" memungkinkan Anda menyetel tanda pusat data milik server ini.
- Konsensus – berdasarkan protokol rakit. Jika ada yang berminat, Anda bisa membaca lebih lanjut di website Konsul. Ini adalah protokol yang memungkinkan Anda menentukan pemimpin dan menentukan uang mana yang dianggap valid dan dapat diakses.
- Gosip adalah protokol yang memungkinkan interaksi antar node. Apalagi sistem ini bersifat desentralisasi. Dalam satu pusat data, semua node berkomunikasi dengan tetangganya. Dan, karenanya, informasi tentang keadaan saat ini dikirimkan satu sama lain. Bisa dibilang ini adalah gosip antar tetangga.
- LAN Gossip – pertukaran data lokal antar tetangga dalam pusat data yang sama.
- WAN Gossip - digunakan ketika kita perlu menyinkronkan informasi antara dua pusat data. Informasi mengalir antar node yang ditandai sebagai server.
- RPC – memungkinkan Anda menjalankan permintaan melalui klien di server.
Deskripsi RPC. Katakanlah Konsul berjalan sebagai klien di mesin virtual atau server fisik. Kami menghubunginya secara lokal. Dan kemudian klien lokal meminta informasi dari server dan disinkronkan. Tergantung pada pengaturannya, informasi dapat diambil dari cache lokal, atau dapat disinkronkan dengan pemimpin, dengan master server.
Kedua skema ini menimbulkan pro dan kontra. Jika kami bekerja dengan cache lokal, maka itu cepat. Jika kita bekerja dengan data yang disimpan di server, dibutuhkan waktu lebih lama, namun kita mendapatkan informasi yang lebih relevan.
Jika Anda menggambarkannya secara grafis, maka inilah gambar situsnya. Kami melihat bahwa kami memiliki tiga master yang sedang berjalan. Yang satu ditandai dengan tanda bintang sebagai pemimpin. Dalam contoh ini, ada tiga klien yang bertukar informasi secara lokal satu sama lain melalui UDP/TCP. Dan informasi antar pusat data ditransfer antar server. Di sini klien berinteraksi satu sama lain secara lokal.
API apa yang disediakan Konsul? Untuk mendapatkan informasi, Konsul memiliki dua jenis API.
Ini adalah API DNS. Secara default, Konsul berjalan pada port 8600. Kita dapat mengonfigurasi proksi permintaan dan menyediakan akses melalui resolusi lokal, melalui DNS lokal. Kami dapat melakukan kueri berdasarkan domain dan menerima informasi alamat IP sebagai tanggapan.
HTTP API - atau kita dapat meminta informasi secara lokal tentang layanan tertentu pada port 8500 dan menerima respons JSON, IP apa yang dimiliki server, host apa, port apa yang terdaftar. Dan informasi tambahan dapat dikirimkan melalui token.
Apa yang Anda perlukan untuk menjalankan Konsul?
Pada opsi pertama, dalam mode pengembang kami menunjukkan tanda bahwa ini adalah mode pengembang. Agen dimulai sebagai server. Dan ia menjalankan seluruh fungsinya secara independen pada satu mesin. Nyaman, cepat, dan praktis tidak diperlukan pengaturan tambahan untuk permulaan pertama.
Mode kedua adalah peluncuran dalam produksi. Di sinilah permulaan menjadi sedikit rumit. Jika kita tidak memiliki versi konsul apa pun, maka kita harus memasukkan mesin pertama ke dalam bootstrap, yaitu mesin ini, yang akan mengambil tanggung jawab sebagai pemimpin. Kita menaikkannya, lalu kita menaikkan server kedua, meneruskan informasi di mana master kita berada. Kami menaikkan yang ketiga. Setelah kami mengaktifkan tiga mesin, kami memulai ulang dalam mode normal pada mesin pertama dari bootstrap yang sedang berjalan. Data disinkronkan dan cluster awal sudah aktif.
Disarankan untuk menjalankan tiga hingga tujuh instance dalam mode server. Hal ini disebabkan karena jika jumlah server bertambah, maka waktu untuk menyinkronkan informasi antar server juga bertambah. Jumlah node harus ganjil untuk memastikan kuorum.
Bagaimana Pemeriksaan Kesehatan diberikan? Kami menulis aturan verifikasi dalam bentuk Json di direktori konfigurasi Konsul. Opsi pertama adalah ketersediaan domain google.com dalam contoh ini. Dan kami katakan bahwa pemeriksaan ini perlu dilakukan dengan interval 30 detik. Dengan cara ini kami memeriksa apakah node kami memiliki akses ke jaringan eksternal.
Pilihan kedua adalah memeriksa diri sendiri. Kami menggunakan curl biasa untuk memanggil localhost pada port yang ditentukan dengan interval 10 detik.
Pemeriksaan ini diringkas dan dikirim ke Service Discovery. Berdasarkan ketersediaan, node ini dikecualikan atau muncul dalam daftar mesin yang tersedia dan berfungsi dengan benar.
Konsul juga menyediakan antarmuka UI, yang diluncurkan dengan flag terpisah dan akan tersedia di mesin. Ini memungkinkan Anda melihat informasi dan Anda juga dapat membuat beberapa perubahan.
Dalam contoh ini, tab “Layanan” terbuka. Terlihat ada tiga layanan yang berjalan, salah satunya adalah Konsul. Jumlah pemeriksaan yang dilakukan. Dan ada tiga pusat data tempat mesin tersebut berada.
Ini adalah contoh tab Node. Kami melihat bahwa mereka memiliki nama gabungan yang melibatkan pusat data. Ini juga menunjukkan layanan mana yang sedang berjalan, yaitu kita melihat bahwa tidak ada tag yang disetel. Tag tambahan ini dapat memberikan beberapa informasi yang dapat digunakan pengembang untuk menentukan parameter tambahan.
Anda juga dapat mengirimkan informasi ke Konsul tentang status disk dan beban rata-rata.
pertanyaan
Pertanyaan: Kami memiliki wadah buruh pelabuhan, bagaimana cara menggunakannya dengan Konsul?
Jawaban: Ada beberapa pendekatan untuk docker container. Salah satu cara yang paling umum adalah menggunakan wadah buruh pelabuhan pihak ketiga yang bertanggung jawab untuk pendaftaran. Saat startup, soket buruh pelabuhan diteruskan ke sana. Semua peristiwa pendaftaran kontainer dan de-publikasi dicatat di Konsul.
Pertanyaan: Jadi Konsul sendiri yang memulai wadah buruh pelabuhan?
Jawaban: Tidak. Kami menjalankan wadah buruh pelabuhan. Dan saat mengonfigurasi, kami menunjukkan - dengarkan soket ini dan itu. Ini kira-kira sama dengan cara kita bekerja dengan sertifikat, ketika kita mengunggah informasi tentang di mana dan apa yang kita miliki.
Pertanyaan: Ternyata di dalam container Docker yang kita coba sambungkan ke Service Discovery harusnya ada semacam logika yang bisa mengirim data ke Konsul?
Jawaban: Tidak juga. Saat dimulai, kami meneruskan variabel melalui variabel lingkungan. Katakanlah nama layanan, port layanan. Register mendengarkan informasi ini dan memasukkannya ke Konsul.
Pertanyaan: Saya punya pertanyaan lain tentang UI. Kami menerapkan UI, misalnya, di server produksi. Bagaimana dengan keamanan? Di mana datanya disimpan? Apakah mungkin untuk mengumpulkan data?
Jawaban: Di UI ada data dari database dan dari Service Discovery. Kami mengatur sendiri kata sandi di pengaturan.
Pertanyaan: Bisakah ini dipublikasikan di Internet?
Jawaban: Secara default, Konsul memulai di localhost. Untuk mempublikasikan di Internet, Anda perlu menginstal semacam proxy. Kita bertanggung jawab atas aturan keselamatan kita sendiri.
Pertanyaan: Apakah ini menyediakan data historis secara langsung? Menarik sekali melihat statistik Pemeriksaan Kesehatan. Anda juga dapat mendiagnosis masalah jika server sering gagal.
Jawaban: Saya tidak yakin ada detail cek di sana.
Pertanyaan: Keadaan saat ini tidak sepenting dinamikanya.
Jawaban: Untuk analisis – ya.
Pertanyaan: Apakah lebih baik tidak menggunakan Service Discovery untuk buruh pelabuhan Konsul?
Answer: Saya tidak akan merekomendasikan menggunakannya. Tujuan dari laporan ini adalah untuk memperkenalkan konsep apa yang ada. Secara historis, menurut pendapat saya, ini telah mencapai versi pertama. Sekarang sudah ada solusi yang lebih lengkap, misalnya Kubernetes, yang memiliki semua ini. Sebagai bagian dari Kubernetes Service Discovery lebih rendah daripada Dll. Tapi saya tidak begitu familiar dengan Konsul. Oleh karena itu, saya memutuskan untuk membuat Service Discovery dengan menggunakan Consul sebagai contoh.
Pertanyaan: Bukankah skema dengan server pemimpin memperlambat permulaan aplikasi secara keseluruhan? Lalu bagaimana Konsul menentukan pemimpin baru jika yang ini berbohong?
Jawaban: Mereka memiliki keseluruhan protokol yang dijelaskan. Jika Anda tertarik, Anda bisa membacanya.
Pertanyaan: Konsul bertindak sebagai server lengkap bagi kami dan semua permintaan melewatinya?
Jawaban: Ini tidak bertindak sebagai server lengkap, tetapi mengambil alih zona tertentu. Biasanya diakhiri dengan service.consul. Dan kemudian kita melanjutkan secara logis. Kami tidak menggunakan nama domain dalam produksi, melainkan infrastruktur internal, yang biasanya tersembunyi di balik cache server jika kami bekerja menggunakan DNS.
Pertanyaan: Artinya, jika kita ingin mengakses suatu database, maka bagaimanapun kita akan menarik Konsul untuk mencari database tersebut terlebih dahulu bukan?
Jawaban: Ya. Jika kita bekerja menggunakan DNS, maka cara kerjanya sama seperti tanpa Konsul saat kita menggunakan nama DNS. Biasanya, aplikasi modern tidak menarik nama domain di setiap permintaan, karena kami menginstal koneksi, semuanya berfungsi dan dalam waktu dekat kami praktis tidak menggunakannya. Jika koneksi terputus, ya, kami bertanya lagi di mana markas kami dan pergi ke sana.
— Obrolan pengguna Hashicorp: Konsul, Nomad, Terraform
P.S. Mengenai pemeriksaan kesehatan. Konsul, seperti Kubernetes, menggunakan sistem yang sama untuk memeriksa status kelangsungan suatu layanan berdasarkan status kode.
200 OK for healthy
503 Service Unavailable for unhealthySumber:
Sumber: www.habr.com