14 posts tagged with "APISIX"

Data manipulation methods for etcd data in apisix

May 25, 2022 · One min read

Student of JUST, Open Source Enthusiast.

这次的排错过程，主要是由我的 mentor 主导的，这边也给出了我导师的 github 账号，有兴趣的可以去交流一下哦。

tail -f logs/error.log

首先 static/img/2022-02-08-记录一次排错/image-20220208223242984.png

得到 etcd 中所有的路由信息

etcdctl get / --prefix --keys-only

tail 日志信息

tail -f logs/error.log

删除 etcd 中所有的 APISIX 路由数据

etcdctl del /apisix/routes --prefix

这边也记录一下 etcd 的官方关闭命令，其实也可以参考其他进程类关闭的方法：

kill `pgrep etcd`

来自于 etcd 官方链接

如何在 APISIX Ingress 中使用 go-plugin-runner

April 29, 2022 · 12 min read

CheverJohn

Student of JUST, Open Source Enthusiast.

[toc]

背景描述

当我在社区闲逛的时候，发现有一位用户对“如何在 APISIX Ingress 的环境下使用多语言插件”这个问题存在困惑。而我正好同时是 go-plugin-runner 的使用者，以及对 APISIX Ingress 项目有一点了解，于是便诞生了这篇文档。

How to run go plugin runner in APISIX Ingress

April 29, 2022 · 8 min read

CheverJohn

Student of JUST, Open Source Enthusiast.

Background Description

While wandering around the community, I found a user confused about "how to use multilingual plugins in APISIX Ingress environment". I happen to be a user of go-plugin-runner and have a little knowledge of the APISIX Ingress project, so this document was born.

记录一次复现

March 21, 2022 · 4 min read

CheverJohn

Student of JUST, Open Source Enthusiast.

I’m having trouble integrating openid-connect plugin with apisix gateway. When I have it enabled I end up getting no response from the API. Any idea what am I doing wrong or how to troubleshoot it? in slack

enabled openid-connect plugin

curl [http://127.0.0.1:9080/apisix/admin/routes/5](http://127.0.0.1:9080/apisix/admin/routes/5) -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
  "uri": "/get",
  "plugins": {
    "openid-connect": {
      "client_id": "my-client",
      "client_secret": "XXXX-XXXX-XXX",
      "discovery": "[https://my-auth-server/myapi/.well-known/openid-configuration](https://my-auth-server/myapi/.well-known/openid-configuration)",
      "access_token_in_authorization_header": true,
      "bearer_only": true
    }
  },
  "upstream": {
    "type": "roundrobin",
    "nodes": {
      "httpbin.org:80": 1
    }
  }
}'

request to the /get endpoint results in Empty reply from server

curl -i -X GET [http://127.0.0.1:9080/get](http://127.0.0.1:9080/get) -H "Host: httpbin.org" -H "Authorization: Bearer #####token####"

curl: (52) Empty reply from server

3. error.log has the following:

2022/03/18 21:23:09 [alert] 1#1: worker process 124 exited on signal 11
2022/03/18 21:23:09 [warn] 127#127: *723842 [lua] plugin.lua:172: load(): new plugins: {"uri-blocker":true,"fault-injection":true,"serverless-pre-function":true,"wolf-rbac":true,"datadog":true,"authz-keycloak":true,"skywalking-logger":true,"grpc-transcode":true,"splunk-hec-logging":true,"ext-plugin-pre-req":true,"ua-restriction":true,"ext-plugin-post-req":true,"response-rewrite":true,"key-auth":true,"grpc-web":true,"jwt-auth":true,"limit-count":true,"referer-restriction":true,"forward-auth":true,"udp-logger":true,"serverless-post-function":true,"basic-auth":true,"openwhisk":true,"cors":true,"limit-conn":true,"server-info":true,"azure-functions":true,"traffic-split":true,"request-validation":true,"google-cloud-logging":true,"rocketmq-logger":true,"sls-logger":true,"kafka-logger":true,"proxy-control":true,"proxy-rewrite":true,"syslog":true,"consumer-restriction":true,"echo":true,"http-logger":true,"prometheus":true,"redirect":true,"ip-restriction":true,"aws-lambda":true,"limit-req":true,"opa":true,"real-ip":true,"authz-casbin":true,"tcp-logger":true,"zipkin":true,"openid-connect":true,"gzip":true,"example-plugin":true,"request-id":true,"api-breaker":true,"hmac-auth":true,"ldap-auth":true,"proxy-mirror":true,"client-control":true,"proxy-cache":true}, context: init_worker_by_lua*
2022/03/18 21:23:09 [warn] 127#127: *723842 [lua] plugin.lua:222: load_stream(): new plugins: {"limit-conn":true,"ip-restriction":true,"mqtt-proxy":true}, context: init_worker_by_lua*

首先在我本地的 m1 上已安装的 APISIX 上看是否能重现bug。流程如下：

进入 APISIX，使用 ./bin/apisix start 命令启动 APISIX。
直接报错 401，这个属于正常情况，因为没有做权限认证，就应该是这样的报错。

换一种重现方式：使用 docker 镜像（arm 版本） https://hub.docker.com/r/apache/apisix/tags#:~:text=3ab0b2f76959-,linux,-/arm64 首先复制命令

apache/apisix/2.12.1-alpine/images/sha256-3ab0b2f76959f057790b35adf2438fea5ae6cbc8c994aff159bf17d72654d857?context=explore

docker pull apache/apisix:2.12.1-alpine@sha256:3ab0b2f76959f057790b35adf2438fea5ae6cbc8c994aff159bf17d72654d857

docker pull nginx:stable-perl@sha256:3ab0b2f76959f057790b35adf2438fea5ae6cbc8c994aff159bf17d72654d857

docker pull nginx:stable-perl@sha256:3ab0b2f76959f057790b35adf2438fea5ae6cbc8c994aff159bf17d72654d857

docker run -itd --rm --name=dev-apisx -v /srv/[github.com/apache/apisix/conf/config.yaml:/usr/local/apisix/conf/config.yaml](http://github.com/apache/apisix/conf/config.yaml:/usr/local/apisix/conf/config.yaml) apache/apisix

修改：docker tag c8202912bb3a apache/apisix:dev 这个命令用于运行apisix，记住这边得先把 APISIX镜像的tag改了哈改成 apache/apisix:dev

docker run -itd --rm --name=dev-apisx -p 9080:9080 -v /Users/cheverjohn/home/api7/dev_cj/apisix/conf/config.yaml:/usr/local/apisix/conf/config.yaml apache/apisix:dev

上面的这条命令要好好理解，这是最终的状态。

![[dockerdestop.png]]

这边还有一个 etcd 的映射端口更改。

这一块需要思考到的地方有， etcd 由于我是本地使用 brew 命令安装的，所以它会默认由brew 守护开启，也就是无论你开关机它都会启动。这个需要额外关闭。我是通过这条命令看到的

brew info etcd

看到可以这样关闭 etcd

brew services stop etcd

ETCD_UNSUPPORTED_ARCH="arm64" /opt/homebrew/opt/etcd/bin/etcd

ETCD_UNSUPPORTED_ARCH="arm64" /opt/homebrew/opt/etcd/bin/etcd --listen-client-urls=http://0.0.0.0:2379

ETCD_UNSUPPORTED_ARCH="arm64" /opt/homebrew/opt/etcd/bin/etcd --listen-client-urls http://0.0.0.0:2379 --advertise-client-urls http://0.0.0.0:2379 --listen-peer-urls http://0.0.0.0:2380 --initial-advertise-peer-urls http://0.0.0.0:2380

其中为了确认 etcd 的安装位置，他的端口状态，会一直使用到以下命令：

lsof -i:2379

得出运行 2379 端口的进程。

lsof -p PID

根据 PID 得到进程的具体位置，根据这个操作确认到进程的具体位置。

这里边超哥贡献了一些命令：

history | grep etcd

curl http://192.168.28.179:2379/version

期望通过这个配置，判断是否正常启动好 etcd。

还有命令：

docker logs aae1b3434ce4

这里边的后边的数字其实是 container ID

此处码一下，希望了解清楚以下两条命令的区别：

docker ps

docker ps -a

下面的代码也要了解清楚各种参数的意思：

docker run -itd --name=dev-apisx -v /Users/cheverjohn/home/api7/dev_cj/apisix/conf/config.yaml:/usr/local/apisix/conf/config.yaml apache/apisix:dev

查看日志命令

tail -f error.log

有时候我也看到会连续执行两条命令：

docker stop 9b17b3bbb061

docker rm 9b17b3bbb061

docker rmi c8202912bb3a

检查： docker inspect apache/apisix:dev

这边配置好 etcd 和 APISIX 之后，开始 curl 请求 ifconfig | grep 192.168 找到了：curl http://192.168.101.161:2379/version

关于ubuntu安装部署APISIX以及测试的想法

March 15, 2022 · 3 min read

CheverJohn

Student of JUST, Open Source Enthusiast.

首先上我最终跑通一个测试的例子：

Installation

按照正常的操作，我先 clone fork 下来的仓库，然后安装相关依赖，这个我还是根据了 APISIX 2.10 的文档版本里讲一系列步骤做的。千万注意，这个方法已经老套了，你应该用下面介绍的最新脚本的方法，如图所示：

ubuntu 安装依赖

Make deps

然后这个地方坑的就来了，在最新的github 脚本里边，是有下面的这行命令的，也就是文档内容跟最新脚本内容是不相符的。这个需要我及时去进行修改。

sudo apt-get install -y git openresty curl openresty-openssl111-dev make gcc libpcre3 libpcre3-dev libldap2-dev unzip

事实上运行了上面的命令之后，就不会有什么找不到 ldap 之类的问题了，淦

然后我们解决了 make deps 的问题。接下来就直接是 make install，一切正常。

开始测试部分

首先根据官方的命令安装

第一是安装 perl 的包管理工具 cpanminus：

apt install cpanminus

第二然后通过 cpanm 安装 test-nginx 的依赖。

sudo cpanm --notest Test::Nginx IPC::Run > build.log 2>&1 || (cat build.log && exit 1)

首先将 APISIX 加入到框架中去

export PERL5LIB=.:$PERL5LIB:/home/api7/dev_cj/apisix

然后配置OpenResty 中的 NGINX 的环境变量配置

export PATH=/usr/local/openresty/nginx/sbin:$PATH

如果你遇到这样的问题

你就需要下载子模块：

git submodule update --init --recursive

请注意，当我仅运行

apisix start

and

nohup etcd &

之后，便能够成功运行，如图

虚拟机经历了很多

跑通测试框架且解决多进程问题

February 15, 2022 · 3 min read

CheverJohn

Student of JUST, Open Source Enthusiast.

我的问题描述

无法跑测试（APISIX 的）；
Nginx 会启动多个进程。

然后我复现的命令如下可见

export PERL5LIB=.:$PERL5LIB:/home/api7/dev_cj/apisix

export PATH=/usr/local/openresty/nginx/sbin:$PATH

prove ....../example.t

然后就出现一个问题端口占用

解决办法：当跑测试的时候，因为 APISIX 会启动upstream 端口，所以如果不关闭 openresty 的阿虎，就会遇到端口占用的问题。

然后我运行

netstat -nultp

复现了多个 nginx 进程的问题，

运行

ps -ef | grep nginx

发现了多个进程，意识到我的 openresty 还开着。

关闭 openresty

openresty -s stop

然后利用kill -9 杀掉了很多个进程。这边我采取了笨方法，一个进程一个进程杀掉了，可以不用 -9 ，这边 remark 一下。

kill -9 76007
kill -9 76008
kill -9 76009

APISIX 重启了一切正常

总结

ps -ef | grep nginx

这个命令还是要记记牢。

2022年 3月 8日

细节问题：没想到已经跑通测试的我，还是在新的开发机上跑测试框架遇到了问题。本次主要问题在于一个安装包问题，所以说环境是真的无语，还是得设置到代理啊。我设置了git 的代理解决了问题，详情方法，请参考 link ，我的主要疏忽在于，没注意端口，因为之前实在 Windows 本上做开发的，用的是 v2ray，端口是 10808，没曾想就照着走错了，离谱啊。此处 mark 一下，需要注意。

然后还有一个点需要注意一下，make deps 和 LUAROCKS_SERVER=https://luarocks.cn make deps 可以混着用，over。

放上遇到问题的图：

我又遇到问题啦呜呜呜

放上解决问题之后的图片：

解决问题就是爽啊！

关于APISIX测试框架我想说

February 15, 2022 · 2 min read

CheverJohn

Student of JUST, Open Source Enthusiast.

本篇文章主要针对 APISIX 的插件开发，以及核心开发，配置相应的测试框架，并跑通。

首先我通过 git clone 将 APISIX 源码仓库 clone 到本地。

然后搭配另外安装的 etcd 和 OpenResty，将一些例子请求跑起来。

然后就开始我们主要的配置测试框架过程。这边对于 APISIX、OpenResty、NGINX 皆可用。

首先如果想要获取对测试框架的基本知识，请浏览此链接，这对接下来的很多操作都很有帮助。

然后还有一些基本的经验可以学习。

先配置

首先将 APISIX 加入到框架中去

export PERL5LIB=.:$PERL5LIB:/home/api7/dev_cj/apisix

然后配置OpenResty 中的 NGINX 的环境变量配置

export PATH=/usr/local/openresty/nginx/sbin:$PATH

小知识

--- ONLY

在测试案例中加入 --- ONLY or --- SKIP 可以仅测试一个案例，可以大大加快速度。

ONLY只做一个测试例子

--- SKIP

跳过这一个测试案例，其他都跑

小知识

这边有一个专属于 APISIX 的小知识，跑测试前要下载子模块（submoudle）。

git submodule update --init --recursive

如果你跑测试的时候遇到这样的报错：缺依赖

只需要运行上面的命令即可

解决一个issue的过程

February 10, 2022 · 14 min read

CheverJohn

Student of JUST, Open Source Enthusiast.

本篇博客，详细讲述一个 issues 的解决过程，享受解决问题的快乐吧:)

起源

当我浏览我关注的 Apache APISIX 社区的时候，发现了一个非常符合我的 issues。这是一个关于 GraphQL 的issues，正好我有关于 GraphQL 的了解，便想着接下这个 issues 以锻炼自己的能力叭。

接下来讲述发现的过程：

issue 详情

看到 issue （标题为 bug: ctx.lua#59 parse_graphql(ctx) #6266 )，我刚开始看 issues 的时候，还以为是这位老哥不会使用 APISIX ，居然在发送请求的时候漏掉 -X POST （没想到最后还是我格局小了）

首先看 issue 的描述

use whole request body to parse graphql will get parse error. graphql request body is json , example :{"query":"query{getUser{name age}}","variables":null},
{"query":
    "query{
        getUser{
            name age
        }
    }",
    "variables":null
}
not query{getUser{name age}}
query{
    getUser{
        name 
        age
    }
}

我简单描述一下，这个问题就是说当他使用请求体为 json 的请求时，出现 parse error 的问题。

这边还是要抽自己一下，他都明确说了，没有用 query 的方式，我还在后边用我的 query 跟他解释，离谱，我该反省~

curl -X POST http://127.0.0.1:9080/graphql -d '
query getUser {
    owner {
        name
    }
    repo {
        created
    }
}'

他给出了自己的环境配置

Environment

apisix version (cmd: apisix version): apache/apisix:2.12.0-alpine
OS (cmd: uname -a): docker
OpenResty / Nginx version (cmd: nginx -V or openresty -V): null
etcd version, if have (cmd: run curl http://127.0.0.1:9090/v1/server_info to get the info from server-info API): bitnami/etcd:3.4.15
apisix-dashboard version, if have: apache/apisix-dashboard:2.10.1-alpine

然后他给出了自己的复现过程

Reproduce

define graphql

query {
    getUser:User
}

type User{
    name:String
    age:String
}

add route

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "methods": ["POST"],
    "uri": "/graphql",
    "vars": [
        ["graphql_operation", "==", "query"],
        ["graphql_name", "==", "getUser"]
    ],
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1980": 1
        }
    }
}'

perform graphql request by curl

curl 'http://127.0.0.1:9080/graphql' \
  -H 'Content-Type: text/plain;charset=UTF-8' \
  -H 'Accept: */*' \
  --data-raw '{"query":"query getUser{getUser{name age}}","variables":null}' \
  --compressed

上方请求化简

curl 'http://127.0.0.1:9080/graphql' \
  -H 'Content-Type: text/plain;charset=UTF-8' \
  -H 'Accept: */*' \
  --data-raw '
  {"query":"query getUser {
                getUser {
                    name 
                    age
                }
            }",
            "variables":null
  }' \
  --compressed

Actual result

HTTP/1.1 404 Not Found Date: Tue, 08 Feb 2022 07:39:16 GMT Content-Type: text/plain; charset=utf-8 Transfer-Encoding: chunked Connection: keep-alive

{ "error_msg": "404 Route Not Found" }

Error log

2022/02/08 07:39:16 [error] 45#45: *1085159 [lua] ctx.lua:80: get_parsed_graphql(): failed to parse graphql: Syntax error near line 1 body:

Expected result

success

issue 提出者认为

一个正常的 graphql 请求应该是这样的：

curl 'https://api.mocki.io/v2/c4d7a195/graphql' \
  -H 'authority: api.mocki.io' \
  -H 'accept: */*' \
  -H 'content-type: application/json' \
  -H 'origin: https://api.mocki.io' \
  --data-raw '{"operationName":"getUser","variables":{},"query":"query getUser {\n  user(id: \"4dc70521-22bb-4396-b37a-4a927c66d43b\") {\n    id\n    email\n    name\n  }\n}\n"}' \
  --compressed

会返回

{
  "data": {
    "user": {
      "id": "Hello World",
      "email": "Hello World",
      "name": "Hello World"
    }
  }
}

而且

A standard GraphQL POST request should use the application/json content type, and include a JSON-encoded body of the following form:

{
  "query": "...",
  "operationName": "...",
  "variables": { "myVariable": "someValue", ... }
}

see official graphql document, https://graphql.org/learn/serving-over-http/#post-request

and --data will perform request with POST method ,see curl document

A standard GraphQL POST request should use the application/json content type, and include a JSON-encoded body of the following form:

{
  "query": "...",
  "operationName": "...",
  "variables": { "myVariable": "someValue", ... }
}

see official graphql document, https://graphql.org/learn/serving-over-http/#post-request

and --data will perform request with POST method ,see curl document

对于 curl 工具的使用

$ curl --help
Usage: curl [options...] <url>
 -d, --data <data>   **HTTP POST data**
...

use -v to print verbose log

curl -v 'https://api.mocki.io/v2/c4d7a195/graphql' \
  -H 'authority: api.mocki.io' \
  -H 'accept: */*' \
  -H 'content-type: application/json' \
  -H 'origin: https://api.mocki.io' \
  --data-raw '{"operationName":"getUser","variables":{},"query":"query getUser {\n  user(id: \"4dc70521-22bb-4396-b37a-4a927c66d43b\") {\n    id\n    email\n    name\n  }\n}\n"}' \
  --compressed

issue 提出者原话：
it will print something like this > POST /v2/c4d7a195/graphql HTTP/2, thought i'm not use -X POST
sorry, I'm try to discuss about how APISIX deal with graphql request. it seems that the mock GraphQL data of APISIX is not a standard GraphQL request.

得出结论: mock GraphQL data of APISIX is not a standard GraphQL request.

评估需求

看过这个 issue 之后，思考了 APISIX 中的 GraphQL 到底是什么。或许 APISIX 支持的是假的 GraphQL？思考明白之后才能动手做。

之前应该是只做了这个：If the "application/graphql" Content-Type header is present, treat the HTTP POST body contents as the GraphQL query string.

curl -v -H "Content-Type: application/graphql" -d "{ hello }"  "localhost:3000/graphql" 

需要指定 content-type 了

所以我对于这个 issue 的结论就是：需要 fix 三部分

解决 POST JSON的问题，让 APISIX 支持 JSON 格式的 POST；
支持 GET 。

其实根据这篇文档。

一个标准的 GraphQL POST 请求就应该使用 application/json content type, 然后包括 json 格式的body在里边。

但对于目前的 GraphQL 在 APISIX 中的应用来讲，是可以通过 "application/graphql" Content-Type 的形式绕过的。参考文档中的这句：

If the "application/graphql" Content-Type header is present, treat the HTTP POST body contents as the GraphQL query string.

重点：点睛之笔

https://graphql.org/learn/serving-over-http/ 参考官方的文档，实际上 APISIX 现在处理的场景是

If the "application/graphql" Content-Type header is present, treat the HTTP POST body contents as the GraphQL query string.

APISIX 暂时只能够实现 GraphQL query 的功能。

我们需要 json 格式的功能最好还要加上 “GET” 的功能。

可参考的 GraphQL 官方文档

https://graphql.org/learn/serving-over-http/#post-request

评估工作情况

第一次评估

我认为我需要修改 graphql-lua 库中的 parse.lua

curl 'http://127.0.0.1:9080/graphql' \
  -H 'Content-Type: text/plain;charset=UTF-8' \
  -H 'Accept: */*' \
  -d '{"query":"query getUser{getUser{name age}}","variables":null}' \
  --compressed

源码分析

找到 GraphQL 在 APISIX 中的代码，主要有关系的只有apisix/core/ctx.lua 中有相关代码。其实 APISIX 依靠的

--
-- Licensed to the Apache Software Foundation (ASF) under one or more
-- contributor license agreements.  See the NOTICE file distributed with
-- this work for additional information regarding copyright ownership.
-- The ASF licenses this file to You under the Apache License, Version 2.0
-- (the "License"); you may not use this file except in compliance with
-- the License.  You may obtain a copy of the License at
--
--     http://www.apache.org/licenses/LICENSE-2.0
--
-- Unless required by applicable law or agreed to in writing, software
-- distributed under the License is distributed on an "AS IS" BASIS,
-- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-- See the License for the specific language governing permissions and
-- limitations under the License.
--
local core_str     = require("apisix.core.string")
local core_tab     = require("apisix.core.table")
local request      = require("apisix.core.request")
local log          = require("apisix.core.log")
local config_local = require("apisix.core.config_local")
local tablepool    = require("tablepool")
local get_var      = require("resty.ngxvar").fetch
local get_request  = require("resty.ngxvar").request
local ck           = require "resty.cookie"
local gq_parse     = require("graphql").parse
local setmetatable = setmetatable
local sub_str      = string.sub
local ngx          = ngx
local ngx_var      = ngx.var
local re_gsub      = ngx.re.gsub
local ipairs       = ipairs
local type         = type
local error        = error
local pcall        = pcall


local _M = {version = 0.2}
local GRAPHQL_DEFAULT_MAX_SIZE = 1048576               -- 1MiB


local function parse_graphql(ctx)
    local local_conf, err = config_local.local_conf()
    if not local_conf then
        return nil, "failed to get local conf: " .. err
    end

    local max_size = GRAPHQL_DEFAULT_MAX_SIZE
    local size = core_tab.try_read_attr(local_conf, "graphql", "max_size")
    if size then
        max_size = size
    end

    local body, err = request.get_body(max_size, ctx)
    if not body then
        return nil, "failed to read graphql body: " .. err
    end

    local ok, res = pcall(gq_parse, body)
    if not ok then
        return nil, "failed to parse graphql: " .. res .. " body: " .. body
    end

    if #res.definitions == 0 then
        return nil, "empty graphql: " .. body
    end

    return res
end


local function get_parsed_graphql()
    local ctx = ngx.ctx.api_ctx
    if ctx._graphql then
        return ctx._graphql
    end

    local res, err = parse_graphql(ctx)
    if not res then
        log.error(err)
        ctx._graphql = {}
        return ctx._graphql
    end

    if #res.definitions > 1 then
        log.warn("Multiple operations are not supported.",
                    "Only the first one is handled")
    end

    local def = res.definitions[1]
    local fields = def.selectionSet.selections
    local root_fields = core_tab.new(#fields, 0)
    for i, f in ipairs(fields) do
        root_fields[i] = f.name.value
    end

    local name = ""
    if def.name and def.name.value then
        name = def.name.value
    end

    ctx._graphql = {
        name = name,
        operation = def.operation,
        root_fields = root_fields,
    }

    return ctx._graphql
end


do
    -- 获取特殊var的方法
    local var_methods = {
        method = ngx.req.get_method,
        -- ref: https://github.com/cloudflare/lua-resty-cookie
        cookie = function ()
            if ngx.var.http_cookie then
                return ck:new()
            end
        end
    }

    local no_cacheable_var_names = {
        -- var.args should not be cached as it can be changed via set_uri_args
        args = true,
        is_args = true,
    }

    local ngx_var_names = {
        upstream_scheme            = true,
        upstream_host              = true,
        upstream_upgrade           = true,
        upstream_connection        = true,
        upstream_uri               = true,

        upstream_mirror_host       = true,

        upstream_cache_zone        = true,
        upstream_cache_zone_info   = true,
        upstream_no_cache          = true,
        upstream_cache_key         = true,
        upstream_cache_bypass      = true,

        var_x_forwarded_proto = true,
    }

    local mt = {
        -- 重载 hash 元方法
        -- t 是 self
        __index = function(t, key)
            
            -- 若 cache table 存在直接返回
            local cached = t._cache[key]
            if cached ~= nil then
                return cached
            end

            if type(key) ~= "string" then
                error("invalid argument, expect string value", 2)
            end

            local val
            -- 如果是特殊类型, 使用特定方法获取
            local method = var_methods[key]
            if method then
                val = method()

            elseif core_str.has_prefix(key, "cookie_") then
                -- 通过 var_methods 访问到 resty.cookie
                local cookie = t.cookie
                if cookie then
                    local err
                    val, err = cookie:get(sub_str(key, 8))
                    if err then
                        log.warn("failed to fetch cookie value by key: ",
                                 key, " error: ", err)
                    end
                end

            elseif core_str.has_prefix(key, "arg_") then
                local arg_key = sub_str(key, 5)
                local args = request.get_uri_args()[arg_key]
                if args then
                    if type(args) == "table" then
                        val = args[1]
                    else
                        val = args
                    end
                end

            elseif core_str.has_prefix(key, "http_") then
                key = key:lower()
                key = re_gsub(key, "-", "_", "jo")
                -- 最终通过 ngx.var 获取
                val = get_var(key, t._request)

            elseif core_str.has_prefix(key, "graphql_") then
                -- trim the "graphql_" prefix
                key = sub_str(key, 9)
                val = get_parsed_graphql()[key]

            elseif key == "route_id" then
                val = ngx.ctx.api_ctx and ngx.ctx.api_ctx.route_id

            elseif key == "service_id" then
                val = ngx.ctx.api_ctx and ngx.ctx.api_ctx.service_id

            elseif key == "consumer_name" then
                val = ngx.ctx.api_ctx and ngx.ctx.api_ctx.consumer_name

            elseif key == "route_name" then
                val = ngx.ctx.api_ctx and ngx.ctx.api_ctx.route_name

            elseif key == "service_name" then
                val = ngx.ctx.api_ctx and ngx.ctx.api_ctx.service_name

            elseif key == "balancer_ip" then
                val = ngx.ctx.api_ctx and ngx.ctx.api_ctx.balancer_ip

            elseif key == "balancer_port" then
                val = ngx.ctx.api_ctx and ngx.ctx.api_ctx.balancer_port

            else
                val = get_var(key, t._request)
            end

            if val ~= nil and not no_cacheable_var_names[key] then
                t._cache[key] = val
            end

            return val
        end,

        __newindex = function(t, key, val)
            if ngx_var_names[key] then
                ngx_var[key] = val
            end

            -- log.info("key: ", key, " new val: ", val)
            t._cache[key] = val
        end,
    }

function _M.set_vars_meta(ctx)
    local var = tablepool.fetch("ctx_var", 0, 32)
    if not var._cache then
        var._cache = {}
    end

    var._request = get_request()
    setmetatable(var, mt)
    ctx.var = var
end

function _M.release_vars(ctx)
    if ctx.var == nil then
        return
    end

    core_tab.clear(ctx.var._cache)
    tablepool.release("ctx_var", ctx.var, true)
    ctx.var = nil
end

end -- do


return _M

简单理一下函数框架

parse_graphql(ctx)
get_parsed_graphql()
do
- var_methods
- no_cacheable_var_names
- ngx_var_names
- mt
  - __index = function(t, key)
  - __newindex = function(t, key, val)
_M.set_vars_meta
_M.release_vars

然后中有一部分代码可以从 APISIX 的官方一个源码文档里得到学习。

地址为：请求生命周期。

开始工作

我的第一版计划

向上游提交 json 格式的 PR
1. 上游 PR 通过后，再进行 APISIX 的 issue 修复。
APISIX 中只要对上游的函数进行使用，并输出报错结果就行。

大佬思路

来自APISIX PMC zexuan

大概意思就是，把 json 在APISIX 里解码成 query 字段，然后再将其query 喂给 graphql-lua。

我们并不需要支持 operationName、variable这些功能。

这个思路贼简单，那我为啥想不到呢？

轻微反思，是因为有点“眼高手低”处理实际问题的能力待加强。慢慢学习吧

有个调试问题没解决好，离谱，得加速了。

2022年2月11日的工作

找到需要更改的代码范围，将 graphql-lua 中的 parse.lua 代码理解清楚。
将 ctx.lua 代码理解清楚。
确定思路

2022年2月14日的工作

完成测试框架的搭建

2022年2月15日的工作

成功跑通测试框架
开始正式开发，将问题锁定在具体的部分

问题解决需要在这里添加代码需要添加代码的地方

很明显，当我从终端扫入一个 body ，它的内容可能是这样的。

2022/02/15 15:31:09 [info] 338683#338683: *77846 [lua] ctx.lua:59: parse_graphql(): booody: query getRepo {owner {name}repo {created}}, client: 127.0.0.1, server: _, request: "POST /graphql HTTP/1.1", host: "127.0.0.1:9080"

这对照了这样的请求：

curl -H 'content-type: application/graphql' -X POST http://127.0.0.1:9080/graphql -d 'query getRepo {owner {name}repo {created}}'

也可以是这样的：

2022/02/15 15:32:55 [info] 338682#338682: *84824 [lua] ctx.lua:59: parse_graphql(): booody: {"query":"query getUser{getUser{name age}}","variables":null}, client: 127.0.0.1, server: _, request: "POST /graphql HTTP/1.1", host: "127.0.0.1:9080"

这对照了这样的请求：

curl 'http://127.0.0.1:9080/graphql' \
  -H 'Content-Type: application/json' \
  -H 'Accept: */*' \
  --data-raw '{"query":"query getUser{getUser{name age}}","variables":null}' \
  --compressed

当然，第一个请求就是目前 APISIX 能够处理的 query 格式的 graphql 语句，第二个请求是目前 APISIX 不能够处理的 json 格式的 graphql 语句。

而我需要做的事情，就是把 json 格式转换为 query 格式，既然确认了，就开始做，寻找 lua 转换格式的方法。

基础命令_graphql在APISIX中的应用（代码向）

February 4, 2022 · 8 min read

CheverJohn

Student of JUST, Open Source Enthusiast.

本篇博客主要记录了我在使用 GraphQL 和 Apache APISIX 搭配过程中遇到的很多问题。纯属个人产出，有不对的地方还望指出。

基础命令

路由规则配置

# basic Apache APISIX config

curl http://127.0.0.1:9080/apisix/admin/routes/11 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
  "methods": ["POST"],
  "uri": "/graphql",
  "vars": [
    ["graphql_operation", "==", "query"],
    ["graphql_name", "==", "getRepo"],
    ["graphql_root_fields", "has", "owner"]
  ],
  "upstream": {
    "type": "roundrobin",
    "nodes": {
        "127.0.0.1:1980": 1
    }
  }
}'

反馈

一般在我之前的OpenResty中正常配置好1980服务器后，我配置APISIX路由正确之后会返回如下的信息

HTTP/1.1 200 OK
Date: Fri, 04 Feb 2022 22:00:03 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Server: APISIX/2.10.3
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: *
Access-Control-Max-Age: 3600

{"action":"set","node":{"value":{"update_time":1644012003,"create_time":1642620298,"methods":["POST"],"uri":"\/graphql","priority":0,"upstream":{"hash_on":"vars","scheme":"http","type":"roundrobin","nodes":{"127.0.0.1:1980":1},"pass_host":"pass"},"vars":[["graphql_operation","==","query"],["graphql_name","==","getRepo"],["graphql_root_fields","has","owner"]],"id":"11","status":1},"key":"\/apisix\/routes\/11"}}

简单请求

# basic request

curl -H 'content-type: application/graphql' -X POST http://127.0.0.1:9080/graphql -d '
query getRepo {
    owner {
        name
    }
    repo {
        created
    }
}'

反馈

当APISIX路由配置正确之后，请求一个基础请求

---Headers
x-real-ip:127.0.0.1
host:127.0.0.1:9080
x-forwarded-proto:http
x-forwarded-host:127.0.0.1
x-forwarded-port:9080
content-length:82
content-type:application/x-www-form-urlencoded
accept:*/*
user-agent:curl/7.29.0
x-forwarded-for:127.0.0.1
---Args
---URI
/graphql
---Service Node
Centos-port: 1980

进阶操作

感谢大佬时刻

这边感谢一下我泽轩大佬，谢谢他给我提出的宝贵意见。非常感谢！

体现 roundrobin 均衡策略

简单记一下逻辑，其实就是不断配置APISIX的路由规则

这边 upstream 里配置了分别架设在 OpenResty 上端口为 1980 和 1981 的两个 node

curl http://127.0.0.1:9080/apisix/admin/routes/11 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "methods": ["POST"],
    "uri": "/graphql",
    "vars": [
        ["graphql_operation", "==", "query"],
        ["graphql_name", "==", "getRepo"],
        ["graphql_root_fields", "has", "owner"]
    ],
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1980": 1,
            "127.0.0.1:1981": 1
        }
    }
}'

两个服务器的权重都设置为 1，一个等级，这里边 2 的权重大于 1。

然后分别发出请求的话，会按照顺序，1 > 2 > 1 > 2 > 1......的顺序得到 upstream 服务器的响应。

根据 graphql_name 匹配 upstream 服务器

错误示范

这一串是给第一个 upstream 服务器配置 graphql_name 为getRepo111

curl http://127.0.0.1:9080/apisix/admin/routes/11 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "methods": ["POST"],
    "uri": "/graphql",
    "vars": [
        ["graphql_operation", "==", "query"],
        ["graphql_name", "==", "getRepo111"],
        ["graphql_root_fields", "has", "owner"]
    ],
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1980": 1
        }
    }
}'

第二个 upstream 服务器配置 graphql_name 为 getRepo222

curl http://127.0.0.1:9080/apisix/admin/routes/11 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "methods": ["POST"],
    "uri": "/graphql",
    "vars": [
        ["graphql_operation", "==", "query"],
        ["graphql_name", "==", "getRepo222"],
        ["graphql_root_fields", "has", "owner"]
    ],
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1981": 1
        }
    }
}'

然后我们可以根据不同的 graphql query 来进行不同的匹配，即泽轩大佬说的

泽轩：Apache APISIX 还可以针对不同的 graphql_operation 进行不同的权限校验、针对不同的 graphql_name 转发到不同的 upstream。

开始 query

curl -H 'content-type: application/graphql' -i -X POST http://127.0.0.1:9080/graphql -d '
query getRepo111 {
    owner {
        name
    }
    repo {
        created
    }
}'

上面的query 转发到了1980 端口的 graphql server上

curl -H 'content-type: application/graphql' -i -X POST http://127.0.0.1:9080/graphql -d '
query getRepo222 {
    owner {
        name
    }
    repo {
        created
    }
}'

上面的 query 转发到了 1981 端口的 graphql server 上

就是这样，先简单做一下，明天再写详细一点。

这边可能对APISIX的 upstream 配置有点问题，所以暂停一下。

如果你这样设置，会遇到一个很明显的问题，后边的配置会覆盖掉前面的配置。
主要原因是 upstream 应该分组！接下来开始正式的工作

成功示范

对第一个 upstream 服务器的配置

首先创建一个上游 upstream 对象：

curl http://127.0.0.1:9080/apisix/admin/upstreams/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "type": "chash",
    "key": "remote_addr",
    "nodes": {
        "127.0.0.1:1980": 1
    }
}'  

上游 upstream 对象创建后，均可以被具体 Route 或者 Service 引用，例如：

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "methods": ["POST"],
    "uri": "/graphql",
    "vars": [
        ["graphql_operation", "==", "query"],
        ["graphql_name", "==", "getRepo111"],
        ["graphql_root_fields", "has", "owner"]
    ],    
    "upstream_id": "1"
}' 

这里边我稍微解释一下，其中 curl http://127.0.0.1:9080/apisix/admin/routes/1 之后最后的 1，我认为就是 "upstream_id": "1"。因为从源码中解析 curl 请求的那个函数来看，就应该是这样的，如果有错误，可以来找我哈。

然后进行最后的正式请求：

curl -H 'content-type: application/graphql' -i -X POST http://127.0.0.1:9080/graphql -d '
query getRepo111 {
    owner {
        name
    }
    repo {
        created
    }
}'

得到正确的响应：

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Date: Mon, 07 Feb 2022 22:57:24 GMT
Server: APISIX/2.10.3

---Headers
x-forwarded-port:9080
content-length:85
user-agent:curl/7.29.0
accept:*/*
content-type:application/x-www-form-urlencoded
host:127.0.0.1:9080
x-real-ip:127.0.0.1
x-forwarded-for:127.0.0.1
x-forwarded-proto:http
x-forwarded-host:127.0.0.1
---Args
---URI
/graphql111
---Service Node
Centos-port: 1980
John Chever's 1980 port is working......

完成第一个 upstream 上游服务器的配置了。

对第二个 upstream 服务器的配置

首先创建一个上游 upstream 对象：

curl http://127.0.0.1:9080/apisix/admin/upstreams/2 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "type": "chash",
    "key": "remote_addr",
    "nodes": {
        "127.0.0.1:1981": 1
    }
}'

上游 upstream 对象创建后，均可以被具体 Route 或者 Service 引用，例如：

curl http://127.0.0.1:9080/apisix/admin/routes/2 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "methods": ["POST"],
    "uri": "/graphql",
    "vars": [
        ["graphql_operation", "==", "query"],
        ["graphql_name", "==", "getRepo222"],
        ["graphql_root_fields", "has", "owner"]
    ],
    "upstream_id": 2
}'

然后进行最后的正式请求：

curl -H 'content-type: application/graphql' -i -X POST http://127.0.0.1:9080/graphql -d '
query getRepo222 {
    owner {
        name
    }
    repo {
        created
    }
}'

得到正确的响应：

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Date: Mon, 07 Feb 2022 23:04:44 GMT
Server: APISIX/2.10.3

---Headers
x-forwarded-port:9080
content-length:85
user-agent:curl/7.29.0
accept:*/*
content-type:application/x-www-form-urlencoded
host:127.0.0.1:9080
x-real-ip:127.0.0.1
x-forwarded-for:127.0.0.1
x-forwarded-proto:http
x-forwarded-host:127.0.0.1
---Args
---URI
/graphql222
---Service Node
Centos-port: 1981
John Chever's 1981 port is working......

小结

这样配置好，就可以根据不同的 graphql_name 来匹配不同的上游 upstream 啦。

根据 graphql_operation 进行不同的权限校验

首先配置好上游对象实例

curl http://192.168.1.200:9080/apisix/admin/routes/11 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "methods": ["POST"],
    "uri": "/hello",
    "vars": [
        ["graphql_operation", "==", "mutation"],
        ["graphql_name", "==", "repo"]
    ],
    "upstream": {
        "nodes": {
            "192.168.1.200:1982": 1
        },
        "type": "roundrobin"
    }
}'

然后发送请求以验证配置：

curl -i -X POST http://127.0.0.1:9080/hello -d '
mutation repo($ep: Episode!, $review: ReviewInput!) {
  createReview(episode: $ep, review: $review) {
    stars
    commentary
  }
}'

返回响应：

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Date: Tue, 08 Feb 2022 22:05:51 GMT
Server: APISIX/2.10.3

---Headers
content-type:application/x-www-form-urlencoded
host:127.0.0.1:9080
x-real-ip:127.0.0.1
x-forwarded-for:127.0.0.1
x-forwarded-proto:http
x-forwarded-host:127.0.0.1
x-forwarded-port:9080
content-length:133
user-agent:curl/7.29.0
accept:*/*
---Args
---URI
/hello
---Service Node
Centos-port: 1982
John Chever's 1982 port is working......

自此实现了 Apache APISIX 针对不同的 graphql_operation 进行不同的权限校验、针对不同的 graphql_name 转发到不同的 upstream。

APISIX与上游测试服务器

January 30, 2022 · 4 min read

CheverJohn

Student of JUST, Open Source Enthusiast.

明天就是新春佳节了，已经鸽了两天的博客了，不能再继续下去咯！！！然后祝大家新春快乐哈！
本次博客记录的是我使用 Apache APISIX 中的 GraphQL 特性时，遇到的新手级尴尬问题，淦！主要还是基础网络工具不会用。文章主要围绕两个点：一是 curl 命令工具的使用总结，二是 OpenResty 建立测试服务器的方法（以后还是要单独开张帖子，把 OpenResty，也可以说是 NGINX 的奇淫巧技都梳理一遍）
好吧又得鸽一天，看春晚去咯！:)
春节过完咯，开始肝！
教训妹妹的一晚！
完成文章的抽象部分内容 > 实操部分内容

前言

正如引言中所讲的，本篇博文主要是为了记录我使用 Apache APISIX 的 GraphQL 特性的过程。其中获得了一些对 Apache APISIX，亦或者说是 OpenResty，亦或者说是 NGINX 的最新感悟。首先我先以一张图缕清我所要做的事情的逻辑吧。

GraphQL流量在Apache_APISIX里的轨迹

当然上图这一层面还是太保守了，如果我们有多个 GraphQL Server 呢？其实 Apache APISIX 还具备根据搜索项的参数更精细化的匹配 GraphQL Server (多亏泽轩大佬跟我讲了)。那我们换一个场景。

根据三个参数更加精细化

graphql_operation
graphql_name
graphql_root_fields

逻辑图如下

GraphQL流量在Apache_APISIX里的轨迹_三个参数实现更精细化操作

以上是抽象层面的逻辑图，

部署配置

这一篇你可以搭配这两篇博客来看：
《问题解决：跑通 GraphQL》: 这一篇介绍了我第一次跑通的情形，里边有我在虚拟机中的Centos7中实操的记录。
《Support GraphQL In APISIX》: 主要讲了 GraphQL 在 APISIX 里的地位是什么样子的。
《基础命令_graphql在APISIX中的应用》

部署配置的架构图应如下所示：

GraphQL在centos中的具体部署方案

这边我们依靠了 OpenResty 搭建了两台 GraphQL Server 上游（Upstream）服务器。并使用命令配置 Apache APISIX的路由匹配规则。这样我们接下来发出 GraphQL 请求的时候，便可以有上游服务器进行响应了。

背景描述​

Background Description​

Installation​

Make deps​

开始测试部分​

2022年 3月 8日​

先配置​

小知识​

--- ONLY​

--- SKIP​

小知识​

起源​

issue 详情​

Environment​

Reproduce​

Actual result​

Error log​

Expected result​

issue 提出者认为​

而且​

对于 curl 工具的使用​

得出结论: mock GraphQL data of APISIX is not a standard GraphQL request.​

评估需求​

重点：点睛之笔​

可参考的 GraphQL 官方文档​

评估工作情况​

第一次评估​

源码分析​

开始工作​

我的第一版计划​

大佬思路​

2022年2月11日的工作​

2022年2月14日的工作​

2022年2月15日的工作​

基础命令​

路由规则配置​

简单请求​

进阶操作​

感谢大佬时刻​

体现 roundrobin 均衡策略​

根据 graphql_name 匹配 upstream 服务器​

错误示范​

成功示范​

对第一个 upstream 服务器的配置​

对第二个 upstream 服务器的配置​

小结​

根据 graphql_operation 进行不同的权限校验​

前言​

部署配置​

背景描述

Background Description

Installation

Make deps

开始测试部分

2022年 3月 8日

先配置

小知识

--- ONLY

--- SKIP

小知识

起源

issue 详情

Environment

Reproduce

Actual result

Error log

Expected result

issue 提出者认为

而且

对于 curl 工具的使用

得出结论: mock GraphQL data of APISIX is not a standard GraphQL request.

评估需求

重点：点睛之笔

可参考的 GraphQL 官方文档

评估工作情况

第一次评估

源码分析

开始工作

我的第一版计划

大佬思路

2022年2月11日的工作

2022年2月14日的工作

2022年2月15日的工作

基础命令

路由规则配置

简单请求

进阶操作

感谢大佬时刻

体现 roundrobin 均衡策略

根据 graphql_name 匹配 upstream 服务器

错误示范

成功示范

对第一个 upstream 服务器的配置

对第二个 upstream 服务器的配置

小结

根据 graphql_operation 进行不同的权限校验

前言

部署配置