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 <[email protected]>
AuthorDate: Fri May 20 19:32:18 2022 +0530
docs: update "Traffic" Plugin docs 3 (#7064)
Signed-off-by: Navendu Pottekkat <[email protected]>
---
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": {},
