Lingkungan menyediakan konteks atau "sandbox" yang terisolasi untuk menjalankan proxy API. Dalam satu organisasi, Anda dapat membuat beberapa lingkungan. Untuk informasi selengkapnya, lihat Tentang lingkungan dan grup lingkungan.
Selama penginstalan dasar, Anda menambahkan untuk pengujian. Namun, praktik terbaiknya adalah membuat beberapa lingkungan dan men-deploy proxy dalam jumlah terbatas ke tiap variabel tersebut.
Tentang host dan lingkungan virtual
Penggunaan hybrid Apigee Gateway masuk Istio untuk menangani traffic API yang masuk. Metode MART dan Kedua layanan runtime dikonfigurasi dengan gateway masuk Istio untuk mengelola yang terbuka di luar cluster. Ini berarti, misalnya, semua permintaan HTTP dan HTTPS ke proxy API akan ditangani terlebih dahulu oleh gateway masuk Istio.
Dalam hybrid, Anda membuat satu atau beberapa lingkungan dan menetapkan alias host untuk setiap lingkungan. Alias {i>host<i} adalah nama DNS. Lalu lintas yang masuk ke nama DNS itu dirutekan melalui jalur masuk ke server lingkungan fleksibel App Engine. Secara internal, setiap lingkungan ditetapkan ke satu dan hanya satu pemroses pesan, yang bekerja memproses permintaan {i>proxy<i}, menerapkan kebijakan, dan mengarahkan lalu lintas ke dan dari layanan target. Oleh karena itu, alias host menentukan prosesor pesan yang menerima menerima permintaan masuk.
Kode berikut menunjukkan contoh konfigurasi di mana beberapa lingkungan didefinisikan. (Konfigurasi semacam ini termasuk dalam file pengganti Anda.) Perhatikan bahwa lingkungan dev1 dan prod1 memiliki alias host yang berbeda:
envs:
- name: dev1
hostAlias: "apitest.mydomain.net"
...
- name: prod1
hostAlias: "apiprod.mydomain.net"
...
Misalkan proxy dengan jalur dasar /foo1 di-deploy ke lingkungan
dev1. Anda dapat memanggil proxy seperti ini:
curl -k https://apitest.mydomain.net/foo1
Saat panggilan ini mencapai ingress, traffic masuk akan tahu untuk mengirimnya ke pemroses pesan
yang terkait dengan lingkungan dev1, yang menangani permintaan.
Demikian pula, jika foo1 juga di-deploy ke lingkungan prod1,
Anda bisa membuat {i>proxy<i}
permintaan seperti ini, ke alias host apiprod.mydomain.net:
curl -k https://apiprod.mydomain.net/foo1
Dan panggilan dirutekan oleh masuknya ke MP yang terkait dengan host tersebut.
Singkatnya, setiap lingkungan yang Anda buat harus memiliki alias host yang ditetapkan untuknya. Setiap lingkungan dipetakan ke satu dan hanya satu pemroses pesan, dan alias host menentukan pemroses pesan mana yang menerima permintaan tertentu.
Lingkungan dapat berbagi alias host yang sama
Apigee Hybrid memungkinkan Anda membuat berbagai lingkungan yang dapat dikelola sesuai keinginan Anda. Sebagai Anda dapat membuat sejumlah lingkungan pengembangan, yaitu dev1, dev2, dev3, dan seterusnya, serta memetakan alias {i>host<i} tunggal ke masing-masing {i>host<i}. Selain itu, Anda dapat men-deploy beberapa proxy ke setiap lingkungan.
Antipattern: Deploy semua proxy Anda ke satu lingkungan hybrid.
Praktik terbaik: Buat beberapa lingkungan dan deploy proxy dalam jumlah terbatas ke tiap variabel tersebut. Teknik untuk mengelola cara hybrid merutekan panggilan proxy ke metode lingkungan yang menggunakan alias host yang sama disebut perutean jalur dasar.
Misalnya, dalam konfigurasi berikut, lingkungan dev1 dan dev2 berbagi alias host yang sama:
envs:
- name: dev1
hostAlias: "apitest.mydomain.net"
...
- name: dev2
hostAlias: "apitest.mydomain.net"
...
Jika beberapa lingkungan berbagi alias host yang sama, Anda harus menggunakan teknik konfigurasi yang disebut perutean jalur dasar untuk memetakan jalur dasar proxy tertentu ke lingkungan tertentu. Lihat perutean jalur dasar untuk informasi selengkapnya.
Batasi jumlah deployment proxy
Untuk hybrid, fakta bahwa banyak lingkungan dapat berbagi {i>host<i} virtual yang sama Anda harus memikirkan secara cermat cara mengelola penyebaran {i>proxy<i} Anda ke setiap alamat lingkungan fleksibel App Engine. Dalam sistem hybrid, praktik terbaik adalah membuat beberapa lingkungan dan men-deploy jumlah {i>proxy<i} yang terbatas di masing-masing {i>proxy<i}.
Berapa banyak proxy yang harus Anda deploy ke suatu lingkungan? Tidak ada jawaban yang pasti atas pertanyaan ini; Namun, tabel berikut memberikan panduan umum tentang mengapa ide yang baik untuk membatasi jumlah {i>proxy<i} yang dikerahkan ke setiap lingkungan dan apa yang Anda pertimbangkan saat mengelola deployment proxy:
| Masalah yang perlu dipertimbangkan | Deskripsi |
|---|---|
| Waktu booting pemroses pesan | Ada korelasi langsung antara durasi waktu pemroses pesan (MP) yang dibutuhkan untuk {i>booting<i} dan jumlah {i> proxy<i} yang di-deploy ke MP tersebut. Dalam penskalaan otomatis lingkungan Kubernetes, peningkatan waktu booting mungkin menjadi masalah. Semakin banyak {i>proxy<i} yang di-deploy ke MP, semakin lama waktu yang dibutuhkan perlu diskalakan atau dibuat ulang. |
| Menskalakan performa | Jika Anda memiliki beberapa {i>proxy<i} yang di-deploy ke suatu lingkungan, dan salah satu {i>proxy<i} itu banyak lalu lintas sehingga sering kali melakukan skala otomatis, semua {i>proxy<i} yang akan menyesuaikan dengan skala data. Efek performa dari penskalaan beberapa {i>proxy<i} dengan satu {i>proxy<i} dengan lalu lintas tinggi mungkin menjadi masalah. |
| Tetangga berisik | Jika Anda memiliki beberapa proxy yang di-deploy ke lingkungan yang sama, dan satu proxy error, maka semua {i>proxy<i} di lingkungannya akan dihapus sementara Anggota parlemen dimulai ulang. Dengan membatasi jumlah {i>proxy<i} yang di-deploy ke suatu lingkungan, Anda meminimalkan dampak kerusakan {i> proxy<i} tunggal. |
Referensi konfigurasi lingkungan
Untuk mengetahui daftar lengkap elemen konfigurasi lingkungan, lihat envs di
Referensi properti konfigurasi.
Bekerja dengan lingkungan
Untuk informasi selengkapnya tentang konfigurasi, lihat topik berikut: