An environment provides an isolated context or "sandbox" for running API proxies. In a single organization, you can create multiple environments. For more information, see About environments and environment groups.
During a basic installation, you added an environment for testing. It's a best practice, however, to create multiple environments and to deploy a limited number of proxies to each one.
About virtual hosts and environments
Apigee hybrid uses Istio ingress gateways to handle incoming API traffic. The MART and runtime services are both configured with Istio ingress gateways to manage their connections that are exposed outside the cluster. This means, for example, that all HTTP and HTTPS requests to an API proxy are first handled by an Istio ingress gateway.
In hybrid, you create one or more environments and assign to each environment a host alias. The host alias is a DNS name. Incoming traffic to that DNS name is routed by the ingress to that environment. Internally, each environment is assigned to one and only one message processor, which does the work of processing proxy requests, applying policies and routing traffic to and from target services. Therefore, the host alias determines which message processor receives any given incoming request.
The following code shows an example configuration where multiple environments are defined. (Such configurations belong in your overrides file.) Note that environments dev1 and prod1 have different host aliases:
envs:
- name: dev1
hostAlias: "apitest.mydomain.net"
...
- name: prod1
hostAlias: "apiprod.mydomain.net"
...
Suppose a proxy with the base path /foo1 is deployed to environment
dev1. You could call the proxy like this:
curl -k https://apitest.mydomain.net/foo1
When this call hits the ingress, the ingress knows to send it to the message processor
associated with the dev1 environment, which handles the request.
Similarly, if foo1 is also deployed to the prod1 environment,
you could make a proxy
request like this, to the host alias apiprod.mydomain.net:
curl -k https://apiprod.mydomain.net/foo1
And the call is routed by the ingress to the MP associated with that host.
In summary, each environment that you create must have a host alias assigned to it. Each environment maps to one and only one message processor, and the host alias determines which message processor receives a given request.
Environments can share the same host alias
Apigee hybrid lets you create multiple environments that you can manage however you wish. For instance, you can create several dev environments, dev1, dev2, dev3, and so on, and map a single host alias to each one. Furthermore, you can deploy multiple proxies to each environment.
Antipattern: Deploy all of your proxies to one hybrid environment.
Best practice: Create multiple environments and deploy a limited number of proxies to each one. The technique for managing how hybrid routes proxy calls to the correct environment that share a host alias is called base path routing.
For example, in the following configuration, environments dev1 and dev2 share the same host alias:
envs:
- name: dev1
hostAlias: "apitest.mydomain.net"
...
- name: dev2
hostAlias: "apitest.mydomain.net"
...
When multiple environments share the same host alias, you must use the configuration technique called base path routing to map specific proxy base paths to specific environments. See base path routing for more information.
Limit the number of proxy deployments
For hybrid, the fact that many environments can share the same virtual host means that you must think carefully about how you manage your proxy deployments to any given environment. In hybrid, the best practice is to create multiple environments and deploy a limited number of proxies to each one.
How many proxies should you deploy to an environment? There is not a set answer to this question; however, the following table provides general guidance on why it's a good idea to limit the number of proxies deployed to each environment and what you need to think about when managing proxy deployments:
| Issue to consider | Description |
|---|---|
| Message processor boot-up time | There is a direct correlation between the amount of time a message processor (MP) takes to boot up and the number of proxies deployed to that MP. In an auto-scaling Kubernetes environment, an increase in boot time might be a problem. The more proxies that are deployed to the MP, the longer it will take for that MP to come up if it needs to be scaled or recreated. |
| Scaling performance | If you have several proxies deployed to an environment, and one of the proxies gets a lot of traffic so that it frequently auto-scales, all of the proxies in that environment will scale with it. The performance effect of scaling multiple proxies with a single high-traffic proxy might be a problem. |
| Noisy neighbor | If you have several proxies deployed to the same environment, and one proxy crashes, then all of the proxies in the environment will be taken down while the MPs restart. By limiting the number of proxies deployed to an environment, you minimize the impact of a single proxy crashing. |
Enviroment configuration reference
For a complete list of environment configuration elements, see envs in the
Configuration property reference.
Working with environments
For more information about configuration, see the following topics: