How to enable Enhanced per-environment proxy limits feature on your Apigee Hybrid Orgs
Overview
Up until recently, Apigee X & hybrid had an enforced limit of 50 proxies (more accurately, 50 proxies + 10 shared flows) that could be deployed to a single Apigee environment. This limit results in operational challenges which customers should not have to deal with. Based on customer feedback, the Apigee team recently introduced a feature known as “Enhanced per-environment proxy limits” (which we will subsequently refer to as Enhanced Proxy Limits or EPL). This feature enables Apigee to automatically instantiate new environment partitions as the number of proxies and shared flows grows beyond 50+10.
EPL, described here, was introduced by Apigee to allow customers to deploy more than 50 proxies in an environment. EPL reduces the operational overhead involved with manually managing proxy deployments across multiple environment partitions.
An EPL enabled Apigee environment is conceptually equivalent in behavior to a non-EPL environment in that it acts as the execution context for API proxies. The environment loads and runs a set of proxies and other environment resources. The diagram below shows the difference between proxies in a non-EPL org ( on the left with 3 environments gcp-env, gcp-env2, gcp-env3) and a EPL Org on the right with 1 environment (test-env)
Audience
Apigee hybrid is Google Cloud’s API management product which allows customers to deploy their API gateway in a Kubernetes cluster of their choice, located either on-premise or in the cloud.
This article describes the process for Apigee hybrid customers to convert their existing hybrid Orgs to use EPL enabled environments.
Conversion Execution
The conversion activity will be performed as a maintenance window activity in collaboration between customer engineers and Google Apigee Engineering team. In case of issues a support ticket to be raised by customers
Preparation
Preserving data from non-EPL Orgs
Some customers have in-house tools to preserve data and resources. Others make use of tools like apigeecli. It offers export commands for backing up Apigee artifacts.
What resources can be preserved from non-EPL Orgs?
Apigee resources that can be preserved from non-EPL Orgs include but are not limited to the following:
-
Apigee API Proxies: can be stored as source code in source repository and deployed using the Management API
-
Shared Flows: Similar to API proxies, you can store shared flow source code in Git and deploy them using the Management API.
-
Target Servers: Target server configurations can be defined in YAML files and deployed via the API.
-
Key Value Maps (KVMs): KVMs can be managed using the API, allowing you to store and deploy configuration data.
-
Developers and Apps: You can manage developer and app registrations with the API as well.
-
Environments and Environment Groups: You can manage the creation and configuration of environments.
-
Cache resources: Cache resources can be created and configured via the API.
-
Resource files: Javascript, python, and java resource files can be deployed.
Conversion from non-EPL Apigee Orgs (versions <= 1.13) to EPL Apigee Orgs (>=1.14.1)
Prerequisite
Customers must have a 2024 subscription license in place to enable EPL. Customers should work with the Apigee sales team to convert their subscription as needed.
Part 1 - Upgrading hybrid from 1.13 to 1.14.1
EPL is only available on version 1.14.1 or higher..
Step 1
Customers must follow the process for upgrading hybrid from 1.13 to 1.14.1 as described here.
If your Apigee hybrid version is lower than 1.13, refer to the below guidance:
If your Apigee hybrid release is 1.12, please refer here for guidance to upgrade from 1.12 to 1.13
If your Apigee hybrid release is 1.11, please refer here for guidance to upgrade from 1.11 to 1.12
Step 2
Enable analytics publisher access as described here.
Step 2b (Optional)
Customers using Java callout policies may observe issues with the Nimbus JOSE + JWT library. To address this, perform the steps described here.
Step 3
Customers may create a support ticket or contact their account team to have the EPL entitlement enabled on their hybrid Orgs. The customer must provide the project ID(s) to be updated.
Part 2 - Performing the Conversion
Please note this activity involves an interruption, and therefore it should be performed during a defined maintenance window.
Step 4
Undeploy proxies from the existing environments using the management UI or API, or using tools such as the epl preparation tool which is based on apigeecli. Please note; this step is optional for non-production hybrid orgs and recommended for production orgs
Step 5
Perform the following pre-check steps on the runtime components of the hybrid org ahead of the conversion activity. This ensures the components are running and healthy and encryption keys have no issues or errors surfaced -
-
Check general health of pods, and confirm all in running state and active pod count :
kubectl get pods -n apigee -
Validate runtime plane to ensure the pods are running and no errors in synchroniser pod log:
kubectl logs apigee-synchroniser -n apigee | grep error
- Validate Cassandra is healthy and running with no errors by checking for events popping up at the bottom of the describe command and also any errors in cassandra pod logs
kubectl describe pod apigee-cassandra-default-0 -n apigee
kubectl logs apigee-cassandra-default-0 -n apigee | grep error
- Run apigeeissues command to ensure no lingering pre-historic issues ( this leverages the automated issue surfacing capability in Apigee hybrid to identify issues:
kubectl -n apigee get apigeeissues
Step 6 (performed by Google Eng)
Apigee support and engineering teams will then execute the conversion process on the Org.
Step 7
After the conversion is completed,
Set the following property in the hybrid overrides file, as described here.
Apply helm chart upgrade on apigee org and virtualhost to activate/apply the enhanceProxy Limit property on the runtime
use kubectl to confirm the new Kubernetes pods for the environments are created, and contain the “-auto-” designation as shown below:
Step 8
Proceed to redeploy previously undeployed proxies. And where validate EPL by deploying >= 51 proxies to the environment(s) and confirm the deployments are successful.
Execute test calls (using curl or other tooling) to test proxy functionality.
