You're viewing Apigee Edge documentation.
Go to the
Apigee X documentation. info
Throughout August and September 2015, we're migrating our Apigee Edge cloud routers and load balancers to NGINX (pronounced "Engine X"). NGINX, an open-source web server, provides even better performance and higher concurrency than our existing load balancers and routers.
What this means to our cloud customers
The bottom line is that this change should be transparent to you and requires no action on your part other than verification that your systems are working as expected. Following are descriptions of the steps we'll be taking, along with answers to some frequently asked questions.
Step 1 - Software update
We'll upgrade all routers to the new NGINX-based router by leveraging our phased deployment model to help ensure services aren’t impacted as a result of this activity.
Step 2 - Remove the load balancer tier in non-production environments
With the new NGINX router handling the load balancing functionality, we will begin the process of removing the existing load balancer tier in your non-production environment(s) first. Production load balancers will remain intact and unchanged during this step. Prior to the removal of existing load balancers, we will take an exhaustive approach towards ensuring traffic is working as expected. No action is required on your part to complete this step. However, you should report any issues to Apigee, and we'll work with you to resolve the issues prior to proceeding with Step 3.
Step 3 - Remove the load balancer tier in production environments
Upon successful completion of Step 2, we will determine a set of maintenance windows to remove the load balancer tier in production environment(s) using the same approach mentioned in Step 2 to ensure runtime API traffic continues to work as expected.
Changes to product functionality
Here are some changes to product functionality with the switch to NGINX.
Deprecated
The following properties are no longer supported in ProxyEndpoints:
- allow.http10
- allow.http11
- allow.http.method.*
- allow.POST.without.content.length
- allow.PUT.without.content.length
To work around this deprecation, see the following community article: https://community.apigee.com/questions/16134/proxy-endpoint-http-allow-method-properties-not-wo.html.
Frequently asked questions
Following are answers to some frequently asked questions about the NGINX migration.
During Step 1, the answer is ‘No’ since we aren’t touching the existing load balancers, which will not directly change any of the IPs serving traffic. However, given the nature of the Amazon Web Services (AWS) load balancing service, normal scaling rules apply, which means IPs may change as part of its scaling logic (existing functionality). This is why we do not recommend implementing Northbound allowlisting configurations with the Apigee Edge product suite. During Steps 2 and 3, there are allowlist implications with the removal of the load balancer and its associated IP addresses. As a result, we’ll coordinate closely with you during these steps to ensure a smooth transition by providing a new set of IP addresses for which to allow access.
No changes are required, assuming the origin servers are the target endpoint servers (servers called from the proxy bundle). This change is on the Northbound side of Apigee or the ingress point into Apigee.
No. Existing CNAME entries will continue to function as expected.
If you're using SSL, the initial step will not impact the existing SSL configuration. However, we will need to coordinate closely with you to ensure SSL is set up properly on the new router prior to proceeding with Steps 2 and 3.
Steps 2 and 3 will be delayed until SNI support is confirmed.
We do not expect any downtime. The changes will be implemented using our standard deployment model during our existing release windows.