Lingkungan menyediakan konteks atau "sandbox" terisolasi untuk menjalankan proxy API.
Dalam satu organisasi, Anda dapat membuat beberapa lingkungan. Untuk informasi selengkapnya,
lihat Tentang lingkungan dan grup lingkungan.
Kode berikut menunjukkan contoh konfigurasi penggantian dengan beberapa lingkungan
yang ditentukan. Perhatikan bahwa lingkungan
prod dan test memiliki alias host yang berbeda:
Misalkan proxy dengan jalur dasar /foo1 di-deploy ke lingkungan
pengujian. Anda dapat memanggil proxy seperti ini:
curl -k https://api.example.com/foo1
Saat panggilan ini mencapai ingress, ingress akan tahu untuk mengirimkannya ke pemroses pesan
yang terkait dengan lingkungan test, yang menangani permintaan.
Demikian pula, jika foo1 juga di-deploy ke lingkungan prod,
Anda dapat membuat permintaan
proxy seperti ini, ke alias host apiprod.mydomain.net:
curl -k https://apiprod.example.com/foo1
Selain itu, panggilan dirutekan oleh ingress ke MP yang terkait dengan host tersebut.
Antipola: Men-deploy semua proxy ke satu lingkungan campuran.
Praktik terbaik: Buat beberapa lingkungan dan deploy proxy dalam jumlah terbatas ke setiap lingkungan. Anda dapat membuat aturan pemilihan rute yang menentukan lingkungan mana yang akan merutekan jalur dasar proxy API tertentu. Untuk mengetahui detailnya, lihat Konfigurasi host virtual.
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 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 yang ditetapkan
untuk pertanyaan ini; namun, tabel berikut memberikan panduan umum tentang mengapa sebaiknya
membatasi jumlah proxy yang di-deploy ke setiap lingkungan dan hal-hal yang
perlu Anda pertimbangkan saat mengelola deployment proxy:
Masalah yang perlu dipertimbangkan
Deskripsi
Waktu booting Message Processor
Ada korelasi langsung antara jumlah waktu yang diperlukan pemroses 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. Makin banyak proxy
yang di-deploy ke MP, makin lama waktu yang diperlukan MP tersebut untuk muncul jika
perlu diskalakan atau dibuat ulang.
Melakukan penskalaan performa
Jika Anda memiliki beberapa proxy yang di-deploy ke lingkungan, dan salah satu proxy mendapatkan
banyak traffic sehingga sering diskalakan secara otomatis, semua proxy di lingkungan
tersebut akan diskalakan bersama. Efek performa dari penskalaan beberapa proxy dengan satu proxy traffic tinggi mungkin menjadi masalah.
Tetangga berisik
Jika Anda memiliki beberapa proxy yang di-deploy ke lingkungan yang sama, dan satu proxy
mengalami error, semua proxy di lingkungan tersebut akan dinonaktifkan saat
MP dimulai ulang. Dengan membatasi jumlah proxy yang di-deploy ke lingkungan, Anda
akan meminimalkan dampak error satu proxy.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-03 UTC."],[[["\u003cp\u003eThis documentation version (1.2) is end-of-life and users should upgrade to a newer, supported version.\u003c/p\u003e\n"],["\u003cp\u003eEnvironments provide isolated sandboxes for running API proxies, and multiple environments can be created within a single organization.\u003c/p\u003e\n"],["\u003cp\u003eVirtual hosts map routing rules to specific environments, allowing different host aliases to route traffic to different environments like 'test' and 'prod'.\u003c/p\u003e\n"],["\u003cp\u003eBest practice dictates creating multiple environments and deploying a limited number of proxies to each to ensure better performance, scalability, and fault isolation.\u003c/p\u003e\n"],["\u003cp\u003eFactors such as message processor boot-up time, scaling performance, and the "noisy neighbor" effect should be considered when determining the number of proxies to deploy to an environment.\u003c/p\u003e\n"]]],[],null,["# About environments\n\n| You are currently viewing version 1.2 of the Apigee hybrid documentation. **This version is end of life.** You should upgrade to a newer version. For more information, see [Supported versions](/apigee/docs/hybrid/supported-platforms#supported-versions).\n\nAn *environment* provides an isolated context or \"sandbox\" for running API proxies.\nIn a single organization, you can create multiple environments. For more information,\nsee [About environments and environment groups](/apigee/docs/api-platform/fundamentals/environments-overview).\n\n\nThe following code shows an example overrides configuration where multiple environments are\ndefined. Note that environments\n**prod** and **test** have different host aliases: \n\n```actionscript-3\nnamespace: my-namespace\norg: my-organization\n...\nenvs:\n - name: test\n serviceAccountPaths:\n synchronizer: \"your_keypath/synchronizer-manager-service-account.json\n udca: \"your_keypath/analytic-agent-service-account.json\n\n - name: prod\n serviceAccountPaths:\n synchronizer: \"your_keypath/synchronizer-manager-service-account.json\n udca: \"your_keypath/analytic-agent-service-account.json\n...\n```\n- Add a `virtualhosts` property that maps its `routingRules` to the environment(s). \n\n ```\n virtualhosts:\n - name: default\n hostAliases: [\"api.example.com\"]\n sslCertPath: ./certs/fullchain.pem\n sslKeyPath: ./certs/privkey.pem\n routingRules:\n - env: test\n ``` \n\n ```\n virtualhosts:\n - name: external\n hostAliases: [\"apiprod.example.com\"]\n sslCertPath: ./certs/fullchain.pem\n sslKeyPath: ./certs/privkey.pem\n routingRules:\n - env: prod\n ```\n\n\n Suppose a proxy with the base path `/foo1` is deployed to environment\n **test**. You could call the proxy like this: \n\n ```\n curl -k https://api.example.com/foo1\n ```\n\n\n When this call hits the ingress, the ingress knows to send it to the message processor\n associated with the `test` environment, which handles the request.\n\n\n Similarly, if `foo1` is also deployed to the `prod` environment,\n you could make a proxy\n request like this, to the host alias `apiprod.mydomain.net`: \n\n ```\n curl -k https://apiprod.example.com/foo1\n ```\n\n\n And the call is routed by the ingress to the MP associated with that host.\n | **NOTE** On a request to an API proxy, the ingress compares the `Host` header of the incoming request to the list of host aliases to determine which virtual host handles the request. `curl` commands, browsers, and many other utilities automatically set the `Host` header with the domain of the request. If for any reason your app is not setting the `Host` header automatically, you must set it manually.\n\n\n **Antipattern**: Deploy all of your proxies to one hybrid environment.\n\n\n **Best practice** : Create multiple environments and deploy a limited number of proxies\n to each one. You can create routing rules that specify which environments\n to route specific API proxy basepaths to. For details, see [Virtual host configuration](/apigee/docs/hybrid/v1.2/base-path-routing).\n\n Limit the number of proxy deployments\n -------------------------------------\n\n\n For hybrid, the fact that many environments can share the same virtual host means\n that you must think carefully about how you manage your proxy deployments to any given\n environment. In hybrid, the best practice is to create multiple environments and deploy\n a limited number of proxies to each one.\n\n\n **How many proxies should you deploy to an environment?** There is not a set answer\n to this question; however, the following table provides general guidance on why it's a\n good idea to limit the number of proxies deployed to each environment and what you\n need to think about when managing proxy deployments:\n | **NOTE:** When deciding how many proxies to deploy to an environment, be sure to consider the product configuration limits described in [Limits](/apigee/docs/api-platform/reference/limits#hybrid).\n\n Enviroment configuration reference\n ----------------------------------\n\n\n For a complete list of environment configuration elements, see `envs` in the\n [Configuration property reference](/apigee/docs/hybrid/v1.2/config-prop-ref#envs).\n\n Working with environments\n -------------------------\n\n\n For more information about configuration, see the following topics:\n - [Creating new environments](/apigee/docs/hybrid/v1.2/environment-create)\n - [Deleting environments](/apigee/docs/hybrid/v1.2/environment-delete)\n - [Base path routing](/apigee/docs/hybrid/v1.2/base-path-routing)"]]
