"Bahaya adalah nama tengah saya," kata Austin Powers, seorang pria misterius dalam skala internasional. Tetapi apa yang dijunjung tinggi oleh agen-super dan layanan khusus sama sekali tidak cocok untuk layanan komputer, di mana hal-hal yang membosankan jauh lebih baik daripada bahaya.
Dan Istio, bersama dengan OpenShift dan Kubernetes, mengubah layanan microser menjadi bisnis yang benar-benar membosankan dan dapat diprediksi - dan itu hebat. Kami akan membicarakan hal ini dan banyak lagi di posting keempat dan terakhir dari seri Istio.Kapan kebosanan itu benar
Dalam kasus kami, kebosanan hanya terjadi pada fase akhir, ketika itu hanya duduk dan menonton prosesnya. Tetapi untuk ini, Anda perlu melakukan pra-konfigurasi segalanya, dan di sini Anda akan menemukan banyak hal menarik.Saat menggunakan versi baru perangkat lunak Anda, Anda harus mempertimbangkan semua opsi untuk meminimalkan risiko. Bekerja dalam mode paralel adalah metode pengujian yang sangat kuat dan terbukti, dan Istio memungkinkan Anda untuk menggunakan "layanan rahasia" (versi layanan mikro Anda yang tersembunyi dari mata yang mengintip) untuk ini tanpa mengganggu sistem produksi. Bahkan ada istilah khusus untuk ini - "Peluncuran Rahasia" (Peluncuran Gelap), yang pada gilirannya diaktifkan oleh fungsi dengan nama spyware paling sedikit "traffic mirroring".Perhatikan bahwa kalimat pertama paragraf sebelumnya menggunakan istilah "deploy" daripada "release". Anda benar-benar harus dapat menggunakan - dan, tentu saja, menggunakan - layanan mikro Anda sesering yang Anda inginkan. Layanan ini harus dapat menerima dan memproses lalu lintas, membuahkan hasil, serta menulis ke log dan memantau. Tetapi pada saat yang sama, layanan ini sendiri tidak harus dilepaskan ke produksi sama sekali. Penyebaran dan rilis perangkat lunak tidak selalu sama. Anda dapat melakukan penyebaran kapan pun Anda inginkan, tetapi lepaskan hanya ketika Anda benar-benar siap.Mengorganisir kebosanan itu menarik
Lihatlah aturan perutean Istio berikut ini, yang merutekan semua permintaan HTTP ke microservice rekomendasi v1 (semua contoh berasal dari repo Tutorial GitHub Tutorial ), sambil mencerminkannya ke rekomendasi v2 microservice:Perhatikan label mirror:di bagian bawah layar - merekalah yang mengatur mirror traffic. Ya, itu sangat sederhana!Hasil dari aturan ini adalah bahwa sistem produksi Anda (v1) akan terus memproses permintaan yang masuk, tetapi permintaan itu sendiri akan mencerminkan secara asinkron pada v2, yaitu, duplikat lengkap mereka akan pergi ke sana. Dengan demikian, Anda dapat menguji kerja v2 dalam kondisi nyata - pada data nyata dan lalu lintas - tanpa mengganggu kerja sistem produksi. Apakah ini membuat organisasi pengujian membosankan? Ya tentu saja. Tapi ini dilakukan dengan menarik.Tambahkan drama
Harap dicatat bahwa dalam kode v2, perlu untuk menyediakan situasi ketika permintaan masuk dapat menyebabkan perubahan data. Pertanyaannya sendiri dicerminkan dengan mudah dan transparan, tetapi pilihan metode pemrosesan dalam tes adalah milik Anda - dan ini sudah sedikit menarik.Ulangi poin penting
Peluncuran rahasia dengan mirroring lalu lintas (Dark Launch / Request Mirroring) dapat dilakukan tanpa memengaruhi kode.Bahan untuk dipikirkan
Tetapi bagaimana jika tempat untuk mencerminkan permintaan adalah untuk mengirim beberapa dari mereka bukan ke v1, tetapi ke v2? Misalnya, satu persen dari semua permintaan atau hanya permintaan dari grup pengguna tertentu. Dan kemudian, sudah melihat cara kerja v2, secara bertahap transfer semua permintaan ke versi baru. Atau sebaliknya, kembalikan semuanya ke v1 jika ada yang salah dengan v2. Tampaknya disebut Canary Deployment ("Canary Deployment" - istilah ini kembali ke penambangan , dan jika itu berasal dari Rusia, mungkin akan berisi referensi ke kucing ), dan sekarang kita akan memeriksanya lebih detail.Canary Deployment at Istio: menyederhanakan commissioning
Perhatian dan bertahap
Inti dari model penyebaran Canary sangat sederhana: ketika Anda memulai versi baru dari perangkat lunak Anda (dalam kasus kami, microservice), Anda pertama kali memberikan akses ke sekelompok kecil pengguna. Jika semuanya berjalan dengan baik, Anda perlahan-lahan meningkatkan grup ini sampai versi baru mulai sampah, atau - jika ini tidak terjadi - pada akhirnya transfer semua pengguna ke dalamnya. Dengan bijaksana dan secara bertahap memperkenalkan versi baru ke dalam operasi dan mengalihkan pengguna ke versi itu secara terkontrol, Anda dapat mengurangi risiko dan memaksimalkan umpan balik.Tentu saja, Istio menyederhanakan Penggunaan Canary dengan menawarkan beberapa opsi bagus untuk perutean kueri cerdas. Dan ya, semua ini dapat dilakukan tanpa menyentuh kode sumber Anda.Saring peramban
Salah satu kriteria perutean yang paling sederhana adalah pengalihan berbasis browser. Misalkan Anda ingin v2 hanya mengirim permintaan dari browser Safari. Inilah cara melakukannya:Kami menerapkan aturan perutean ini dan kemudian dengan perintah curlkami akan mensimulasikan permintaan nyata ke layanan mikro dalam satu lingkaran. Seperti yang dapat Anda lihat di tangkapan layar, semuanya menuju ke v1:Dan di mana lalu lintas di v2? Karena dalam contoh kita semua permintaan hanya datang dari baris perintah kita sendiri, itu tidak ada. Tetapi perhatikan garis bawah pada tangkapan layar di atas: ini adalah reaksi terhadap fakta bahwa kami mengeksekusi permintaan dari browser Safari, yang pada gilirannya mengeluarkan ini:Kekuatan tak terbatas
Kami sudah menulis bahwa ekspresi reguler memberikan kemampuan yang sangat kuat untuk merutekan kueri. Lihatlah contoh berikut (kami pikir Anda sendiri akan mengerti apa fungsinya):Sekarang Anda mungkin sudah tahu ekspresi reguler apa yang mampu.Bertindak cerdas
Perutean pintar, khususnya header paket pemrosesan menggunakan ekspresi reguler, memungkinkan Anda untuk mengarahkan lalu lintas seperti yang Anda inginkan. Dan ini sangat menyederhanakan komisioning kode baru - sederhana, tidak perlu mengubah kode itu sendiri, dan jika perlu, semuanya dapat dengan cepat dikembalikan seperti semula.Berminat?
Apakah Anda ingin bereksperimen dengan Istio, Kubernetes, dan OpenShift di komputer Anda? The Tim Pengembang Red Hat telah menyiapkan baik tutorial tentang topik ini dan berbagi semua file yang terkait. Jadi, teruskan saja, dan jangan menyangkal diri apa pun. Istio Egress: keluar melalui toko suvenir
Menggunakan Istio dengan Red Hat OpenShift dan Kubernetes dapat sangat menyederhanakan hidup Anda dengan layanan microser. Grid utilitas Istio disembunyikan di dalam pod Kubernetes, dan kode Anda dieksekusi (kebanyakan) secara terpisah. Performa, kemudahan perubahan, pelacakan dan banyak lagi - semua ini mudah digunakan secara tepat melalui penggunaan wadah sespan. Tetapi bagaimana jika microservice Anda perlu berkomunikasi dengan layanan lain yang terletak di luar sistem OpenShift-Kubernetes Anda?Di sinilah Istio Egress datang untuk menyelamatkan. Singkatnya, ini memungkinkan Anda untuk mengakses sumber daya (baca: "layanan") yang tidak termasuk dalam sistem Kubernetes Anda. Jika Anda tidak melakukan konfigurasi tambahan, maka di lingkungan Istio Egress, lalu lintas dirutekan hanya di dalam kelompok pod dan di antara kluster tersebut berdasarkan tabel IP internal. Dan pupping semacam ini berfungsi dengan baik sampai Anda membutuhkan akses ke layanan dari luar.Egress memungkinkan Anda untuk mem-bypass tabel IP yang disebutkan di atas, baik berdasarkan aturan Egress, atau untuk berbagai alamat IP.Misalkan kita memiliki program Java yang mengeksekusi permintaan GET ke httpbin.org/headers.(httpbin.org hanyalah sumber yang mudah untuk menguji permintaan layanan keluar.)Jika Anda mengetik pada prompt perintahcurl http://httpbin.org/headerskita akan melihat yang berikut ini:Atau Anda dapat membuka alamat yang sama di browser:Seperti yang Anda lihat, layanan yang terletak di sana hanya mengembalikan header yang diteruskan ke sana.Substitusi impor di dahi
Sekarang, mari kita ambil kode Java dari layanan ini eksternal ke sistem kami dan jalankan di rumah, di mana, ingat, Istio berdiri. (Anda dapat melakukannya sendiri dengan merujuk pada tutorial Istio kami .) Setelah membangun gambar yang sesuai dan menjalankannya pada platform OpenShift, kami akan memanggil layanan ini dengan perintah curl egresshttpbin-istioegress.$(minishift ip).nip.io, dan setelah itu kita akan melihat di layar ini:Ups, apa yang terjadi? Tetap saja itu berhasil. Apa Arti Tidak Ditemukan? Kami hanya melakukannya untuknya curl.Perpanjang tabel IP ke seluruh Internet
Salahkan (atau terima kasih) Istio untuk ini. Lagi pula, Istio hanyalah wadah sespan yang bertanggung jawab untuk deteksi dan perutean (well, untuk banyak hal lain yang telah kita bicarakan sebelumnya). Untuk alasan ini, tabel IP hanya tahu apa yang ada di dalam sistem cluster Anda. Dan httpbin.org terletak di luar dan karenanya tidak tersedia. Dan di sini Istio Egress datang untuk menyelamatkan - tanpa sedikit pun perubahan dalam kode sumber Anda.Aturan Egress berikut memaksa Istio untuk mencari (jika perlu, kemudian di seluruh Internet) untuk layanan yang diinginkan, dalam hal ini, httpbin.org. Seperti yang dapat Anda lihat dari file ini (egress_httpbin.yml), fungsi di sini cukup sederhana:Tetap hanya menerapkan aturan ini:istioctl create -f egress_httpbin.yml -n istioegress
Anda dapat melihat aturan Egress dengan perintah istioctl get egressrules:Dan akhirnya, jalankan perintah curl lagi - dan lihat semuanya bekerja:Kami berpikir secara terbuka
Seperti yang Anda lihat, Istio memungkinkan Anda untuk mengatur interaksi dengan dunia luar. Dengan kata lain, Anda masih bisa membuat layanan OpenShift dan mengarahkannya melalui Kubernetes, memegang semua yang ada di pod yang naik turun sesuai kebutuhan. Dan pada saat yang sama, Anda dapat dengan aman mengakses layanan di luar lingkungan Anda. Dan ya, kami ulangi sekali lagi bahwa semua ini dapat dilakukan tanpa menyentuh kode Anda.Ini adalah pos terakhir dalam seri Istio. Tetap bersama kami - ada banyak hal menarik di depan!