-
Notifications
You must be signed in to change notification settings - Fork 41
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
4 changed files
with
197 additions
and
0 deletions.
There are no files selected for viewing
Binary file added
BIN
+325 KB
en/docs/assets/img/api-management/api-policies/webhook-site-request-mirroring.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
97 changes: 97 additions & 0 deletions
97
...create-and-attach-api-policies/mirror-request-filters/mirror-request-via-crs.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,97 @@ | ||
# Mirroring Requests via CRs | ||
|
||
This functionality enables request mirroring, where a request can be duplicated and sent to multiple backends for testing and monitoring. This guide explains how to enable request mirroring via Kubernetes CRs. | ||
|
||
### Step 1 - Get the CRs for the relevant API configuration | ||
|
||
Here, you can follow the steps in [Develop and Deploy a REST API via CRs](../../create-and-deploy-apis/rest/create-rest-api-using-crs.md) documentation and create the CRs to deploy an API from scratch. | ||
|
||
Alternatively, you can generate the CRs for a given apk-conf file using the steps as detailed in [this section]({{base_path}}/en/latest/api-management-overview/tools-for-api-development/#option-2-generate-k8s-custom-resources-using-config-generator-tool-and-deploy-the-api-using-kubernetes-client) | ||
|
||
### Step 2 - Add the header modification filters to the HTTPRoute CR | ||
|
||
Header modification can be done using an HTTPRoute filter as follows. | ||
|
||
First, create the relevant Backend CR to mirror the request to. A sample Backend CR is provided below. | ||
|
||
``` | ||
apiVersion: "dp.wso2.com/v1alpha1" | ||
kind: "Backend" | ||
metadata: | ||
name: "mirror-backend" | ||
spec: | ||
services: | ||
- host: "webhook.site" | ||
port: 443 | ||
basePath: "/30cd1472-d4ac-4440-ab8d-66fc0a789c7b" | ||
protocol: "https" | ||
``` | ||
|
||
Then you can refer to this CR in your HTTPRoute CR as follows. | ||
|
||
``` | ||
filters: | ||
- type: "RequestMirror" | ||
requestMirror: | ||
backendRef: | ||
group: "dp.wso2.com" | ||
kind: "Backend" | ||
name: "mirror-backend" | ||
``` | ||
|
||
The complete sample HTTPRoute is as follows. | ||
|
||
``` | ||
apiVersion: "gateway.networking.k8s.io/v1beta1" | ||
kind: "HTTPRoute" | ||
metadata: | ||
name: "production-httproute" | ||
spec: | ||
hostnames: | ||
- "default.gw.wso2.com" | ||
rules: | ||
- matches: | ||
- path: | ||
type: "RegularExpression" | ||
value: "/employee" | ||
method: "GET" | ||
filters: | ||
- type: "RequestMirror" | ||
requestMirror: | ||
backendRef: | ||
group: "dp.wso2.com" | ||
kind: "Backend" | ||
name: "mirror-backend" | ||
parentRefs: | ||
- group: "gateway.networking.k8s.io" | ||
kind: "Gateway" | ||
name: "wso2-apk-default" | ||
sectionName: "httpslistener" | ||
``` | ||
|
||
This policy mirrors the request to the production/sandbox endpoint, as well as the relevant mirror URL. | ||
|
||
### Step 3 - Deploy the API in APK | ||
|
||
You can deploy the API using the following command. Replace <namespace> with the correct namespace. | ||
``` | ||
kubectl apply -f . -n <namespace> | ||
``` | ||
|
||
### Step 4 - Generate an access token | ||
|
||
Follow the [Generate Access Token](../../../develop-and-deploy-api/security/generate-access-token.md) documentation to generate an access token. | ||
|
||
### Step 5 - Invoke the API | ||
|
||
You can invoke the API using the following command. | ||
|
||
``` | ||
curl --location 'https://default.gw.wso2.com:9095/employee/1.0/employee' \ | ||
--header 'Host: default.gw.wso2.com' \ | ||
--header 'Authorization: Bearer <accessToken> | ||
``` | ||
|
||
Once you have invoked the above, you can view the duplicated requests in the webhook.site page as follows. | ||
|
||
[![Request Mirroring](../../../assets/img/api-management/api-policies/webhook-site-request-mirroring.png)](../../../assets/img/api-management/api-policies/webhook-site-request-mirroring.png) |
90 changes: 90 additions & 0 deletions
90
...e-and-attach-api-policies/mirror-request-filters/mirror-request-via-rest-api.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,90 @@ | ||
# Mirroring Requests via APK Conf | ||
|
||
This functionality enables request mirroring, where a request can be duplicated and sent to multiple backends for testing and monitoring. This guide explains how to enable request mirroring via the APK-Conf file. | ||
|
||
### Step 1 - Get the API configuration | ||
|
||
Here, you can follow the steps in [Create an API](../../../get-started/quick-start-guide.md) documentation and save this content into a file named `EmployeeService.apk-conf`. You can use this apk-conf file for the rest of this guide. | ||
|
||
### Step 2 - Add the request mirroring policy to the apk-conf file | ||
|
||
A sample request mirror configuration is given below. | ||
For this guide, it's best to use a webhook.site URL for both the production and request mirroring endpoints to view the duplicate requests. Replace the `WEBHOOK_URL` with a relevant webhook url from the site `https://webhook.site`. Ensure that you keep this webpage open to view the incoming requests. | ||
|
||
``` | ||
- target: "/employee" | ||
verb: "GET" | ||
secured: false | ||
scopes: [] | ||
operationPolicies: | ||
request: | ||
- policyName: RequestMirror | ||
policyVersion: v1 | ||
parameters: | ||
urls: | ||
- `WEBHOOK_URL` | ||
``` | ||
|
||
This policy mirrors the request to the production/sandbox endpoint, as well as the relevant mirror URL. | ||
|
||
The complete apk-conf file with this configuration is given below. | ||
|
||
``` | ||
id: "header-modifier-api" | ||
name: "EmployeeServiceAPI" | ||
basePath: "/employee" | ||
version: "1.0" | ||
type: "REST" | ||
defaultVersion: false | ||
endpointConfigurations: | ||
production: | ||
endpoint: `WEBHOOK_URL` | ||
operations: | ||
- target: "/employee" | ||
verb: "GET" | ||
secured: false | ||
scopes: [] | ||
operationPolicies: | ||
request: | ||
- policyName: RequestMirror | ||
policyVersion: v1 | ||
parameters: | ||
urls: | ||
- `WEBHOOK_URL` | ||
- target: "/employee" | ||
verb: "POST" | ||
secured: true | ||
scopes: [] | ||
- target: "/employee/{employeeId}" | ||
verb: "PUT" | ||
secured: true | ||
scopes: [] | ||
- target: "/employee/{employeeId}" | ||
verb: "DELETE" | ||
secured: true | ||
scopes: [] | ||
``` | ||
|
||
### Step 3 - Deploy the API in APK | ||
|
||
Refer to the [Deploy the API in APK](../../../get-started/quick-start-guide.md#deploy-the-api-in-apk) to deploy the API using APK configuration. | ||
|
||
### Step 4 - Generate an access token | ||
|
||
Follow the [Generate Access Token](../../../develop-and-deploy-api/security/generate-access-token.md) documentation to generate an access token. | ||
|
||
### Step 5 - Invoke the API | ||
|
||
You can invoke the API using the following command. | ||
|
||
``` | ||
curl --location 'https://default.gw.wso2.com:9095/employee/1.0/employee' \ | ||
--header 'Host: default.gw.wso2.com' \ | ||
--header 'Authorization: Bearer <accessToken> | ||
``` | ||
|
||
Once you have invoked the above, you can view the duplicated requests in the webhook.site page as follows. | ||
|
||
[![Request Mirroring](../../../assets/img/api-management/api-policies/webhook-site-request-mirroring.png)](../../../assets/img/api-management/api-policies/webhook-site-request-mirroring.png) | ||
|
||
|
10 changes: 10 additions & 0 deletions
10
...cs/create-api/create-and-attach-api-policies/mirror-request-filters/overview.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
# Request Mirroring | ||
|
||
Request mirroring allows traffic to be duplicated and sent to additional backends for testing and monitoring purposes. This feature is particularly useful for scenarios where you want to test changes or monitor the behavior of your application under different conditions without affecting the primary production or sandbox environment. The Request Mirror filter can mirror requests to different backends apart from the primary backend defined in the production or sandbox endpoints. | ||
|
||
The current implementation operates in a “fire and forget” manner, and only the response from the primary endpoint will be returned. This allows for the assessment of changes and performance in a real-world environment without impacting the actual user experience. This method ensures that the production environment remains stable while providing insights into how updates or modifications would perform under actual load conditions. | ||
|
||
Request mirroring can be done in one of two ways. | ||
|
||
1. Via REST API (using the APK-Conf file). | ||
2. Via CRs. |