Tentang lingkungan

Lingkungan menyediakan konteks terisolasi atau "sandbox" 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 sejumlah kecil proxy ke setiap lingkungan.

Tentang host dan lingkungan virtual

Hybrid Apigee menggunakan gateway ingress Istio untuk menangani traffic API masuk. Layanan MART dan runtime dikonfigurasi dengan gateway ingress Istio untuk mengelola koneksi yang diekspos di luar cluster. Artinya, misalnya, semua permintaan HTTP dan HTTPS ke proxy API ditangani terlebih dahulu oleh gateway ingress Istio.

Dalam hybrid, Anda membuat satu atau beberapa lingkungan dan menetapkan alias host ke setiap lingkungan. Alias host adalah nama DNS. Traffic masuk ke nama DNS tersebut dirutekan oleh ingress ke lingkungan tersebut. Secara internal, setiap lingkungan ditetapkan ke satu dan hanya satu pemroses pesan, yang melakukan tugas memproses permintaan proxy, menerapkan kebijakan, dan merutekan traffic ke dan dari layanan target. Oleh karena itu, alias host menentukan pemroses pesan mana yang menerima permintaan masuk tertentu.

Kode berikut menunjukkan contoh konfigurasi dengan beberapa lingkungan yang ditentukan. (Konfigurasi tersebut ada di file penggantian 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, ingress akan tahu cara mengirimkannya ke pemroses pesan yang terkait dengan lingkungan dev1, yang menangani permintaan.

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

Panggilan tersebut dirutekan oleh ingress 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 beberapa lingkungan yang dapat dikelola sesuai keinginan Anda. Misalnya, Anda dapat membuat beberapa lingkungan pengembangan, dev1, dev2, dev3, dan sebagainya, lalu memetakan satu alias host ke setiap lingkungan. Selain itu, Anda dapat men-deploy beberapa proxy ke setiap lingkungan.

Antipola: Men-deploy semua proxy Anda ke satu lingkungan hybrid.

Praktik terbaik: Buat beberapa lingkungan dan deploy sejumlah kecil proxy ke setiap lingkungan. Teknik untuk mengelola cara panggilan proxy rute hybrid ke lingkungan yang benar yang berbagi alias host 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 mengetahui informasi selengkapnya.

Membatasi jumlah deployment proxy

Untuk hybrid, fakta bahwa banyak lingkungan dapat berbagi host virtual yang sama berarti Anda harus berpikir matang tentang cara mengelola deployment proxy ke lingkungan tertentu. Dalam hybrid, praktik terbaiknya adalah membuat beberapa lingkungan dan men-deploy sejumlah kecil proxy 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 pertimbangkan saat mengelola deployment proxy:

Masalah yang perlu dipertimbangkan Deskripsi
Waktu booting Message Processor Ada korelasi langsung antara durasi waktu yang dibutuhkan prosesor pesan (MP) untuk melakukan booting dan jumlah proxy yang di-deploy ke MP tersebut. Di lingkungan Kubernetes dengan penskalaan otomatis, peningkatan waktu booting dapat menjadi masalah. Semakin banyak proxy yang di-deploy ke MP, semakin lama waktu yang dibutuhkan MP tersebut untuk aktif jika MP perlu diskalakan atau dibuat ulang.
Performa penskalaan Jika Anda memiliki beberapa proxy yang di-deploy ke lingkungan, dan salah satu proxy mendapatkan banyak traffic sehingga sering melakukan penskalaan otomatis, semua proxy di lingkungan tersebut akan melakukan penskalaan bersamanya. Efek performa penskalaan beberapa proxy dengan satu proxy traffic tinggi mungkin 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 dihentikan saat MP dimulai ulang. Dengan membatasi jumlah proxy yang di-deploy ke lingkungan, Anda meminimalkan dampak jika satu proxy mengalami error.

Referensi konfigurasi lingkungan

Untuk mengetahui daftar lengkap elemen konfigurasi lingkungan, lihat envs di Referensi properti konfigurasi.

Bekerja dengan lingkungan

Untuk mengetahui informasi selengkapnya tentang konfigurasi, lihat topik berikut: