Migrasi ke router dan load balancer NGINX

Anda sedang melihat dokumentasi Apigee Edge.
Buka dokumentasi Apigee X.
info

Selama bulan Agustus dan September 2015, kami memigrasikan router cloud dan load balancer Apigee Edge ke NGINX (dibaca "Engine X"). NGINX, server web open source, memberikan performa yang lebih baik dan konkurensi yang lebih tinggi daripada load balancer dan router kami yang sudah ada.

Artinya bagi pelanggan cloud kami

Intinya adalah perubahan ini harus transparan kepada Anda dan tidak memerlukan tindakan selain dari verifikasi bahwa sistem Anda telah berfungsi seperti yang diharapkan. Berikut adalah deskripsi langkah-langkah yang akan kami lakukan, beserta jawaban atas beberapa pertanyaan umum (FAQ).

Langkah 1 - Update software

Kami akan mengupgrade semua router ke router berbasis NGINX yang baru dengan memanfaatkan model deployment bertahap untuk membantu memastikan layanan tidak terpengaruh akibat aktivitas ini.

Langkah 2 - Hapus tingkat load balancer di lingkungan non-produksi

Dengan router NGINX baru yang menangani fungsi load balancing, kami akan memulai proses penghapusan tingkat load balancer yang ada di lingkungan non-produksi Anda terlebih dahulu. Load balancer produksi akan tetap utuh dan tidak berubah selama langkah ini. Sebelum penghapusan load balancer yang ada, kami akan menerapkan pendekatan menyeluruh guna memastikan traffic berfungsi sesuai harapan. Anda tidak perlu melakukan tindakan apa pun untuk menyelesaikan langkah ini. Namun, Anda harus melaporkan masalah apa pun ke Apigee, dan kami akan bekerja sama dengan Anda untuk menyelesaikan masalah tersebut sebelum melanjutkan ke Langkah 3.

Langkah 3 - Menghapus tingkat load balancer di lingkungan produksi

Setelah berhasil menyelesaikan Langkah 2, kami akan menentukan serangkaian masa pemeliharaan untuk menghapus tingkat load balancer di lingkungan produksi menggunakan pendekatan yang sama seperti yang disebutkan di Langkah 2 untuk memastikan traffic API runtime terus berfungsi seperti yang diharapkan.

Perubahan pada fungsi produk

Berikut adalah beberapa perubahan pada fungsi produk dengan peralihan ke NGINX.

Tidak digunakan lagi

Properti berikut tidak lagi didukung di ProxyEndpoints:

  • allow.http10
  • allow.http11
  • allow.http.method.*
  • allow.POST.without.content.length
  • allow.PUT.without.content.length

Untuk mengatasi penghentian ini, lihat artikel komunitas berikut: https://community.apigee.com/questions/16134/proxy-endpoint-http-allow-method-properties-not-wo.html.

Pertanyaan umum (FAQ)

Berikut adalah jawaban atas beberapa pertanyaan umum (FAQ) tentang migrasi NGINX.

Apakah hal ini berpotensi mengubah IP publik? Beberapa penjual kami secara khusus mengizinkan akses dari IP yang diketahui, dan saat mereka mengubah jeda alur penjual.
Pada Langkah 1, jawabannya adalah 'Tidak' karena kita tidak menggunakan load balancer yang ada, yang tidak akan secara langsung mengubah IP yang menayangkan traffic. Namun, mengingat sifat layanan load balancing Amazon Web Services (AWS), aturan penskalaan normal berlaku, yang berarti IP dapat berubah sebagai bagian dari logika penskalaannya (fungsi yang ada). Inilah sebabnya kami tidak merekomendasikan penerapan konfigurasi pemberian izin Northbound dengan suite produk Apigee Edge. Selama Langkah 2 dan 3, ada implikasi daftar yang diizinkan dengan penghapusan load balancer dan alamat IP terkaitnya. Oleh karena itu, kami akan berkoordinasi erat dengan Anda selama langkah-langkah ini untuk memastikan transisi yang lancar dengan memberikan kumpulan alamat IP baru yang diizinkan aksesnya.
Apakah hal ini akan memengaruhi pembatasan IP yang kami terapkan di server origin?
Perubahan tidak diperlukan, dengan asumsi server asal adalah server endpoint target (server yang dipanggil dari paket proxy). Perubahan ini berada di sisi Utara Apigee atau titik masuk ke Apigee.
Apakah CNAME yang ada memerlukan perubahan?
Tidak. Entri CNAME yang ada akan tetap berfungsi seperti yang diharapkan.
Migrasi sertifikat SSL akan menyusahkan. Bagaimana Anda akan menangani hal ini?
Jika Anda menggunakan SSL, langkah awal tidak akan memengaruhi konfigurasi SSL yang ada. Namun, kami perlu berkoordinasi erat dengan Anda untuk memastikan SSL disiapkan dengan benar di router baru sebelum melanjutkan ke Langkah 2 dan 3.
Bagaimana jika aplikasi/klien saya tidak mendukung SNI?
Langkah 2 dan 3 akan ditunda hingga dukungan SNI dikonfirmasi.
Apakah akan ada periode nonaktif?
Kami tidak mengantisipasi periode nonaktif ini. Perubahan akan diterapkan menggunakan model deployment standar kami selama periode rilis yang ada.