“Bahaya adalah nama tengah saya,” kata Austin Powers, seorang pria misterius internasional. Namun apa yang dijunjung tinggi oleh agen super dan badan intelijen sama sekali tidak cocok untuk layanan komputer, di mana kebosanan jauh lebih baik daripada bahaya.
Dan Istio, bersama dengan OpenShift dan Kubernetes, menjadikan penerapan layanan mikro benar-benar membosankan dan dapat diprediksi - dan itu bagus. Kita akan membicarakan hal ini dan lebih banyak lagi di postingan keempat dan terakhir seri Istio.
Saat kebosanan itu benar
Dalam kasus kami, kebosanan hanya terjadi pada fase akhir, ketika yang tersisa hanyalah duduk dan menonton prosesnya. Tetapi untuk ini Anda perlu mengkonfigurasi semuanya terlebih dahulu, dan banyak hal menarik menanti Anda di sini.
Saat menerapkan versi baru perangkat lunak Anda, ada baiknya mempertimbangkan semua opsi untuk meminimalkan risiko. Menjalankan secara paralel adalah cara pengujian yang sangat ampuh dan terbukti, dan Istio memungkinkan Anda menggunakan "layanan rahasia" (versi tersembunyi dari layanan mikro Anda) untuk melakukan ini tanpa mengganggu sistem produksi. Bahkan ada istilah khusus untuk ini - "Peluncuran Gelap", yang pada gilirannya diaktifkan oleh fungsi dengan nama mata-mata yang sama "pencerminan lalu lintas".
Perlu diketahui bahwa kalimat pertama paragraf sebelumnya menggunakan istilah “deploy” dan bukan “release”. Anda harus benar-benar dapat menerapkan—dan, tentu saja, menggunakan—layanan mikro Anda sesering yang Anda mau. Layanan ini harus dapat menerima dan memproses lalu lintas, memberikan hasil, dan juga menulis ke log dan memantau. Namun pada saat yang sama, layanan ini sendiri tidak perlu dirilis ke dalam produksi. Menyebarkan dan merilis perangkat lunak tidak selalu sama. Anda dapat menerapkannya kapan pun Anda mau, namun rilis hanya jika Anda sudah siap.
Mengorganisasi kebosanan memang menarik
Lihatlah aturan perutean Istio berikut, yang merutekan semua permintaan HTTP ke rekomendasi layanan mikro v1 (semua contoh diambil dari ), sekaligus mencerminkannya ke layanan mikro rekomendasi v2:
Perhatikan labelnya mirror: di bagian bawah layar - inilah yang mengatur pencerminan lalu lintas. Ya, sesederhana itu!
Hasil dari aturan ini adalah sistem produksi Anda (v1) akan terus memproses permintaan yang masuk, tetapi permintaan itu sendiri akan dicerminkan secara asinkron ke v2, yaitu duplikat lengkapnya akan dikirim ke sana. Dengan cara ini, Anda dapat menguji v2 dalam kondisi nyata - pada data dan lalu lintas nyata - tanpa mengganggu pengoperasian sistem produksi dengan cara apa pun. Apakah ini membuat pengorganisasian pengujian menjadi membosankan? Iya tentu saja. Tapi itu dilakukan dengan cara yang menarik.
Mari tambahkan drama
Harap dicatat bahwa dalam kode v2 perlu untuk menyediakan situasi di mana permintaan masuk dapat menyebabkan perubahan data. Permintaannya sendiri dicerminkan dengan mudah dan transparan, namun pilihan metode pemrosesan dalam pengujian terserah Anda – dan ini agak mengkhawatirkan.
Mari kita ulangi satu poin penting
Peluncuran rahasia dengan pencerminan lalu lintas (Peluncuran Gelap/Pencerminan Permintaan) dapat dilakukan tanpa memengaruhi kode dengan cara apa pun.
Inspirasi
Bagaimana jika tempat di mana permintaan dicerminkan mengirimkan beberapa di antaranya bukan ke v1, tetapi ke v2? Misalnya satu persen dari seluruh permintaan atau hanya permintaan dari kelompok pengguna tertentu. Dan kemudian, setelah melihat cara kerja v2, secara bertahap transfer semua permintaan ke versi baru. Atau sebaliknya, kembalikan semuanya ke v1 jika terjadi kesalahan pada v2. Saya pikir itu disebut Canary Deployment. , dan jika berasal dari Rusia, mungkin berisi referensi ke ), dan sekarang kita akan melihatnya lebih detail.
Penerapan Canary di Istio: menyederhanakan commissioning
Dengan hati-hati dan bertahap
Inti dari model penerapan Canary Deployment sangat sederhana: saat Anda meluncurkan versi baru perangkat lunak Anda (dalam kasus kami, layanan mikro), pertama-tama Anda memberikan akses ke perangkat lunak tersebut kepada sekelompok kecil pengguna. Jika semuanya berjalan dengan baik, Anda perlahan-lahan meningkatkan grup ini hingga versi baru mulai berfungsi, atau - jika tidak - akhirnya memigrasikan semua pengguna ke grup tersebut. Dengan memperkenalkan versi baru secara hati-hati dan bertahap serta mengalihkan pengguna ke versi tersebut dengan cara yang terkendali, Anda dapat mengurangi risiko dan memaksimalkan masukan.
Tentu saja, Istio menyederhanakan Canary Deployment dengan menawarkan beberapa opsi bagus untuk perutean permintaan yang cerdas. Dan ya, semua ini dapat dilakukan tanpa menyentuh kode sumber Anda dengan cara apa pun.
Memfilter browser
Salah satu kriteria perutean yang paling sederhana adalah pengalihan berbasis browser. Katakanlah Anda hanya ingin permintaan dari browser Safari menuju ke v2. Begini cara melakukannya:
Mari kita terapkan aturan perutean ini dan kemudian gunakan perintahnya curl Kami akan mensimulasikan permintaan nyata ke layanan mikro dalam satu lingkaran. Seperti yang Anda lihat di tangkapan layar, semuanya menuju ke v1:
Di mana lalu lintas di v2? Karena dalam contoh kita semua permintaan hanya datang dari baris perintah kita sendiri, maka permintaan itu tidak ada. Namun perhatikan garis bawah pada layar di atas: ini adalah reaksi terhadap fakta bahwa kami menjalankan permintaan dari browser Safari, yang kemudian menghasilkan ini:
Kekuatan tak terbatas
Kami telah menulis bahwa ekspresi reguler memberikan kemampuan yang sangat kuat untuk merutekan permintaan. Lihatlah contoh berikut (kami yakin Anda akan memahami fungsinya):
Sekarang Anda mungkin sudah memiliki gambaran tentang apa yang dapat dilakukan ekspresi reguler.
Bertindak Cerdas
Perutean cerdas, khususnya pemrosesan header paket menggunakan ekspresi reguler, memungkinkan Anda mengarahkan lalu lintas sesuai keinginan Anda. Dan ini sangat menyederhanakan implementasi kode baru - sederhana, tidak perlu mengubah kode itu sendiri, dan jika perlu, semuanya dapat dengan cepat dikembalikan seperti semula.
Tertarik?
Apakah Anda ingin bereksperimen dengan Istio, Kubernetes, dan OpenShift di komputer Anda? Tim menyiapkan yang luar biasa tentang topik ini dan membuat semua file yang menyertainya tersedia untuk umum. Jadi silakan dan jangan menyangkal diri Anda apa pun.
Istio Egress: keluar melalui toko suvenir
Dengan menggunakan Istio bersama Red Hat OpenShift dan Kubernetes, Anda dapat membuat hidup Anda dengan layanan mikro menjadi lebih mudah. Jaring layanan Istio disembunyikan di dalam pod Kubernetes, dan kode Anda (kebanyakan) berjalan secara terpisah. Performa, kemudahan perubahan, penelusuran, dll. – semua ini mudah digunakan berkat penggunaan wadah sespan. Namun bagaimana jika layanan mikro Anda perlu berkomunikasi dengan layanan lain yang berlokasi di luar sistem OpenShift-Kubernetes Anda?
Di sinilah Istio Egress datang untuk menyelamatkan. Singkatnya, ini memungkinkan Anda mengakses sumber daya (baca: “layanan”) yang bukan bagian dari sistem pod Kubernetes Anda. Jika Anda tidak melakukan konfigurasi tambahan, maka di lingkungan Istio Egress, lalu lintas hanya dirutekan dalam satu cluster pod dan antar cluster tersebut berdasarkan tabel IP internal. Dan kepompong seperti itu berfungsi dengan baik selama Anda tidak memerlukan akses layanan dari luar.
Egress memungkinkan Anda melewati tabel IP di atas, baik berdasarkan aturan Egress atau berdasarkan rentang alamat IP.
Misalkan kita mempunyai program Java yang membuat permintaan GET ke httpbin.org/headers.
(httpbin.org hanyalah sumber yang mudah digunakan untuk menguji permintaan layanan keluar.)
Jika Anda masuk pada baris perintah curl http://httpbin.org/headers, kita akan melihat yang berikut:
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.
Kami langsung mengganti impor
Sekarang mari kita ambil kode Java dari layanan ini, di luar sistem kita, dan menjalankannya sendiri, di mana, ingat, Istio diinstal. (Anda dapat melakukannya sendiri dengan menghubungi .) Setelah membuat image yang sesuai dan meluncurkannya di platform OpenShift, kami akan memanggil layanan ini dengan perintah curl egresshttpbin-istioegress.$(minishift ip).nip.io, setelah itu kita akan melihat ini di layar:
Ups, apa yang terjadi? Semuanya berhasil. Apa yang dimaksud dengan Tidak Ditemukan? Kami hanya melakukannya untuknya curl.
Memperluas tabel IP ke seluruh Internet
Istio harus disalahkan (atau berterima kasih) untuk ini. Bagaimanapun, Istio hanyalah container sespan yang bertanggung jawab untuk deteksi dan perutean (dan banyak hal lain yang telah kita bicarakan sebelumnya). Karena alasan ini, tabel IP hanya mengetahui apa yang ada di dalam sistem cluster Anda. Dan httpbin.org terletak di luar sehingga tidak dapat diakses. Dan di sinilah Istio Egress datang untuk menyelamatkan - tanpa perubahan sedikit pun pada kode sumber Anda.
Aturan Egress di bawah memaksa Istio untuk mencari (jika perlu, di seluruh Internet) layanan yang diperlukan, dalam hal ini, httpbin.org. Seperti yang Anda lihat dari file ini (egress_httpbin.yml), fungsinya di sini cukup sederhana:
Yang tersisa hanyalah menerapkan aturan ini:
istioctl create -f egress_httpbin.yml -n istioegress
Anda dapat melihat aturan Egress dengan perintah istioctl get egressrules:
Dan terakhir, kita jalankan perintah itu lagi keriting – dan kami melihat semuanya berfungsi:
Kami berpikir secara terbuka
Seperti yang Anda lihat, Istio memungkinkan Anda mengatur interaksi dengan dunia luar. Dengan kata lain, Anda masih dapat membuat layanan OpenShift dan mengelolanya melalui Kubernetes, menyimpan semuanya di pod yang dapat ditingkatkan dan diturunkan skalanya sesuai kebutuhan. Dan pada saat yang sama, Anda dapat mengakses layanan di luar lingkungan Anda dengan aman. Dan ya, kami ulangi sekali lagi bahwa semua ini dapat dilakukan tanpa menyentuh kode Anda dengan cara apa pun.
Ini adalah postingan terakhir dalam seri di Istio. Pantau terus - ada banyak hal menarik di depan!
Sumber: www.habr.com