You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@apisix.apache.org by ju...@apache.org on 2022/05/20 14:02:23 UTC
[apisix] branch master updated: docs: update "Traffic" Plugin docs 3 (#7064)
This is an automated email from the ASF dual-hosted git repository.
juzhiyuan pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/apisix.git
The following commit(s) were added to refs/heads/master by this push:
new e3a9eb6e2 docs: update "Traffic" Plugin docs 3 (#7064)
e3a9eb6e2 is described below
commit e3a9eb6e21e148d5913393228b1bac32a603481e
Author: Navendu Pottekkat <na...@gmail.com>
AuthorDate: Fri May 20 19:32:18 2022 +0530
docs: update "Traffic" Plugin docs 3 (#7064)
Signed-off-by: Navendu Pottekkat <na...@gmail.com>
---
docs/en/latest/plugins/client-control.md | 37 +++--
docs/en/latest/plugins/proxy-control.md | 36 +++--
docs/en/latest/plugins/request-id.md | 130 ++++++++---------
docs/en/latest/plugins/traffic-split.md | 243 ++++++++++++++++++-------------
4 files changed, 251 insertions(+), 195 deletions(-)
diff --git a/docs/en/latest/plugins/client-control.md b/docs/en/latest/plugins/client-control.md
index c78fe61ab..f142401eb 100644
--- a/docs/en/latest/plugins/client-control.md
+++ b/docs/en/latest/plugins/client-control.md
@@ -1,5 +1,11 @@
---
title: client-control
+keywords:
+ - APISIX
+ - Plugin
+ - Client Control
+ - client-control
+description: This document contains information about the Apache APISIX client-control Plugin.
---
<!--
@@ -23,20 +29,23 @@ title: client-control
## Description
-The `client-control` plugin dynamically controls the behavior of Nginx to
-handle the client request.
+The `client-control` Plugin can be used to dynamically control the behavior of Nginx to handle a client request.
-**This plugin requires APISIX to run on [APISIX-Base](../FAQ.md#how-do-i-build-the-apisix-base-environment?).**
+:::info IMPORTANT
+
+This Plugin requires APISIX to run on APISIX-Base. See [apisix-build-tools](https://github.com/api7/apisix-build-tools) for more info.
+
+:::
## Attributes
-| Name | Type | Requirement | Default | Valid | Description |
-| --------- | ------------- | ----------- | ---------- | ------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- |
-| max_body_size | integer | optional | | >= 0 | dynamically set the `client_max_body_size` directive |
+| Name | Type | Required | Valid values | Description |
+| ------------- | ------- | -------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------ |
+| max_body_size | integer | False | [0,...] | Dynamically set the [client_max_body_size](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) directive. |
-## How To Enable
+## Enabling the Plugin
-Here's an example, enable this plugin on the specified route:
+The example below enables the Plugin on a specific Route:
```shell
curl -i http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
@@ -56,13 +65,15 @@ curl -i http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f03433
}'
```
-## Test Plugin
+## Example usage
-Use curl to access:
+Now since you have configured the `max_body_size` to `1` above, you will get the following message when you make a request:
```shell
curl -i http://127.0.0.1:9080/index.html -d '123'
+```
+```shell
HTTP/1.1 413 Request Entity Too Large
...
<html>
@@ -76,9 +87,7 @@ HTTP/1.1 413 Request Entity Too Large
## Disable Plugin
-When you want to disable this plugin, it is very simple,
-you can delete the corresponding json configuration in the plugin configuration,
-no need to restart the service, it will take effect immediately:
+To disable the `client-control` Plugin, you can delete the corresponding JSON configuration from the Plugin configuration. APISIX will automatically reload, and you do not have to restart for this to take effect.
```shell
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
@@ -92,5 +101,3 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f1
}
}'
```
-
-This plugin has been disabled now. It works for other plugins.
diff --git a/docs/en/latest/plugins/proxy-control.md b/docs/en/latest/plugins/proxy-control.md
index 487447689..34229ca71 100644
--- a/docs/en/latest/plugins/proxy-control.md
+++ b/docs/en/latest/plugins/proxy-control.md
@@ -1,5 +1,11 @@
---
title: proxy-control
+keywords:
+ - APISIX
+ - Plugin
+ - Proxy Control
+ - proxy-control
+description: This document contains information about the Apache APISIX proxy-control Plugin.
---
<!--
@@ -23,19 +29,23 @@ title: proxy-control
## Description
-The `proxy-control` plugin dynamically controls the behavior of Nginx to proxy.
+The proxy-control Plugin dynamically controls the behavior of the Nginx proxy.
-**This plugin requires APISIX to run on [APISIX-Base](../FAQ.md#how-do-i-build-the-apisix-base-environment?).**
+:::info IMPORTANT
+
+This Plugin requires APISIX to run on APISIX-Base. See [apisix-build-tools](https://github.com/api7/apisix-build-tools) for more info.
+
+:::
## Attributes
-| Name | Type | Requirement | Default | Valid | Description |
-| --------- | ------------- | ----------- | ---------- | ------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- |
-| request_buffering | boolean | optional | true | | dynamically set the `proxy_request_buffering` directive |
+| Name | Type | Required | Default | Description |
+| ----------------- | ------- | -------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| request_buffering | boolean | False | true | When set to `true`, the Plugin dynamically sets the [proxy_request_buffering](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_request_buffering) directive. |
-## How To Enable
+## Enabling the Plugin
-Here's an example, enable this plugin on the specified route:
+The example below enables the Plugin on a specific Route:
```shell
curl -i http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
@@ -55,21 +65,19 @@ curl -i http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f03433
}'
```
-## Test Plugin
+## Example usage
-Use curl to access:
+The example below shows the use case of uploading a big file:
```shell
curl -i http://127.0.0.1:9080/upload -d @very_big_file
```
-It's expected not to find "a client request body is buffered to a temporary file" in the error log.
+It's expected to not find a message "a client request body is buffered to a temporary file" in the error log.
## Disable Plugin
-When you want to disable this plugin, it is very simple,
-you can delete the corresponding json configuration in the plugin configuration,
-no need to restart the service, it will take effect immediately:
+To disable the `proxy-control` Plugin, you can delete the corresponding JSON configuration from the Plugin configuration. APISIX will automatically reload and you do not have to restart for this to take effect.
```shell
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
@@ -83,5 +91,3 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f1
}
}'
```
-
-This plugin has been disabled now. It works for other plugins.
diff --git a/docs/en/latest/plugins/request-id.md b/docs/en/latest/plugins/request-id.md
index 4d8e58f8a..05505ac8d 100644
--- a/docs/en/latest/plugins/request-id.md
+++ b/docs/en/latest/plugins/request-id.md
@@ -1,5 +1,11 @@
---
title: request-id
+keywords:
+ - APISIX
+ - Plugin
+ - Request ID
+ - request-id
+description: This document contains information about the Apache APISIX request-id Plugin.
---
<!--
@@ -23,20 +29,60 @@ title: request-id
## Description
-`request-id` plugin adds a unique ID (UUID) to each request proxied through APISIX. This plugin can be used to track an
-API request. The plugin will not add a request id if the `header_name` is already present in the request.
+The `request-id` Plugin adds a unique ID to each request proxied through APISIX.
+
+This Plugin can be used to track API requests.
+
+:::note
+
+The Plugin will not add a unique ID if the request already has a header with the configured `header_name`.
+
+:::
## Attributes
-| Name | Type | Requirement | Default | Valid | Description |
-| ------------------- | ------- | ----------- | -------------- | ----- | -------------------------------------------------------------- |
-| header_name | string | optional | "X-Request-Id" | | Request ID header name |
-| include_in_response | boolean | optional | true | | Option to include the unique request ID in the response header |
-| algorithm | string | optional | "uuid" | ["uuid", "snowflake", "nanoid"] | ID generation algorithm |
+| Name | Type | Required | Default | Valid values | Description |
+| ------------------- | ------- | -------- | -------------- | ------------------------------- | ---------------------------------------------------------------------- |
+| header_name | string | False | "X-Request-Id" | | Header name for the unique request ID. |
+| include_in_response | boolean | False | true | | When set to `true`, adds the unique request ID in the response header. |
+| algorithm | string | False | "uuid" | ["uuid", "snowflake", "nanoid"] | Algorithm to use for generating the unique request ID. |
-## How To Enable
+### Using snowflake algorithm to generate unique ID
-Create a route and enable the request-id plugin on the route:
+To use the snowflake algorithm, you have to enable it first on your configuration file (`conf/config.yaml`):
+
+```yaml title="conf/config.yaml"
+plugin_attr:
+ request-id:
+ snowflake:
+ enable: true
+ snowflake_epoc: 1609459200000
+ data_machine_bits: 12
+ sequence_bits: 10
+ data_machine_ttl: 30
+ data_machine_interval: 10
+```
+
+:::caution WARNING
+
+Please read this documentation before deciding to use the snowflake algorithm. Once it is configured, you cannot arbitrarily change the configuration. Failure to do so may result in duplicate IDs.
+
+:::
+
+#### Attributes
+
+| Name | Type | Required | Default | Description |
+| --------------------- | ------- | -------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| enable | boolean | False | false | When set to `true`, enables the snowflake algorithm. |
+| snowflake_epoc | integer | False | 1609459200000 | Starting timestamp in milliseconds. Default is `2021-01-01T00:00:00Z` and supports to a 69 year time until `2090-09-0715:47:35Z`. |
+| data_machine_bits | integer | False | 12 | Maximum number of supported machines (processes) `1 << data_machine_bits`. Corresponds the set of `workIDs` and `dataCenterIDs` in the snowflake definition. Each process is associated to a unique ID. The maximum number of supported processes is `pow(2, data_machine_bits)`. So, for the default value of 12 bits, it is 4096. |
+| sequence_bits | integer | False | 10 | Maximum number of generated ID per millisecond per node `1 << sequence_bits`. Each process generates up to 1024 IDs per millisecond. |
+| data_machine_ttl | integer | False | 30 | Valid time in seconds of registration of `data_machine` in etcd. |
+| data_machine_interval | integer | False | 10 | Time in seconds between `data_machine` renewals in etcd. |
+
+## Enabling the Plugin
+
+The example below enables the Plugin on a specific Route:
```shell
curl http://127.0.0.1:9080/apisix/admin/routes/5 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
@@ -56,73 +102,23 @@ curl http://127.0.0.1:9080/apisix/admin/routes/5 -H 'X-API-KEY: edd1c9f034335f13
}'
```
-## Test Plugin
+## Example usage
+
+Once you have configured the Plugin as shown above, APISIX will create a unique ID for each request you make:
+
+```shell
+curl -i http://127.0.0.1:9080/hello
+```
```shell
-$ curl -i http://127.0.0.1:9080/hello
HTTP/1.1 200 OK
X-Request-Id: fe32076a-d0a5-49a6-a361-6c244c1df956
......
```
-### Use the snowflake algorithm to generate an ID
-
-> supports using the Snowflake algorithm to generate ID.
-> read the documentation first before deciding to use snowflake. Because once the configuration information is enabled, you can not arbitrarily adjust the configuration information. Failure to do so may result in duplicate ID being generated.
-
-The Snowflake algorithm is not enabled by default and needs to be configured in 'conf/config.yaml'.
-
-```yaml
-plugin_attr:
- request-id:
- snowflake:
- enable: true
- snowflake_epoc: 1609459200000
- data_machine_bits: 12
- sequence_bits: 10
- data_machine_ttl: 30
- data_machine_interval: 10
-```
-
-#### Configuration parameters
-
-| Name | Type | Requirement | Default | Valid | Description |
-| ------------------- | ------- | ------------- | -------------- | ------- | ------------------------------ |
-| enable | boolean | optional | false | | When set it to true, enable the snowflake algorithm. |
-| snowflake_epoc | integer | optional | 1609459200000 | | Start timestamp (in milliseconds) |
-| data_machine_bits | integer | optional | 12 | | Maximum number of supported machines (processes) `1 << data_machine_bits` |
-| sequence_bits | integer | optional | 10 | | Maximum number of generated ID per millisecond per node `1 << sequence_bits` |
-| data_machine_ttl | integer | optional | 30 | | Valid time of registration of 'data_machine' in 'etcd' (unit: seconds) |
-| data_machine_interval | integer | optional | 10 | | Time between 'data_machine' renewal in 'etcd' (unit: seconds) |
-
-- `snowflake_epoc` default start time is `2021-01-01T00:00:00Z`, and it can support `69 year` approximately to `2090-09-0715:47:35Z` according to the default configuration
-- `data_machine_bits` corresponds to the set of workIDs and datacEnteridd in the snowflake definition. The plug-in aslocates a unique ID to each process. Maximum number of supported processes is `pow(2, data_machine_bits)`. The default number of `12 bits` is up to `4096`.
-- `sequence_bits` defaults to `10 bits` and each process generates up to `1024` ID per millisecond.
-
-#### example
-
-> Snowflake supports flexible configuration to meet a wide variety of needs
-
-- Snowflake original configuration
-
-> - Start time 2014-10-20 T15:00:00.000z, accurate to milliseconds. It can last about 69 years
-> - supports up to `1024` processes
-> - Up to `4096` ID per millisecond per process
-
-```yaml
-plugin_attr:
- request-id:
- snowflake:
- enable: true
- snowflake_epoc: 1413817200000
- data_machine_bits: 10
- sequence_bits: 12
-```
-
## Disable Plugin
-Remove the corresponding json configuration in the plugin configuration to disable the `request-id`.
-APISIX plugins are hot-reloaded, therefore no need to restart APISIX.
+To disable the `request-id` Plugin, you can delete the corresponding JSON configuration from the Plugin configuration. APISIX will automatically reload and you do not have to restart for this to take effect.
```shell
curl http://127.0.0.1:9080/apisix/admin/routes/5 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
diff --git a/docs/en/latest/plugins/traffic-split.md b/docs/en/latest/plugins/traffic-split.md
index 3f8deadb2..89ba7e296 100644
--- a/docs/en/latest/plugins/traffic-split.md
+++ b/docs/en/latest/plugins/traffic-split.md
@@ -1,7 +1,12 @@
---
title: traffic-split
+keywords:
+ - APISIX
+ - Plugin
+ - Traffic Split
+ - traffic-split
+description: This document contains information about the Apache APISIX traffic-split Plugin.
---
-
<!--
#
# Licensed to the Apache Software Foundation (ASF) under one or more
@@ -23,50 +28,56 @@ title: traffic-split
## Description
-The traffic split plugin allows users to incrementally direct percentages of traffic between various upstreams.
+The `traffic-split` Plugin can be used to dynamically direct portions of traffic to various Upstream services.
+
+This is done by configuring `match`, which are custom rules for splitting traffic, and `weighted_upstreams` which is a set of Upstreams to direct traffic to.
+
+When a request is matched based on the `match` attribute configuration, it will be directed to the Upstreams based on their configured `weights`. You can also omit using the `match` attribute and direct all traffic based on `weighted_upstreams`.
+
+:::note
+
+The traffic ratio between Upstream services may be less accurate since round robin algorithm is used to direct traffic (especially when the state is reset).
-Note: The ratio between each upstream may not so accurate since the drawback of weighted round robin algorithm (especially when the wrr state is reset).
+:::
## Attributes
-| Name | Type | Requirement | Default | Valid | Description |
-| ------------------------------ | ------------- | ----------- | ------- | ------- | ---------------------------------------------------------------------------------------- |
-| rules.match | array[object] | optional | | | List of matching rules, by default the list is empty and the rule will be executed unconditionally. |
-| rules.match.vars | array[array] | optional | | | A list consisting of one or more {var, operator, val} elements, like this: {{var, operator, val}, {var, operator, val}, ...}}. For example: {"arg_name", "==", "json"}, which means that the current request parameter name is json. The var here is consistent with the naming of Nginx internal variables, so request_uri, host, etc. can also be used; for the operator part, the currently supported operators are ==, ~=, ~~, [...]
-| rules.weighted_upstreams | array[object] | optional | | | List of upstream configuration rules. |
-| weighted_upstreams.upstream_id | string/integer| optional | | | The upstream id is bound to the corresponding upstream. |
-| weighted_upstreams.upstream | object | optional | | | Upstream configuration information. |
-| upstream.type | enum | optional | roundrobin | [roundrobin, chash] | roundrobin supports weighted load, chash consistent hashing, the two are alternatives. |
-| upstream.hash_on | enum | optional | vars | | This option is only valid if the `type` is `chash`. Supported types `vars`(Nginx variables), `header`(custom header), `cookie`, `consumer`, `vars_combinations`, the default value is `vars`. For more details, please refer to [upstream](../admin-api.md#upstream) usage.|
-| upstream.key | string | optional | | | This option is only valid if the `type` is `chash`. Find the corresponding node `id` according to `hash_on` and `key`. For more details, please refer to [upstream](../admin-api.md#upstream) usage.|
-| upstream.nodes | object | optional | | | In the hash table, the key of the internal element is the list of upstream machine addresses, in the format of address + Port, where the address part can be an IP or a domain name, such as 192.168.1.100:80, foo.com:80, etc. value is the weight of the node. In particular, when the weight value is 0, it has special meaning, which usually means that the upstream node is invalid and never wants to be selected. |
-| upstream.timeout | object | optional | 15 | | Set the timeout period for connecting, sending and receiving messages (time unit: second, all default to 15 seconds). |
-| upstream.pass_host | enum | optional | "pass" | ["pass", "node", "rewrite"] | `pass`: Pass the client's host transparently to the upstream; `node`: Use the host configured in the node of `upstream`; `rewrite`: Use the value of the configuration `upstream_host`. |
-| upstream.name | string | optional | | | Identify the upstream service name, usage scenario, etc. |
-| upstream.upstream_host | string | optional | | | Only valid when pass_host is configured as rewrite. |
-| weighted_upstreams.weight | integer | optional | weight = 1 | | The traffic is divided according to the `weight` value, and the roundrobin algorithm is used to divide multiple `weight`. |
-
-Currently, in the configuration of `weighted_upstreams.upstream`, the unsupported fields are:
-service_name, discovery_type, checks, retries, retry_timeout, desc, scheme, labels, create_time and update_time. But you can use `weighted_upstreams.upstream_id` to bind the `upstream` object to achieve their functions.
-
-The traffic-split plugin is mainly composed of two parts: `match` and `weighted_upstreams`. `match` is a custom conditional rule, and `weighted_upstreams` is upstream configuration information. If you configure `match` and `weighted_upstreams` information, then after the `match` rule is verified, it will be based on the `weight` value in `weighted_upstreams`; the ratio of traffic between each upstream in the plugin will be guided, otherwise, all traffic will be directly Reach the `upstre [...]
-
-Note: 1. In `match`, the expression in vars is the relationship of `and`, and the relationship between multiple `vars` is the relationship of `or`. 2. In the weighted_upstreams field of the plugin, if there is a structure with only `weight`, it means the upstream traffic weight value on `route` or `service`. Such as:
-
-```json
-"weighted_upstreams": [
- ......
- {
- "weight": 2
- }
-]
-```
+| Name | Type | Required | Default | Valid values | Description |
+|--------------------------------|----------------|----------|------------|-----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| rules.match | array[object] | False | | | Rules to match for conditional traffic split. By default the list is empty and the traffic will be split unconditionally. |
+| rules.match.vars | array[array] | False | | | List of variables to match for filtering requests for conditional traffic split. It is in the format `{variable operator value}`. For example, `{"arg_name", "==", "json"}`. The variables here are consistent with Nginx internal variables. For details on supported operators, [lua-resty-expr](https://github.com/api7/lua-resty-expr#operator-list). |
+| rules.weighted_upstreams | array[object] | False | | | List of Upstream configurations. |
+| weighted_upstreams.upstream_id | string/integer | False | | | ID of the configured Upstream object. |
+| weighted_upstreams.upstream | object | False | | | Configuration of the Upstream. |
+| upstream.type | enum | False | roundrobin | [roundrobin, chash] | Type of mechanism to use for traffic splitting. `roundobin` supports weighted load and `chash` does consistent hashing. |
+| upstream.hash_on | enum | False | vars | | Only valid if the `type` is `chash`. Supported `vars` (Nginx variables), `header` (custom header), `cookie`, `consumer`, and `vars_combinations`. For more details, refer [Upstream](../admin-api.md#upstream). |
+| upstream.key | string | False | | | Only valid if the `type` is `chash`. Finds the corresponding node `id` according to `hash_on` and `key` values. For more details, refer [Upstream](../admin-api.md#upstream). |
+| upstream.nodes | object | False | | | IP addresses (with optional ports) of the Upstream nodes represented as a hash table. In the hash table, the key is the IP address and the value is the weight of the node. Setting `weight` to `0` means that a request is never forwarded to that node. |
+| upstream.timeout | object | False | 15 | | Timeout in seconds for connecting, sending and receiving messages. |
+| upstream.pass_host | enum | False | "pass" | ["pass", "node", "rewrite"] | Configures the host when the request is forwarded to the upstream. Can be one of `pass`, `node` or `rewrite`. `pass`- transparently passes the client's host to the Upstream. `node`- uses the host configured in the node of the Upstream. `rewrite`- Uses the value configured in `upstream_host`. |
+| upstream.name | string | False | | | Identifier for the Upstream for specifying service name, usage scenarios etc. |
+| upstream.upstream_host | string | False | | | Host of the Upstream request. Only valid when `pass_host` attribute is set to `rewrite`. |
+| weighted_upstreams.weight | integer | False | weight = 1 | | Weight to give to each Upstream node for splitting traffic. |
+
+:::note
+
+Some of the configuration fields supported in Upstream are not supported in weighted_upstreams.upstream. These fields are `service_name`, `discovery_type`, `checks`, `retries`, `retry_timeout`, `desc`, `scheme`, `labels`, `create_time`, and `update_time`.
-## How To Enable
+As a workaround, you can create an Upstream object and configure it in `weighted_upstreams.upstream_id` to achieve these functionalities.
-Create a route and enable the `traffic-split` plugin. When configuring the upstream information of the plugin, there are two ways:
+:::
-1. Configure upstream information through the `upstream` attribute in the plugin.
+:::info IMPORTANT
+
+In the `match` attribute configuration, the expression in variable is related as AND whereas multiple variables are related by OR.
+
+If only the `weight` attribute is configured, it corresponds to the weight of the Upstream service configured on the Route or Service. You can see this in action below.
+
+:::
+
+## Enabling the Plugin
+
+You can configure the Plugin on a Route as shown below:
```shell
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
@@ -109,7 +120,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
}'
```
-2. Use the `upstream_id` attribute in the plugin to bind upstream.
+Alternatively, you can configure `upstream_id` if you have already configured an Upstream object:
```shell
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
@@ -141,13 +152,27 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
}'
```
->Note: **1.** Use the `upstream_id` to bind the defined upstream, it can reuse upstream health detection, retry and other functions. **2.** Support the two configuration methods of `upstream` and `upstream_id` to be used together.
+:::tip
+
+Configure via `upstream_id` to reuse Upstream's health detection, retires, and other functions.
+
+:::
+
+:::note
-## Example
+You can use both `upstream` configuration and `upstream_id` configuration together.
-### Grayscale Release
+:::
-The `match` rule part is missing, and the traffic is split according to the `weight` value configured by the `weighted_upstreams` in the plugin. Divide `plugin's upstream` and `route's upstream` according to the traffic ratio of 3:2, of which 60% of the traffic reaches the upstream of the `1981` port in the plugin, and 40% of the traffic reaches the default `1980` port on the route Upstream.
+## Example usage
+
+The examples below shows different use cases for using the `traffic-split` Plugin.
+
+### Canary release
+
+This is the process of gradually rolling out a release by splitting an increasing percentage of traffic to the new release until all traffic is directed to the new release.
+
+To set this up, you can configure the `weight` attribute of your `weighted_upstreams` as shown below:
```shell
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
@@ -190,29 +215,37 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
}'
```
-**Test plugin:**
+Here, the weights are in the ratio 3:2 which means that 60% of the traffic reaches the Upstream service running on `:1981` (Plugin's Upstream) and 40% reaches the service running on `:1980` which is the Route's Upstream service.
-There are 5 requests, 3 requests hit the upstream of port 1981 of the plugin, and 2 requests hit the upstream of port 1980 of `route`.
+Now to test this configuration, if you make 5 requests, 3 will hit one service and 2 will hit the other:
+
+```shell
+curl http://127.0.0.1:9080/index.html -i
+```
```shell
-$ curl http://127.0.0.1:9080/index.html -i
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
hello 1980
+```
-$ curl http://127.0.0.1:9080/index.html -i
+```shell
+curl http://127.0.0.1:9080/index.html -i
+```
+
+```shell
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
world 1981
-
-......
```
-### Blue-green Release
+### Blue-green release
+
+In this setup, user traffic is shifted from the "green" (production) environment to the "blue" (staging) environment once the new changes have been tested and accepted within the blue environment.
-Get the `match` rule parameter through the request header (you can also get it through the request parameter or NGINX variable). After the `match` rule is matched, it means that all requests hit the upstream configured by the plugin, otherwise the request only hits the `route` configured upstream.
+To set this up, you can configure `match` rules based on the request headers as shown below:
```shell
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
@@ -253,12 +286,15 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
}'
```
-**Test plugin:**
+Here, if the request comes with a `release` header with value `new_release` it is directed to the new Upstream.
-The rule of `match` is matched, and all requests hit the upstream port 1981 configured by the plugin:
+Now if you send a request with `new_release` as the value for the `release` header, it will be directed to one Upstream and other requests will be directed to another Upstream.
+
+```shell
+curl http://127.0.0.1:9080/index.html -H 'release: new_release' -i
+```
```shell
-$ curl http://127.0.0.1:9080/index.html -H 'release: new_release' -i
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
......
@@ -266,10 +302,11 @@ Content-Type: text/html; charset=utf-8
world 1981
```
-The `match` rule fails to match, and all requests hit the 1980 port upstream configured on the `route`:
+```shell
+curl http://127.0.0.1:9080/index.html -H 'release: old_release' -i
+```
```shell
-$ curl http://127.0.0.1:9080/index.html -H 'release: old_release' -i
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
......
@@ -277,11 +314,11 @@ Content-Type: text/html; charset=utf-8
hello 1980
```
-### Custom Release
+### Custom release
-Multiple `vars` rules can be set in `match`. Multiple expressions in `vars` have an `and` relationship, and multiple `vars` rules have an `or` relationship; as long as one of the vars is required If the rule passes, the entire `match` passes.
+You can also make custom releases by configuring rules and setting weights.
-**Example 1: Only one `vars` rule is configured, and multiple expressions in `vars` are in the relationship of `and`. In `weighted_upstreams`, the traffic is divided into 3:2 according to the value of `weight`, of which only the part of the `weight` value represents the proportion of upstream on the `route`. When `match` fails to pass, all traffic will only hit the upstream on the route.**
+In the example below, only one `vars` rule is configured and the multiple expressions in the rule have an AND relationship. The weights are configured in 3:2 ratio and traffic not matching the `vars` will be redirected to the Upstream configured on the Route.
```shell
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
@@ -328,16 +365,13 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
}'
```
-The plugin sets the requested `match` rule and upstream with port `1981`, and the route has upstream with port `1980`.
-
-**Test plugin:**
-
->1. After the verification of the `match` rule is passed, 60% of the requests hit the upstream of the plugin port 1981, and 40% of the requests hit the upstream of the 1980 port of the `route`.
+After the rules are matched, 60% of the traffic hit the Upstream on port `1981` and 40% hit the one on `1980`.
-The match rule is successfully verified, and the upstream port of `1981` is hit.
+```shell
+curl 'http://127.0.0.1:9080/index.html?name=jack' -H 'user-id:30' -H 'apisix-key: hello' -i
+```
```shell
-$ curl 'http://127.0.0.1:9080/index.html?name=jack' -H 'user-id:30' -H 'apisix-key: hello' -i
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
......
@@ -345,10 +379,13 @@ Content-Type: text/html; charset=utf-8
world 1981
```
-The match rule fails to verify, and it hits the upstream of the default port of `1980`.
+If the rule fails to match, then the request is directed to the service on `1980`:
+
+```shell
+curl 'http://127.0.0.1:9080/index.html?name=jack' -H 'user-id:30' -H 'apisix-key: hello' -i
+```
```shell
-$ curl 'http://127.0.0.1:9080/index.html?name=jack' -H 'user-id:30' -H 'apisix-key: hello' -i
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
......
@@ -356,9 +393,7 @@ Content-Type: text/html; charset=utf-8
hello 1980
```
-After 5 requests, the service of port `1981` was hit 3 times, and the service of port `1980` was hit 2 times.
-
-**Example 2: Configure multiple `vars` rules. Multiple expressions in `vars` are `and` relationships, and multiple `vars` are `or` relationships. According to the `weight` value in `weighted_upstreams`, the traffic is divided into 3:2, where only the part of the `weight` value represents the proportion of upstream on the route. When `match` fails to pass, all traffic will only hit the upstream on the route.**
+In the example below, multiple `vars` rules are configured and they have an OR relationship.
```shell
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
@@ -412,14 +447,13 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
}'
```
-The plugin sets the requested `match` rule and the upstream port of `1981`, and the route has upstream port of `1980`.
+In the example below, both the `vars` rules are matched. After the rules are matched, 60% of the traffic is directed to the service on `1981` and 40% to the service on `1980`:
-**Test plugin:**
-
->1. The expressions of the two `vars` are matched successfully. After the `match` rule is verified, 60% of the requests hit the 1981 port upstream of the plugin, and 40% of the requests hit the 1980 port upstream of the `route`.
+```shell
+curl 'http://127.0.0.1:9080/index.html?name=jack&name2=rose' -H 'user-id:30' -H 'user-id2:22' -H 'apisix-key: hello' -H 'apisix-key2: world' -i
+```
```shell
-$ curl 'http://127.0.0.1:9080/index.html?name=jack&name2=rose' -H 'user-id:30' -H 'user-id2:22' -H 'apisix-key: hello' -H 'apisix-key2: world' -i
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
......
@@ -428,7 +462,10 @@ world 1981
```
```shell
-$ curl 'http://127.0.0.1:9080/index.html?name=jack&name2=rose' -H 'user-id:30' -H 'user-id2:22' -H 'apisix-key: hello' -H 'apisix-key2: world' -i
+curl 'http://127.0.0.1:9080/index.html?name=jack&name2=rose' -H 'user-id:30' -H 'user-id2:22' -H 'apisix-key: hello' -H 'apisix-key2: world' -i
+```
+
+```shell
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
......
@@ -436,12 +473,13 @@ Content-Type: text/html; charset=utf-8
hello 1980
```
-After 5 requests, the service of port `1981` was hit 3 times, and the service of port `1980` was hit 2 times.
+In the example below, the second `vars` rule fail to match. But since it is an OR relationship, the rules are matched and traffic is directed as configured:
->2. The second expression of `vars` failed to match (missing the `name2` request parameter). After the `match` rule was verified, 60% of the requests hit the plugin's 1981 port upstream, and 40% of the request traffic hits Go upstream to the 1980 port of `route`.
+```shell
+curl 'http://127.0.0.1:9080/index.html?name=jack' -H 'user-id:30' -H 'user-id2:22' -H 'apisix-key: hello' -H 'apisix-key2: world' -i
+```
```shell
-$ curl 'http://127.0.0.1:9080/index.html?name=jack' -H 'user-id:30' -H 'user-id2:22' -H 'apisix-key: hello' -H 'apisix-key2: world' -i
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
......
@@ -450,7 +488,10 @@ world 1981
```
```shell
-$ curl 'http://127.0.0.1:9080/index.html?name=jack' -H 'user-id:30' -H 'user-id2:22' -H 'apisix-key: hello' -H 'apisix-key2: world' -i
+curl 'http://127.0.0.1:9080/index.html?name=jack' -H 'user-id:30' -H 'user-id2:22' -H 'apisix-key: hello' -H 'apisix-key2: world' -i
+```
+
+```shell
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
......
@@ -458,12 +499,13 @@ Content-Type: text/html; charset=utf-8
hello 1980
```
-After 5 requests, the service of port `1981` was hit 3 times, and the service of port `1980` was hit 2 times.
+In the example below the required headers are missing and both the `vars` rules fail to match and the request is directed to the default Upstream of the Route (`1980`):
->3. The expression verification of two `vars` failed (missing the request parameters of `name` and `name2`), the `match` rule verification failed, and the response is the upstream data `hello 1980` of the default `route`.
+```shell
+curl 'http://127.0.0.1:9080/index.html?name=jack' -i
+```
```shell
-$ curl 'http://127.0.0.1:9080/index.html?name=jack' -i
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
......
@@ -471,13 +513,11 @@ Content-Type: text/html; charset=utf-8
hello 1980
```
-### Matching rules correspond to upstream
+### Multiple rules to correspond to Upstream
-By configuring multiple `rules`, we can achieve one-to-one correspondence between different matching rules and upstream.
+You can achieve one-to-one correspondence between rules and Upstream by configuring multiple `rules`:
-**Example:**
-
-When the request header `x-api-id` is equal to 1, it hits the upstream with port 1981; when `x-api-id` is equal to 2, it hits the upstream with port 1982; otherwise, it hits the upstream with port 1980 (the upstream response data is the corresponding port number).
+For example, when the request header `x-api-id` is equal to `1` it should be directed to Upstream on port `1981` and if it is equal to `2` it should be directed to Upstream on port `1982`. And in other cases, it should default to the Upstream on port `1980`. You can configure this as shown below:
```shell
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
@@ -540,35 +580,42 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
}'
```
-**Test plugin:**
+Now, when the request header `x-api-id` is equal to `1`, it will hit the Upstream on `1981`:
-The request header `x-api-id` is equal to 1, hitting the upstream with the 1981 port.
+```shell
+curl http://127.0.0.1:9080/hello -H 'x-api-id: 1'
+```
```shell
-$ curl http://127.0.0.1:9080/hello -H 'x-api-id: 1'
1981
```
-The request header `x-api-id` is equal to 2, hitting the upstream with the 1982 port.
+If request header `x-api-id` is equal to `2`, it will hit the Upstream on `1982`:
+
+```shell
+curl http://127.0.0.1:9080/hello -H 'x-api-id: 2'
+```
```shell
-$ curl http://127.0.0.1:9080/hello -H 'x-api-id: 2'
1982
```
-The request header `x-api-id` is equal to 3, the rule does not match, and it hits the upstream with port 1980.
+If request header `x-api-id` is equal to `3`, the rules do not match, and it will hit the Upstream on `1980`:
+
+```shell
+curl http://127.0.0.1:9080/hello -H 'x-api-id: 3'
+```
```shell
-$ curl http://127.0.0.1:9080/hello -H 'x-api-id: 3'
1980
```
## Disable Plugin
-When you want to remove the traffic-split plugin, it's very simple, just delete the corresponding json configuration in the plugin configuration, no need to restart the service, it will take effect immediately:
+To disable the `traffic-split` Plugin, you can delete the corresponding JSON configuration from the Plugin configuration. APISIX will automatically reload and you do not have to restart for this to take effect.
```shell
-$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
+curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
"uri": "/index.html",
"plugins": {},