Question

I'm upgrading from 3.8 to the latest Apigee version, now called Apigee Edge, and setting up my DEV/TST instance

In my 3.8 install, I have a single non-Production instance supports 12 total development and test environments

• There are currently 6 DEV (DEV01, DEV02,…DEV06) and 6 TST (TST01, TST02,…TST06) instances to support current versions and in-development versions

• Each instance has copy of each API Proxy (“epapi”, “ewsapi” and “Token Service”) • Each instance has 3 virtual servers, one for each API Proxy

I had these in one domain in 3.8. I named the 12 deployed applications epapi_TST01, epapi_TST02,… epapi_TST06 and epapi_DEV01, epapi_DEV02,…epapi_DEV06

What is the best Organization and Environment strategy to implement this in Apigee Edge?

Was it helpful?

Solution

I would create 2 organizations, dev and tst to keep them logically separated. Inside each organization, you can have multiple environments. Example:

Organization: dev
Environments: dev1, dev2, dev3

Organization: tst
Environments: tst1, tst2, tst3

There are multiple ways you can approach the configuration of the environments to ensure proxies can be deployed to any of the environments interchangeably. Information below describes 2 ways you can leverage virtual host configurations.

NOTE: The below configurations are not self-service in the free offering of Apigee Edge and not likely to be changed away from the default offerings described here: http://apigee.com/docs/api-services/content/virtual-hosts. This information mostly pertains to on-premise deployments of Apigee Edge or paid accounts.

Virtual hosts are scoped at the environment level. This means you can have the same virtual host named default in different named environments. However, the configuration for the virtual host in each environment would have a different port and/or host alias configured. This will allow you to leave the ProxyEndpoint configuration the same for <BasePath> and <VirtualHost>.

Example of strategy using different virtual host ports:

  1. dev1:

    • vhost name: default
    • vhost port: 8080
  2. dev2:

    • vhost name: default
    • vhost port: 8081
  3. dev3:

    • vhost name: default
    • vhost port: 8082

Notice the name is the same so your <VirtualHost> configuration in the Apigee API proxy bundle will remain the same when you deploy to any of the dev environments. However, you would make a request into each environment as such:

dev1: http://dev.api.example.com:8080/basepath/resource
dev2: http://dev.api.example.com:8081/basepath/resource
dev3: http://dev.api.example.com:8082/basepath/resource

The above strategy will ensure you can deploy the same proxy config to multiple environments without having any conflicts when activating the API proxy. The proxy will listen on a different port, depending on environment. Then, you can choose to do different things with load balancers in front of Apigee to abstract the use of different ports for accessing the environments.

A similar solution can be obtained by using hostAliases config on the virtual host as well, using the HTTP header Host determine which environment the request routes to instead of different ports.

Example virtual host config using hostAliases example:

  1. dev1:

    • vhost name: default
    • vhost port: 80
    • hostAliases: ["dev1.api.example.com"]
  2. dev2:

    • vhost name: default
    • vhost port: 80
    • hostAliases: ["dev2.api.example.com"]
  3. dev3:

    • vhost name: default
    • vhost port: 80
    • hostAliases: ["dev3.api.example.com"]

When hostAliases are configured, the Host header value will be used to classify the request into the API proxy deployed in the proper environment. Example requests using this config:

dev1: http://dev1.api.example.com/basepath/resource
dev2: http://dev2.api.example.com/basepath/resource
dev3: http://dev3.api.example.com/basepath/resource

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top