Lingkungan menyediakan konteks atau "sandbox" yang terisolasi untuk menjalankan proxy API. Dalam satu organisasi, Anda dapat membuat beberapa lingkungan. Untuk mengetahui informasi selengkapnya, lihat Tentang lingkungan dan grup lingkungan.
Selama penginstalan dasar, Anda menambahkan lingkungan untuk pengujian. Namun, praktik terbaiknya adalah membuat beberapa lingkungan dan men-deploy jumlah proxy yang terbatas ke setiap lingkungan.
Tentang host dan lingkungan virtual
Apigee Hybrid menggunakan Gateway masuk Istio untuk menangani traffic API yang masuk. Layanan MART dan runtime dikonfigurasi dengan gateway masuk Istio untuk mengelola koneksi yang terekspos di luar cluster. Artinya, semua permintaan HTTP dan HTTPS ke proxy API akan ditangani terlebih dahulu oleh gateway masuk Istio.
Dalam sistem hybrid, Anda membuat satu atau beberapa lingkungan, lalu menetapkan alias host untuk setiap lingkungan. Alias host adalah nama DNS. Traffic masuk ke nama DNS tersebut dirutekan oleh traffic masuk ke lingkungan tersebut. Secara internal, setiap lingkungan ditetapkan ke satu dan hanya satu pemroses pesan yang berfungsi memproses permintaan proxy, menerapkan kebijakan, dan merutekan traffic ke dan dari layanan target. Oleh karena itu, alias host menentukan pemroses pesan mana yang akan menerima setiap permintaan masuk.
Kode berikut menunjukkan contoh konfigurasi tempat beberapa lingkungan ditentukan. (Konfigurasi tersebut termasuk dalam file penggantian Anda.) Perlu diingat 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 {i>proxy<i} seperti ini:
curl -k https://apitest.mydomain.net/foo1
Saat panggilan ini mencapai ingress, ingress akan tahu untuk mengirimkannya ke pemroses pesan yang terkait dengan lingkungan dev1, yang menangani permintaan tersebut.
Demikian pula, jika foo1 juga di-deploy ke lingkungan prod1,
Anda dapat membuat permintaan
proxy seperti ini, ke alias host apiprod.mydomain.net:
curl -k https://apiprod.mydomain.net/foo1
Dan panggilan dialihkan oleh masuknya ke MP yang terkait dengan {i>host<i} tersebut.
Singkatnya, setiap lingkungan yang Anda buat harus memiliki alias host yang ditetapkan untuk lingkungan tersebut. Setiap lingkungan dipetakan ke satu dan hanya satu pemroses pesan, dan alias host menentukan pemroses pesan mana yang menerima permintaan tertentu.
Lingkungan dapat memiliki alias host yang sama
Apigee Hybrid memungkinkan Anda membuat beberapa lingkungan yang dapat dikelola sesuai keinginan. Misalnya, Anda dapat membuat beberapa lingkungan developer, dev1, dev2, dev3, dan seterusnya, serta memetakan satu alias host ke setiap lingkungan. Selain itu, Anda dapat men-deploy beberapa proxy ke setiap lingkungan.
Antipola: Deploy semua proxy Anda ke satu lingkungan hybrid.
Praktik terbaik: Buat beberapa lingkungan dan deploy proxy dalam jumlah terbatas ke setiap lingkungan. Teknik untuk mengelola bagaimana hybrid merutekan panggilan proxy ke lingkungan yang benar dan memiliki alias host yang sama disebut perutean jalur dasar.
Misalnya, dalam konfigurasi berikut, lingkungan dev1 dan dev2 memiliki alias host yang sama:
envs:
- name: dev1
hostAlias: "apitest.mydomain.net"
...
- name: dev2
hostAlias: "apitest.mydomain.net"
...
Jika beberapa lingkungan memiliki alias host yang sama, Anda harus menggunakan teknik konfigurasi yang disebut perutean jalur dasar untuk memetakan jalur dasar proxy tertentu ke lingkungan tertentu. Lihat pemilihan rute jalur dasar untuk informasi selengkapnya.
Membatasi jumlah deployment proxy
Untuk hybrid, fakta bahwa banyak lingkungan dapat berbagi host virtual yang sama berarti Anda harus memikirkan dengan cermat cara mengelola deployment proxy ke lingkungan tertentu. Dalam sistem hybrid, praktik terbaiknya adalah membuat beberapa lingkungan dan men-deploy proxy dalam jumlah terbatas ke setiap lingkungan.
Berapa banyak proxy yang harus Anda deploy ke lingkungan? Tidak ada jawaban pasti untuk pertanyaan ini; namun, tabel berikut memberikan panduan umum tentang alasan sebaiknya membatasi jumlah proxy yang di-deploy ke setiap lingkungan dan hal yang perlu Anda pikirkan ketika mengelola deployment proxy:
| Masalah yang perlu dipertimbangkan | Deskripsi |
|---|---|
| Waktu booting pemroses pesan | Ada korelasi langsung antara jumlah waktu yang diperlukan prosesor pesan (MP) untuk melakukan booting dan jumlah proxy yang di-deploy ke MP tersebut. Dalam lingkungan Kubernetes penskalaan otomatis, peningkatan waktu booting mungkin menjadi masalah. Semakin banyak proxy yang di-deploy ke MP, semakin lama waktu yang diperlukan untuk memunculkan MP jika perlu diskalakan atau dibuat ulang. |
| Menskalakan performa | Jika Anda memiliki beberapa proxy yang di-deploy ke suatu lingkungan, dan salah satu proxy mendapatkan banyak traffic sehingga sering kali melakukan penskalaan otomatis, semua proxy di lingkungan tersebut akan menskalakannya. Efek performa dari penskalaan beberapa proxy dengan satu proxy dengan traffic tinggi mungkin akan menjadi masalah. |
| Tetangga yang berisik | Jika Anda memiliki beberapa proxy yang di-deploy ke lingkungan yang sama, dan satu proxy mengalami error, semua proxy di lingkungan tersebut akan dihapus saat Anggota Parlemen dimulai ulang. Dengan membatasi jumlah proxy yang di-deploy ke suatu lingkungan, Anda meminimalkan dampak error pada satu proxy. |
Referensi konfigurasi lingkungan
Untuk mengetahui daftar lengkap elemen konfigurasi lingkungan, lihat envs dalam
Referensi properti konfigurasi.
Bekerja dengan lingkungan
Untuk informasi selengkapnya tentang konfigurasi, lihat topik berikut: