https://github.com/api7/envoy-apisix
https://github.com/api7/envoy-apisix
Last synced: 10 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/api7/envoy-apisix
- Owner: api7
- License: apache-2.0
- Created: 2020-09-16T07:17:05.000Z (over 5 years ago)
- Default Branch: master
- Last Pushed: 2021-01-13T13:47:10.000Z (about 5 years ago)
- Last Synced: 2023-03-09T05:55:53.457Z (almost 3 years ago)
- Language: Lua
- Size: 490 KB
- Stars: 34
- Watchers: 9
- Forks: 6
- Open Issues: 14
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# About
A Lua framework that support [Apache APISIX](https://github.com/apache/apisix) plugins run directly in [Envoy](https://github.com/envoyproxy/envoy) Lua filter without modify Envoy.
# Example
1. clone the code
```shell
git clone https://github.com/api7/envoy-apisix.git
```
2. build and run the example
```shell
$ cd envoy-apisix/example
$ docker-compose pull
$ docker-compose up --build -d
```
3. test the example
```shell
$ curl 127.0.0.1:8000/foo/root.exe -i
HTTP/1.1 403 Forbidden
server: envoy
content-length: 0
date: Wed, 18 Nov 2020 00:08:54 GMT
```
# Plugins
* [redirect](docs/plugins/redirect.md): URI redirect.
* [referer-restriction](docs/plugins/referer-restriction.md): Referer whitelist.
* [uri-blocker](docs/plugins/uri-blocker.md): Block client request by URI.
* [ip-restriction](docs/plugins/ip-restriction.md): Restrict access by IP addresses.
# How does it work
We shield platform differences for the plugin layer. All interfaces that need to be used are abstracted in the underlying framework, which we call apisix.core, so that all plugins can run on Envoy and Apache APISIX at the same time.
# Plugin workflow
We use the example to show how the plugin runs:
## First step, read configuration
We configure through metadata to determine what plugins need to run on each route and what configuration is for each plugin.
In the example, we configured plugin `uri-blocker` for the route whose prefix is `/foo`, as well as the block rule of the plugin and the response status when a block is required.
## Second step, parse request
We encapsulated the client request data into `ctx` so that it can be used directly in the entire process.
## Third step, run the plugin
We determine whether we need to block this request by matching the configured rules and the obtained uri. If a block is needed, we call `respond` to directly respond, otherwise we let it go.