Wasm

APISIX supports Wasm plugins written with Proxy Wasm SDK.

Currently, only a few APIs are implemented. Please follow wasm-nginx-module to know the progress.

Programming model

The plugin supports the following concepts from Proxy Wasm:

  1.                     Wasm Virtual Machine
  2. ┌────────────────────────────────────────────────────────────────┐
  3. │      Your Plugin                                               │
  4. │          │                                                     │
  5. │          │ 1: 1                                                │
  6. │          │         1: N                                        │
  7. │      VMContext  ──────────  PluginContext                      │
  8. │                                           ╲ 1: N               │
  9. │                                            ╲                   │
  10. │                                             ╲  HttpContext     │
  11. │                                               (Http stream)    │
  12. └────────────────────────────────────────────────────────────────┘
  • All plugins run in the same Wasm VM, like the Lua plugin in the Lua VM
  • Each plugin has its own VMContext (the root ctx)
  • Each configured route/global rules has its own PluginContext (the plugin ctx). For example, if we have a service configuring with Wasm plugin, and two routes inherit from it, there will be two plugin ctxs.
  • Each HTTP request which hits the configuration will have its own HttpContext (the HTTP ctx). For example, if we configure both global rules and route, the HTTP request will have two HTTP ctxs, one for the plugin ctx from global rules and the other for the plugin ctx from route.

How to use

First of all, we need to define the plugin in config.yaml:

  1. wasm:
  2.   plugins:
  3.     - name: wasm_log # the name of the plugin
  4.       priority: 7999 # priority
  5.       file: t/wasm/log/main.go.wasm # the path of `.wasm` file
  6.       http_request_phase: access # default to "access", can be one of ["access", "rewrite"]

That’s all. Now you can use the wasm plugin as a regular plugin.

For example, enable this plugin on the specified route:

Wasm - 图1note

You can fetch the admin_key from config.yaml and save to an environment variable with the following command:

  1. admin_key=$(yq '.deployment.admin.admin_key[0].key' conf/config.yaml | sed 's/"//g')
  1. curl -i http://127.0.0.1:9180/apisix/admin/routes/1  -H "X-API-KEY: $admin_key" -X PUT -d '
  2. {
  3.     "uri": "/index.html",
  4.     "plugins": {
  5.          "wasm_log": {
  6.              "conf": "blahblah"
  7.          }
  8.     },
  9.     "upstream": {
  10.         "type": "roundrobin",
  11.         "nodes": {
  12.             "127.0.0.1:1980": 1
  13.         }
  14.     }
  15. }'

Attributes below can be configured in the plugin:

NameTypeRequirementDefaultValidDescription
confstringrequired!= “”the plugin ctx configuration which can be fetched via Proxy Wasm SDK

Here is the mapping between Proxy Wasm callbacks and APISIX’s phases:

  • proxy_on_configure: run once there is not PluginContext for the new configuration. For example, when the first request hits the route which has Wasm plugin configured.
  • proxy_on_http_request_headers: run in the access/rewrite phase, depends on the configuration of http_request_phase.
  • proxy_on_http_request_body: run in the same phase of proxy_on_http_request_headers. To run this callback, we need to set property wasm_process_req_body to non-empty value in proxy_on_http_request_headers. See t/wasm/request-body/main.go as an example.
  • proxy_on_http_response_headers: run in the header_filter phase.
  • proxy_on_http_response_body: run in the body_filter phase. To run this callback, we need to set property wasm_process_resp_body to non-empty value in proxy_on_http_response_headers. See t/wasm/response-rewrite/main.go as an example.

Example

We have reimplemented some Lua plugin via Wasm, under t/wasm/ of this repo:

  • fault-injection
  • forward-auth
  • response-rewrite