标签归档:Kong插件

如何在 Kong 和 OpenResty 中使用环境变量 os.getenv()

在项目中有时会遇到使用系统环境变量的问题,但是直接使用 os.getenv() 是不可行的,不仅是在 Kong 中,在 OpenResty 也都是不可以的,原因是 Kong 是基于 OpenResty ,OpenResty 是基于 Nginx 的,而Nginx在启动的时候,会把环境中所有的环境变量都清除掉,我们可以从Nginx的官方文档中看到这段描述:http://nginx.org/en/docs/ngx_core_module.html#env 

By default, nginx removes all environment variables inherited from its parent process except the TZ variable.

具体可以参考春哥在这个issue下的回复:https://github.com/openresty/lua-nginx-module/issues/601

所以需要在你的nginx.conf文件中把你需要的环境变量声明一下:

events{
  ...
}

env PATH;
env USERNAME;

然后重启一下Nginx,就可以直接在你的 Lua 代码中使用 os.getenv("USERNAME") 获取环境变量。

在 Kong 中使用 os.getenv()

那如果我想在kong的插件中是使用os.getenv()要怎么操作呢?

在 Kong 里面,我们看到Kong生成的 Nginx配置文件是不可修改的,即使你修改了,Kong 还是会生成恢复成修改前,那么这个时候就要用到 Kong 的一个自定义 Nginx 配置文件功能。详情可以看这俩issue:

那么实际操作起来就很简单了,新建一个custom-nginx.conf文件,里面和上文一样,把你需要使用到的环境变量写到这个配置文件中。

events{
  ...
}

env PATH;
env USERNAME;

接着重启 Kong 即可。不过这里要注意的是,重启的时候,需要带上一个参数--nginx-conf。不过不要搞错的是-c参数是kong的配置文件参数,--nginx-conf 是自定义Nginx模板配置参数

 kong restart -c kong.conf --nginx-conf custom-nginx.conf

重启成功之后,就可以在 Kong 的插件中使用代码中使用 os.getenv("USERNAME") 来获取环境变量了。

使用 Docker 安装 Kong

有关如何在Docker中使用Kong的详细信息可以在镜像图像的DockerHub存储库中找到:kong。 我们还有一个Docker Compose template,内置编排和可扩展性。

使用数据库

这是一个快速示例,显示如何将Kong容器连接到Cassandra或PostgreSQL容器。

  1. 创建一个Docker network

    您需要创建一个自定义网络,以允许容器相互发现和通信。在此示例中,kong-net是网络名称,您可以使用任何名称。

     $ docker network create kong-net
    
  2. 启动数据库

    如果您想使用Cassandra容器:

      $ docker run -d --name kong-database \
                --network=kong-net \
                -p 9042:9042 \
                cassandra:3
    

    如果您想使用PostgreSQL容器:

      $ docker run -d --name kong-database \
                --network=kong-net \
                -p 5432:5432 \
                -e "POSTGRES_USER=kong" \
                -e "POSTGRES_DB=kong" \
                postgres:9.6
    
  3. 准备数据库

    使用临时Kong容器运行迁移:

      $ docker run --rm \
      --network=kong-net \
      -e "KONG_DATABASE=postgres" \
      -e "KONG_PG_HOST=kong-database" \
      -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
      kong:latest kong migrations bootstrap
    

    在上面的示例中,配置了Cassandra和PostgreSQL,但您应该使用cassandrapostgres更新KONG_DATABASE环境变量。
    对于Kong 小于0.15的注意事项:如果Kong版本低于0.15(最高0.14),请使用up子命令而不是bootstrap。另请注意,如果Kong 版本小于0.15,则不应同时进行迁移;只有一个Kong节点应该一次执行迁移。对于0.15,1.0及以上的Kong,此限制被取消。

  4. 启动Kong

    迁移运行并且数据库准备就绪后,启动一个将连接到数据库容器的Kong容器,就像临时迁移容器一样:

      $ docker run -d --name kong \
      --network=kong-net \
      -e "KONG_DATABASE=postgres" \
      -e "KONG_PG_HOST=kong-database" \
      -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
      -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
      -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
      -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
      -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
      -e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl" \
      -p 8000:8000 \
      -p 8443:8443 \
      -p 8001:8001 \
      -p 8444:8444 \
      kong:latest
    
  5. 使用Kong

    Kong正在运行:

      $ curl -i http://localhost:8001/
    

    通过5分钟的快速入门快速学习如何使用Kong。

无数据库模式

在无DB模式下启动Kong所涉及的步骤如下:

  1. 创建一个Docker network

    这与Pg / Cassandra指南中的相同。我们也使用kong-net作为网络名称,它也可以改为其他东西。

      $ docker network create kong-net
    

    在无DB模式下运行Kong并不严格需要此步骤,但如果您希望将来添加其他内容(如Redis群集备份的速率限制插件),这是一个很好的预防措施。

  2. 创建Docker volume

    对于本指南的目的,Docker卷是主机内的一个文件夹,可以将其映射到容器中的文件夹中。卷有一个名称。在这种情况下,我们将命名我们的kong-vol

      $ docker volume create kong-vol
    

    您现在应该能够检查volume:

      $ docker volume inspect kong-vol
    

    结果应该类似于:

      [
          {
              "CreatedAt": "2019-05-28T12:40:09Z",
              "Driver": "local",
              "Labels": {},
              "Mountpoint": "/var/lib/docker/volumes/kong-vol/_data",
              "Name": "kong-vol",
              "Options": {},
              "Scope": "local"
          }
      ]
    

    注意MountPoint条目。我们将在下一步中使用该路径。

  3. 准备声明性配置文件

    声明性配置格式指南中描述了语法和属性。

    添加您需要的任何核心实体(服务,路由,插件,消费者等)。

    在本指南中,我们假设您将其命名为kong.yml。

    将其保存在上一步中提到的MountPoint路径中。

    就本指南而言,这将是/var/lib/docker/volumes/kong-vol/_data/kong.yml

  4. 在无DB模式中启动Kong

    虽然可以仅使用KONG_DATABASE=off来启动Kong容器,但通常还需要通过KONG_DECLARATIVE_CONFIG变量名称将声明性配置文件作为参数包含在内。为此,我们需要从容器中使文件“visible”。我们使用-v标志来实现这一点,它将kong-vol卷映射到容器中的/usr/local/kong/declarative文件夹。

      $ docker run -d --name kong \
      --network=kong-net \
      -v "kong-vol:/usr/local/kong/declarative" \
      -e "KONG_DATABASE=off" \
      -e "KONG_DECLARATIVE_CONFIG=/usr/local/kong/declarative/kong.yml" \
      -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
      -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
      -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
      -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
      -e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl" \
      -p 8000:8000 \
      -p 8443:8443 \
      -p 8001:8001 \
      -p 8444:8444 \
      kong:latest
    
  5. 使用Kong

    Kong应该正在运行,它应该包含一些以Kong .yml添加的实体。

      $ curl -i http://localhost:8001/
    

    例如,获取服务列表:

      $ curl -i http://localhost:8001/services

 

Kong 1.3发布!支持原生gRPC代理,上游双向TLS认证,以及更多功能

原文地址:https://konghq.com/blog/kong-1-3-released/

今天,我们很高兴地宣布推出Kong 1.3!我们的工程团队和出色的社区为此版本提供了许多功能和改进。基于1.2版本的成功,Kong 1.3是Kong的第一个版本,它本身支持gRPC代理,上游相互TLS身份验证,以及一系列新功能和性能改进。

请阅读以下内容,了解有关Kong 1.3的新功能,改进和修复的更多信息,以及如何利用这些令人兴奋的变化。 请花几分钟时间阅读我们的更新日志以及升级路径以获取更多详细信息。

原生gRPC代理

我们观察到越来越多的用户转向微服务架构,并听到用户表达他们对本机gRPC代理支持的兴趣。Kong 1.3通过支持gRPC本地代理来解决这个问题,为支持gRPC的基础架构带来更多控制和可见性。

主要优点:

  • 简化运营流程。
  • 为gRPC服务添加A / B测试,自动重试和断路,以提高可靠性和正常运行时间。
  • 更多的可观测性
  • 针对gRPC服务的日志记录,分析或Prometheus集成?Kong让你满意。

主要功能:

  • 新协议:Route和Service实体的protocol属性现在可以设置为grpcgrpcs,这对应于通过明文HTTP/2(h2c)的gRPC和通过TLS HTTP/ 2(h2)的gRPC。

上游双向TLS认证

Kong长期以来一直支持与上游服务的TLS连接。 在1.3中,我们添加了对Kong的支持,以提供特定证书,同时与上游握手以提高安全性。

主要优点:

  • 能够使用证书与上游服务握手使得Kong在需要强大的身份验证保证的行业中更加出色,例如金融和医疗保健服务。
  • 安全性更好
  • 通过提供可信证书,上游服务将确定传入请求是由Kong转发的,而不是恶意客户端。
  • 对开发人员更友好
  • 您可以使用Kong将需要相互TLS身份验证的服务转换为与开发人员无关的方法(例如OAuth)。

主要功能:

  • 新配置属性:Service实体具有新字段client_certificate。如果设置,当Kong尝试与服务握手时将使用相应的证书。

Sessions 插件

在Kong 1.3中,我们开放了Sessions插件(之前仅在Kong Enterprise中提供)供所有用户使用。 结合其他身份验证插件,它允许Kong记住之前已经过身份验证的浏览器用户。 您可以在此处阅读详细的文档

NGINX CVE修复

Kong 1.3附带NGINX HTTP/2模块(CVE-2019-9511CVE-2019-9513CVE-2019-9516)的修复程序。 我们还发布了Kong 1.0.4,1.1.3,1.2.2来修补旧版Kong中的漏洞,以防不能立即升级到1.3。

OpenResty Version Bump

OpenResty的版本已经发布到最新的OpenResty版本 - 1.15.8.1,该版本基于Nginx 1.15.8。 此版本的OpenResty在关闭上游keepalive连接,ARM64架构支持和LuaJIT GC64模式时带来了更好的性能。 最引人注目的变化是,由于LuaJIT编译器生成更多本机代码,OpenResty更有效地存储请求上下文数据,因此使用密钥身份验证在基线代理基准测试中,Kong现在运行速度提高约10%。 

Kong 1.3的其他新功能

按任何请求 header 路由

  • Kong的路由器现在能够通过任何请求头(不仅是Host)匹配路由。
  • 这允许对服务之间路由传入流量的方式进行精细控制。
  • 参阅此处的文档

最少连接负载平衡

  • Kong现在可以将流量发送到连接数最少的上游服务。
  • 在某些用例中改善上游负载分配。
  • 参阅此处的文档

数据库导出

  • 新添加的kong config db_export CLI命令可用于创建数据库内容转储到YAML文件中,该文件适用于声明性配置或稍后导回数据库。
  • 这样可以更轻松地创建声明性配置文件。
  • 这使得Kong配置的备份和版本控制变得更加容易
  • 参阅此处的文档

主动关闭上游keepalive连接

  • 在旧版本的Kong中,上游连接永远不会被Kong关闭。这可能导致竞争条件,因为Kong可能会尝试重新使用keepalived连接,而上游尝试关闭它。
  • 如果您在Kong error.log中看到“upstream prematurely closed connection”错误,则此版本应显着减少甚至消除部署中的此错误。
  • 添加了新的配置指令来控制此行为,请阅读完整的更新日志以了解更多信息。

更多的监听标志支持

  • 特别是reuseport标志,如果Kong worker数量很大,可用于改善负载分配和延迟抖动。
  • 还添加了deferredbind标志支持。您可以查看NGINX listen指令文档以了解使用它们的效果。

其他改进和错误修复

Kong 1.3还包含有关存储CA证书(没有私钥的证书),Admin API接口和更多PDK功能的新实体的改进。 我们还修复了很多错误。由于此版本中有大量新功能,因此我们无法在此博客文章中介绍所有这些内容,而是鼓励您在此处阅读完整的更新日志

我们还在kong.conf模板中添加了一个新的部分,以更好地解释注入NGINX指令的功能。 对于具有仅添加几个NGINX指令的自定义模板的用户,我们建议切换使用注入的NGINX指令,以获得更好的可升级性。

与往常一样,Kong 1.3的文档可在此处获得。 此外,如上所述,我们将在后续帖子和社区电话中讨论1.3中的主要功能,敬请期待!

感谢我们的用户,贡献者和核心维护者社区,感谢您对Kong的开源平台的持续支持。 请试试Kong 1.3,一定要告诉我们您的想法

Kong社区

像往常一样,随时可以就我们的社区论坛Kong Nation提出任何问题。 从您的反馈中学习将使我们能够更好地理解任务关键用例并不断改进Kong。

微服务 API 网关 Kong 插件 Kubernetes Sidecar 注入插件中文文档

Kubernetes Sidecar 注入插件

该插件将注入Kong数据平面节点并在Kubernetes之上形成服务网格

介绍

Kong 0.15.0 / 1.0.0增加了代理和路由原始tcptls流的能力,并使用服务网格Sidecar模式和Kong节点之间的相互tls来部署Kong。本教程将引导您使用我们的 Kubernetes Sidecar 注入插件在Kubernetes上设置Kong服务网格。

准备条件

您需要在Kubernetes上运行Kong 1.0.0或更高版本,包括存储为可用于Kong控制平面的机密的SSL证书。来自Kong Kubernetes Repository的Make任务run_cassandrarun_postgres将完全配置必备数据存储,Kong控制平面,Kong数据平面和SSL机密。

或者,按照Kong Kubernetes Install Instructions页面中的任何设置说明进行操作,然后设置SSL证书/密码:

cd $(mktemp -d)

### Create a key+certificate for the control plane
cat <<EOF | kubectl create -f -
apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:
  name: kong-control-plane.kong.svc
spec:
  request: $(openssl req -new -nodes -batch -keyout privkey.pem -subj /CN=kong-control-plane.kong.svc | base64 | tr -d '\n')
  usages:
  - digital signature
  - key encipherment
  - server auth
EOF
kubectl certificate approve kong-control-plane.kong.svc
kubectl -n kong create secret tls kong-control-plane.kong.svc --key=privkey.pem --cert=<(kubectl get csr kong-control-plane.kong.svc -o jsonpath='{.status.certificate}' | base64 --decode)
kubectl delete csr kong-control-plane.kong.svc
rm privkey.pem

或使用以下简便脚本:

curl -fsSL https://raw.githubusercontent.com/Kong/kong-dist-kubernetes/master/setup_certificate.sh | bash

安装步骤

导出一些变量以访问Kong Admin API和Proxy:

$ export HOST=$(kubectl get nodes --namespace default -o jsonpath='{.items[0].status.addresses[0].address}')
$ export ADMIN_PORT=$(kubectl get svc --namespace kong kong-control-plane  -o jsonpath='{.spec.ports[0].nodePort}')

通过Kong Admin API启用Sidecar Injector插件:

curl $HOST:$ADMIN_PORT/plugins -d name=kubernetes-sidecar-injector -d config.image=kong

打开Kubernets Sidecar Injection:

cat <<EOF | kubectl create -f -
apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration
metadata:
  name: kong-sidecar-injector
webhooks:
- name: kong.sidecar.injector
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
    operations: [ "CREATE" ]
  failurePolicy: Fail
  namespaceSelector:
    matchExpressions:
    - key: kong-sidecar-injection
      operator: NotIn
      values:
      - disabled
  clientConfig:
    service:
      namespace: kong
      name: kong-control-plane
      path: /kubernetes-sidecar-injector
    caBundle: $(kubectl config view --raw --minify --flatten -o jsonpath='{.clusters[].cluster.certificate-authority-data}')
EOF

或使用以下简便脚本:

curl -fsSL https://raw.githubusercontent.com/Kong/kong-dist-kubernetes/master/setup_sidecar_injector.sh | bash

使用

接下来,任何开始使用Kong Sidecar的pods都会自动注入,而来自该pods容器的所有数据都将通过Kong Sidecar。 例如,如果我们使用Istio中的bookinfo.yaml示例:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.1/samples/bookinfo/platform/kube/bookinfo.yaml

我们看到所有pods都收到了Kong Sidecar:

kubectl get all
NAME                 READY   STATUS
pod/details-v1       2/2     Running
pod/productpage      2/2     Running
pod/ratings-v1       2/2     Running
pod/reviews-v1       2/2     Running
pod/reviews-v2       2/2     Running
pod/reviews-v3       2/2     Running

继续配置服务。

微服务 API 网关 Kong 中文文档发布

由于项目的原因,最近的几个月一直在学习微服务的API网关 Kong ,在这里做一个简单介绍,是一个云原生,高效,可扩展的分布式 API 网关。 自 2015 年在 github 开源后,广泛受到关注,目前已收获 1.68w+ 的 star,其核心价值在于高性能和可扩展性。由于对项目的积极维护,Kong被广泛用于从初创公司到全球5000强以及政府机构的生产中。从技术角度来说,Kong是基于Openresty的一个莹莹,Openresty是基于Nginx的,使用的语言是Lua。

所以在学习过程中,首要是需要看官方文档,由于项目比较新,所以暂时没有中文文档,我就想着,反正文档总是要全部看一遍的,不如自己翻译一份好了,于是乎就有了这个项目:Kong的文档中文版。欢迎大家star&fork。

由于自己不是英语专业,而且主要目的是学习Kong,所以采用的是人工+机翻结合的方式,如果有遇到翻译的不够通顺,或者对于翻译的语句有歧义的地方,麻烦一定点击官网英文文档https://docs.konghq.com/ 查看,并且欢迎提 PR 提修改意见。另,由于kong的文档本身也在不断增加和完善当中,如果有遇到没有即使更新翻译的状况欢迎提issue,我会不断补充的。

todo:

  • 目前文档中的超链接都是链接的英文原文,后续会慢慢改成中文内链。
  • 会在每一页文档里面附上单独的英文原文链接,以便做对照。
  • 会添加kong自带的插件文档。

本文档是基于 https://docs.konghq.com/1.1.x/ 1.1.x 版本,目前官网已经更新至 1.2.x 版本,如果使用的最新版本,请查看 https://docs.konghq.com 并注意差别。

微服务 API 网关 Kong 插件开发 – 插件配置

原文地址:https://docs.konghq.com/1.1.x/plugin-development/plugin-configuration/(不能保证所有的翻译都是准确无误的,所有如有翻译的不准确或错误之处,请一定记得查看原文,并欢迎留言指出)。

简介

大多数情况下,您的插件可以配置为满足您的所有用户需求。当插件被执行的时候,您的插件的配置存储在Kong的数据存储区中,以检索它并将其传递给handler.lua方法。

配置由Kong中的Lua表组成,我们称之为 schema。它包含用户在通过Admin API启用插件时将设置的键/值属性。Kong为您提供了一种验证用户插件配置的方法。

当用户向Admin API发出请求以启用或更新给定Service,Route和/或Consumer上的插件时,将根据您的架构schema插件的配置。

例如,用户执行以下请求:

$ curl -X POST http://kong:8001/services/<service-name-or-id>/plugins/ \
    -d "name=my-custom-plugin" \
    -d "config.foo=bar"

如果配置对象的所有config都根据您的模式有效,则API将返回201 Created,并且插件将与其配置一起存储在数据库中(在这种情况下为{foo =“bar”})。如果配置无效,Admin API将返回400 Bad Request和相应的错误消息。

模块

kong.plugins.<plugin_name>.schema

schema.lua规范

此模块将返回一个Lua表,其中包含将定义用户以后如何配置插件的属性的属性。 可用的属性是:

属性名称 Lua type 默认值 描述
no_consumer Boolen false 如果为true,则无法将此插件应用于特定的Consumer。此插件必须仅应用于服务和路由。例如:身份验证插件。
fields Table {} 你插件的schema,可用属性及其规则的键/值表。
self_check Function nil 如果要在接受插件配置之前执行任何自定义验证,则要实现的功能。

self_check函数必须按如下方式实现:

-- @param `schema` 描述插件配置的架构(规则)的表。
-- @param `config` 当前插件配置的键/值表。
-- @param `dao` DAO的一个实例 (查看 DAO 章节).
-- @param `is_updating` 一个布尔值,指示是否在更新的上下文中执行此检查。
-- @return `valid` 一个布尔值,指示插件的配置是否有效。
-- @return `error` 一个 DAO 错误 (查看 DAO 章节)

以下是一个可能的schema.lua文件的示例:

return {
  no_consumer = true, -- 此插件仅适用于服务或路由,
  fields = {
    -- 在此处描述您的插件配置架构。
  },
  self_check = function(schema, plugin_t, dao, is_updating)
    -- 执行任何自定义验证
    return true
  end
}

描述您的配置schema

schema.lua文件的fields自选描述了插件配置的schema。它是一个灵活的键/值表,其中每个键都是插件的有效配置属性,每个键都是一个描述该属性规则的表。例如:

 fields = {
    some_string = {type = "string", required = true},
    some_boolean = {type = "boolean", default = false},
    some_array = {type = "array", enum = {"GET", "POST", "PUT", "DELETE"}}
  }

以下是属性的规则列表:

规则 LUA TYPE(S) 可使用的值 描述
type string “id”, “number”, “boolean”, “string”, 
“table”, “array”, “url”, “timestamp”
验证属性的类型。
required boolean 默认值:false。
如果为true,则该属性必须存在于配置中。
unique boolean 默认值:false。
如果为true,则该值必须是唯一的(请参阅下面的注释)。
default any 如果未在配置中指定该属性,则将该属性设置为给定值。
immutable boolean 默认值:false。
如果为true,则在创建插件配置后将不允许更新该属性。
enum table 属性的可接受值列表。不接受此列表中未包含的任何值。
regex string 用于验证属性值的正则表达式。
schema table 如果属性的类型是table,则定义用于验证这些子属性的模式。
func function 用于对属性执行任何自定义验证的函数。请参阅后面的示例,了解其参数和返回值。
  • type:将转换从请求参数中检索的值。如果类型不是本机Lua类型之一,则会对其执行自定义验证:
    • id:必须是string
    • timestamp:必须是nember
    • uri:必须是有效的URL
    • array:必须是整数索引表(相当于Lua中的数组)。在Admin API中,可以通过在请求的正文中使用不同值的属性键的多次来发送这样的数组,或者通过单个body参数以逗号分隔。
  • unique:此属性对插件配置没有意义,但在插件需要在数据存储区中存储自定义实体时使用。
  • schema:如果您需要对嵌套属性进行深化验证,则此字段允许您创建嵌套模式。模式验证是递归的。任何级别的嵌套都是有效的,但请记住,这会影响插件的可用性。
  • 附加到配置对象但schema中不存在的任何属性也将使所述配置无效。

例子

key-auth插件的schema.lua文件定义了API密钥的可接受参数名称的默认列表,以及默认设置为false的布尔值:

-- schema.lua
return {
  no_consumer = true,
  fields = {
    key_names = {type = "array", required = true, default = {"apikey"}},
    hide_credentials = {type = "boolean", default = false}
  }
}

于是,当在handler.lua中实现插件的access()函数并且用户使用默认值启用插件时,您可以如下:

-- handler.lua
local BasePlugin = require "kong.plugins.base_plugin"
local CustomHandler = BasePlugin:extend()

function CustomHandler:new()
  CustomHandler.super.new(self, "my-custom-plugin")
end

function CustomHandler:access(config)
  CustomHandler.super.access(self)

  kong.log.inspect(config.key_names)        -- {"apikey"}
  kong.log.inspect(config.hide_credentials) -- false
end

return CustomHandler

请注意,上面的示例使用插件开发工具包(PDK)kong.log.inspect函数将这些值打印到Kong日志中。

一个更复杂的示例,可用于最终日志记录插件:

-- schema.lua

local function server_port(given_value, given_config)
  -- 自定义验证
  if given_value > 65534 then
    return false, "port value too high"
  end

  -- 如果环境是“开发”,8080将是默认端口
  if given_config.environment == "development" then
    return true, nil, {port = 8080}
  end
end

return {
  fields = {
    environment = {type = "string", required = true, enum = {"production", "development"}}
    server = {
      type = "table",
      schema = {
        fields = {
          host = {type = "url", default = "http://example.com"},
          port = {type = "number", func = server_port, default = 80}
        }
      }
    }
  }
}

这样的配置将允许用户将配置发布到您的插件,如下所示:

curl -X POST http://kong:8001/services/<service-name-or-id>/plugins \
    -d "name=my-custom-plugin" \
    -d "config.environment=development" \
    -d "config.server.host=http://localhost"

以下内容将在handler.lua中提供:

-- handler.lua
local BasePlugin = require "kong.plugins.base_plugin"
local CustomHandler = BasePlugin:extend()

function CustomHandler:new()
  CustomHandler.super.new(self, "my-custom-plugin")
end

function CustomHandler:access(config)
  CustomHandler.super.access(self)

  kong.log.inspect(config.environment) -- "development"
  kong.log.inspect(config.server.host) -- "http://localhost"
  kong.log.inspect(config.server.port) -- 8080
end

return CustomHandler

您还可以在Key-Auth插件源代码中查看schema的真实示例。

微服务 API 网关 Kong 插件开发 – 文件结构

原文地址:https://docs.konghq.com/1.1.x/plugin-development/file-structure/ (不能保证所有的翻译都是准确无误的,所有如有翻译的不准确或错误之处,请一定记得查看原文,并欢迎留言指出)。

本章假定你已经会使用Lua语言

介绍

将您的插件视为一组Lua模块。本章中描述的每个文件都被视为一个单独的模块。如果他们的名字遵循这个约定,Kong将检测并加载你的插件的模块:

kong.plugins.<plugin_name>.<module_name>

您的模块当然需要通过package.path变量访问,可以通过lua_package_path配置属性调整您的需求。但是,安装插件的首选方法是通过LuaRocks,它与Kong本身集成。有关LuaRocks安装的插件的更多信息,请参阅本指南后面的内容。

为了让Kong意识到必须查找插件的模块,你必须将它添加到配置文件中的plugins属性中,这是一个以逗号分隔的列表。例如

plugins = bundled,my-custom-plugin # 你的插件名称

或者,如果您不想加载任何自带的插件:

plugins = my-custom-plugin  # 你的插件名称

现在,Kong将尝试从以下命名空间加载几个Lua模块:

kong.plugins.my-custom-plugin.<module_name>

其中一些模块是必需的(例如handler.lua),有些是可选的,并且允许插件实现一些额外的功能(例如api.lua以扩展Admin API)。现在让我们准确描述您可以实现的模块以及它们的用途。

基本插件模块

在最基本的形式中,插件包含两个必需的模块:

simple-plugin
├── handler.lua
└── schema.lua
  • 每个函数将在请求的生命周期中的所需时刻运行。
  • 由用户。此模块保存该配置的模式并在其上定义规则,以便用户只能输入有效的配置值。

高级插件模块

有些插件可能需要与Kong更深入地集成:在数据库中拥有自己的表,在Admin API中公开端点等等……每个插件都可以通过向插件添加新模块来完成。如果它实现了所有可选模块,那么插件的结构如下:

complete-plugin
├── api.lua
├── daos.lua
├── handler.lua
├── migrations
│   ├── cassandra.lua
│   └── postgres.lua
└── schema.lua

以下是要实施的可能模块的完整列表以及其目的的简要说明。 本指南将详细介绍,让您掌握其中的每一个文件。

模块文件名称 是否必须 描述
api.lua No 定义Admin API中可用的端点列表,以与插件处理的实体自定义实体进行交互。
daos.lua No 定义DAO(数据库访问对象)列表,这些DAO是插件所需并存储在数据存储区中的自定义实体的抽象。
handler.lua Yes 一个接口的实现。每个函数都由Kong在请求的生命周期中的所需时刻运行。
migrations/xxxx.lua No 给定数据存储的相应迁移。只有当您的插件必须在数据库中存储自定义实体并通过daos.lua定义的其中一个DAO与它们进行交互时,才需要进行迁移。
schema.lua Yes 保存插件配置的架构,以便用户只能输入有效的配置值。

Key-Auth 插件是具有此文件结构的插件的示例。 有关详细信息,请参阅其源代码

微服务 API 网关 Kong 插件开发 – 安装/卸载插件

原文地址:https://docs.konghq.com/1.1.x/plugin-development/entities-cache/ (不能保证所有的翻译都是准确无误的,所有如有翻译的不准确或错误之处,请一定记得查看原文,并欢迎留言指出)。

介绍

Kong的自定义插件由Lua源文件组成,这些源文件需要位于每个Kong节点的文件系统中。本指南将为您提供逐步说明,使Kong节点了解您的自定义插件。这些步骤应该应用于Kong集群中的每个节点,以确保每个节点上都有自定义插件。

打包源

您可以使用常规打包策略(例如tar),也可以使用LuaRocks包管理器为您执行此操作。我们推荐使用LuaRocks,因为它在使用其中一个官方分发包时与Kong一起安装。

使用LuaRocks时,您必须创建一个rockspec文件,用来指定包的内容。有关示例,请参阅Kong插件模板,有关该格式的更多信息,请参阅有关rockspecs的LuaRocks文档

使用以下命令打包你的rock(来自插件仓库):

# install it locally (based on the `.rockspec` in the current directory)
$ luarocks make

# 打包已安装的rock
$ luarocks pack <plugin-name> <version>

假设你的插件rockspec的名字为kong-plugin-myPlugin-0.1.0-1.rockspec,上面就会变成:

$ luarocks pack kong-plugin-myPlugin 0.1.0-1

LuaRocks pack命令现在已经创建了一个.rock文件(这只是一个包含安装rock所需内容的zip文件)。

如果您不使用或不能使用LuaRocks,则使用tar将插件所包含的.lua文件打包到.tar.gz存档中。 如果目标系统上有LuaRocks,也可以包含.rockspec文件。

该插件的内容应该接近以下内容:

$ tree <plugin-name>
<plugin-name>
├── INSTALL.txt
├── README.md
├── kong
│   └── plugins
│       └── <plugin-name>
│           ├── handler.lua
│           └── schema.lua
└── <plugin-name>-<version>.rockspec

安装插件

要使Kong节点能够使用自定义插件,必须在主机的文件系统上安装自定义插件的Lua源。有多种方法:通过LuaRocks,或手动。 选择一个,然后跳转到第3部分。

  1. 来自新建的’rock’的LuaRocks。
    .rock文件是一个自包含的软件包,可以在本地安装,也可以从远程服务器安装。
    如果您的系统中安装了luarocks实用程序(如果使用其中一个官方安装包,可能就是这种情况),您可以在LuaRocks树(LuaRocks安装Lua模块的目录)中安装“rock”。
    它可以通过以下方式安装:

     $ luarocks install <rock-filename>
    

    文件名可以是本地名称,或任何支持的方法。
    例如:http://myrepository.lan/rocks/myplugin-0.1.0-1.all.rock

  2. 从源档案中通过LuaRocks安装。 如果您的系统中安装了luarocks实用程序(如果使用其中一个官方安装包,可能就是这种情况),您可以在LuaRocks树(LuaRocks安装Lua模块的目录)中安装Lua源代码。
    您可以通过将当前目录更改为提取的存档来实现,其中rockspec文件是:

     $ cd <plugin-name>
    

    然后运行以下命令:

     $ luarocks make
    

    这将在系统的LuaRocks树中的kong/plugins/<plugin-name>中安装Lua源代码,其中所有的Kong源都已存在。

  3. 手动
    安装插件源的一种更保守的方法是避免“污染”LuaRocks树,而是将Kong指向包含它们的目录。
    这是通过调整Kong配置的lua_package_path属性来完成的。如果你熟悉它,那么这个属性是Lua VM的LUA_PATH变量的别名。
    这些属性包含以分号分隔的目录列表,用于搜索Lua源。它应该在您的Kong配置文件中设置如下:

     lua_package_path = /<path-to-plugin-location>/?.lua;
    

    继续:
    4./<path-to-plugin-location>是包含提取的存档的目录的路径。它应该是归档中kong目录的位置。
    5.?是一个占位符,将被kong.plugins替换。<plugin-name>当Kong将尝试加载你的插件。
    6.;;“默认Lua路径”的占位符。不要改变它。
    例如:
    插件位于文件系统上,使处理程序文件为:

     /usr/local/custom/kong/plugins/<something>/handler.lua
    

    kong目录的位置是:/usr/local/custom,因此正确的路径设置将是:

     lua_package_path = /usr/local/custom/?.lua;;
    

    多个插件:

    如果您希望以这种方式安装两个或更多自定义插件,可以将变量设置为:

      lua_package_path = /path/to/plugin1/?.lua;/path/to/plugin2/?.lua;;
    
     7.`;`是目录之间的分隔符。
     8.`;;`仍然意味着“默认的Lua路径”。
    

    注意:您还可以通过其等效的环境变量KONG_LUA_PACKAGE_PATH设置此属性。

提醒:无论您使用哪种方法来安装插件的源,您仍必须为Kong群集中的每个节点执行此操作。

加载插件

您现在必须将自定义插件的名称添加到Kong配置中的插件列表中(在每个Kong节点上):

plugins = bundled,<plugin-name>

或者,如果您不想包含默认捆绑的插件:

plugins = <plugin-name>

或者

plugins = plugin1,plugin2

注意:您还可以通过其等效的环境变量KONG_PLUGINS来设置此属性。 提醒:不要忘记更新Kong群集中每个节点的plugins指令。 提醒:插件重启后会生效:

kong restart

但是,如果你想在kong永不停止时应用插件,你可以使用:

kong prepare
kong reload

验证加载插件

你现在应该能够毫无问题地启动Kong。 请参阅自定义插件有关如何在服务,路由或消费者实体上启用/配置插件的说明。

为确保您的插件由Kong加载,您可以使用调试日志级别启动Kong:

log_level = debug

或者

KONG_LOG_LEVEL=debug

然后,您应该看到正在加载的每个插件的以下日志:

[debug] Loading plugin <plugin-name>

删除插件

完全删除插件有三个步骤。

  1. 从您的Kong Service或Route配置中删除插件。确保它不再适用于全局,也不适用于任何服务,路由或使用者。对于整个Kong集群,只需执行一次,不需要重新启动/重新加载。此步骤本身将使插件不再使用。但它仍然可用,仍然可以重新应用插件。
  2. plugins指令中删除插件(在每个Kong节点上)。确保在执行此操作之前已完成步骤1。在此步骤之后,任何人都无法将插件重新应用于任何Kong Service,Route,Consumer甚至全局。此步骤需要重新启动/重新加载Kong节点才能生效。
  3. 要彻底删除插件,请从每个Kong节点中删除与插件相关的文件。在删除文件之前,请确保已完成步骤2,包括重新启动/重新加载Kong。如果你使用LuaRocks来安装插件,你可以使用luarocks remove <plugin-name>来删除它。

分发插件

这样做的首选方法是使用LuaRocks,Lua模块的包管理器。它称这些模块为“rocks”。 您的模块不必存在于Kong存储库中,但如果您希望维护Kong设置,则可能就是这样。

通过在rockspec文件中定义模块(及其最终依赖项),您可以通过LuaRocks在您的平台上安装这些模块。

您也可以在LuaRocks上传模块并将其提供给所有人!

有关示例,请参阅Kong插件模板,有关该格式的更多信息,请参阅有关rockspecs的LuaRocks文档

故障排除

由于以下几个原因,配置错误的自定义插件可能无法启动:

  • “plugin is in use but not enabled” -> 您从另一个节点配置了一个自定义插件,并且该插件配置在数据库中,但您尝试启动的当前节点在其plugins指令中没有它。要解决此问题,请将插件的名称添加到节点的plugins指令中。
  • “plugin is enabled but not installed” -> 插件的名称出现在plugins指令中,但是Kong无法从文件系统加载handler.lua源文件。要解决此问题,请确保正确设置lua_package_path指令以加载此插件的Lua源。
  • “no configuration schema found for plugin” -> 插件已在plugins指令中安装,但是Kong无法从文件系统加载schema.lua源文件。要解决此问题,请确保schema.lua文件与插件的handler.lua文件一起存在。

微服务 API 网关 Kong 插件开发 – 缓存自定义实体

原文地址:https://docs.konghq.com/1.1.x/plugin-development/entities-cache/ (不能保证所有的翻译都是准确无误的,所有如有翻译的不准确或错误之处,请一定记得查看原文,并欢迎留言指出)。

介绍

您的插件可能需要经常访问每个请求 和/或 响应的自定义实体(在前一章中可见)。通常,加载它们一次并将它们缓存在内存中会显着提高性能,同时确保数据存储区不会因负载增加而受到压力。

考虑一个api-key身份验证插件,需要在每个请求上验证api-key,从而在每个请求中从数据存储区加载自定义凭据对象。当客户端提供api-key以及请求时,通常你会查询数据存储区以检查该密钥是否存在,然后,阻止请求或检索 Consumer ID以识别用户,这将在每个请求上发生,并且效率非常低:

  • 查询数据存储会增加每个请求的延迟,使请求处理速度变慢。
  • 数据存储区也会受到负载增加,可能崩溃或减速的影响,这反过来会影响每个Kong节点。

为避免每次都查询数据存储区,我们可以在节点上缓存内存中的自定义实体,这样频繁的实体查找不会每次都触发数据存储区查询(仅限第一次),而是在内存中查询,从数据存储区查询它(特别是在高负载下)更快更可靠。

Modules

kong.plugins.<plugin_name>.daos

缓存自定义实体

一旦定义了自定义实体,就可以使用插件开发工具包提供的 kong.cache 模块将它们缓存在代码中的内存中:

local cache = kong.cache

有两级缓存:

  1. L1:Lua内存缓存 – nginx worker的本地缓存这可以包含任何类型的Lua值。
  2. L2:共享内存缓存(SHM) – nginx节点的本地缓存,但在所有工作者之间共享。这只能保存标量值,因此需要(反)序列化。

从数据库中提取数据时,它将存储在两个缓存中。现在,如果同一个工作进程再次请求数据,它将从Lua内存缓存中检索以前反序列化的数据。如果同一Nginx节点中的另一个工作程序请求该数据,它将在SHM中找到数据,对其进行反序列化(并将其存储在自己的Lua内存缓存中),然后将其返回。

该模块公开以下功能:

FUNCTION NAME DESCRIPTION
value, err = cache:get(key, opts?, cb, ...) 从缓存中检索值。如果缓存没有值(未命中),在保护模式下调用cbcb必须返回一个(并且只有一个)将被缓存的值。它可能会抛出错误,因为这些错误会被Kong捕获并正确记录在ngx.ERR级别。 此函数会缓存否定结果(nil)。因此,在检查错误时必须依赖其第二个参数err
ttl, err, value = cache:probe(key) 检查是否缓存了值。如果是,则返回其剩余的TTL。它没有,返回零。缓存的值也可以是负缓存。第三个返回值是被缓存的值本身。
cache:invalidate_local(key) 从节点缓存中移除一个值。
cache:invalidate(key) 从节点的缓存中删除一个值,并将删除事件传播到集群中的所有其他节点。
cache:purge() 从节点缓存中删除所有值。

回到我们的身份验证插件示例,要查找具有特定api-key的凭据,我们将编写类似于:

-- access.lua

local function load_entity_key(api_key)
  -- 重要: 回调是在锁中执行的,因此我们不能在这里终止请求,我们必须始终返回。
  local apikeys, err = kong.dao.apikeys:find_all({key = api_key}) -- Lookup in the datastore
  if err then
    error(err) -- 被kong.cache捕获并记录
  end

  if not apikeys then
    return nil -- 没有找到 (cached for `neg_ttl`)
  end

  -- 假设键是唯一的,我们总是只有一个值…
  return apikeys[1] -- cache the credential (cached for `ttl`)
end

-- 从请求querystring检索apikey
local querystring = kong.request.get_query()
local apikey = querystring.apikey

-- 我们使用缓存。首先检查apikey是否已经存在
-- 存储在内存缓存中的键值为:“apikeys”。. .apikey
-- 如果不是,则查找数据存储并返回凭据对象。
-- 内部缓存。get将把值保存在内存中,然后返回凭据。
local credential, err = kong.cache:get("apikeys." .. apikey, nil,
                                       load_entity_key, apikey)
if err then
  return kong.response.exit(500, "Unexpected error: " .. err)
end

if not credential then
  -- 缓存和数据存储中没有凭据
  return kong.response.exit(403, "Invalid authentication credentials")
end

-- 如果凭据存在且有效,则设置上游标头
kong.service.request.set_header("X-API-Key", credential.apikey)

注意,在上面的示例中,我们使用插件开发工具包中的各种组件与请求、缓存模块交互,甚至从插件生成响应。
现在,有了上面的机制,一旦使用者使用API键发出请求,缓存就会被认为是热的,随后的请求不会导致数据库查询。 在Key-Auth插件处理程序中,缓存用于多个位置。让我们来看看官方插件是如何使用缓存的。

更新或者删除一个缓存实体

每次在数据存储中更新或删除缓存的自定义实体(即使用Admin API)时,都会在数据存储中的数据与缓存在Kong节点内存中的数据之间产生不一致。为了避免这种不一致,我们需要从内存存储中删除缓存的实体,并强制Kong从数据存储中再次请求它。我们将此过程称为缓存失效。

缓存失效

如果希望缓存的实体在CRUD操作时失效,而不是等待它们到达TTL,则必须执行以下步骤。对于大多数实体,这个过程都可以自动化,但是手动订阅一些CRUD事件可能需要使一些具有更复杂关系的实体失效。

自动缓存失效

如果依赖于实体模式的cache_key属性,则可以为实体提供开箱即用的缓存失效。例如,在下面的模式中:

local SCHEMA = {
  primary_key = { "id" },
  table = "keyauth_credentials",
  cache_key = { "key" }, -- 此实体的缓存键
  fields = {
    id = { type = "id" },
    created_at = { type = "timestamp", immutable = true },
    consumer_id = { type = "id", required = true, foreign = "consumers:id"},
    key = { type = "string", required = false, unique = true }
  }
}

return { keyauth_credentials = SCHEMA }

我们可以看到,我们将这个API key实体的缓存键声明为它的key属性。这里使用key是因为它有一个唯一的约束。因此,添加到cache_key的属性应该产生唯一的组合,这样就不会有两个实体产生相同的缓存键。
添加此值允许您在该实体的DAO上使用以下函数:

cache_key = kong.db.<dao>:cache_key(arg1, arg2, arg3, ...)

其中参数必须是模式的cache_key属性中指定的属性,按照指定的顺序,然后,此函数计算确保唯一的字符串值cache_key
例如,如果我们要生成API密钥的cache_key:

local cache_key = kong.db.keyauth_credentials:cache_key("abcd")

这将为API密钥“abcd”(从查询的一个参数中检索)生成一个cache_key,我们可以使用它来从缓存中检索密钥(如果缓存是未命中,则从数据库中获取):

local apikey = kong.request.get_query().apikey
local cache_key = kong.db.keyauth_credentials:cache_key(apikey)

local credential, err = kong.cache:get(cache_key, nil, load_entity_key, apikey)
if err then
  return kong.response.exit(500, "Unexpected error: " .. err)
end

-- do something with the credential

如果cache_key是这样生成的并且在实体的模式中指定,则缓存失效将是一个自动过程:影响此API密钥的每个CRUD操作都将使make生成受影响的cache_key,并将其广播到群集上的所有其他节点,以便他们可以从缓存中逐出该特定值,并在下一个请求中从数据存储区中获取新值。

当父实体正在接收CRUD操作时(例如,拥有此API密钥的消费者,根据我们的模式的consumer_id属性),Kong为父实体和子实体执行缓存失效机制。

注意:请注意Kong提供的负面缓存。在上面的示例中,如果给定密钥的数据存储区中没有API密钥,则缓存模块将存储未命中,就像它是命中一样。这意味着Kong也会传播“创建”事件(使用此给定密钥创建API密钥的事件),以便存储未命中的所有节点都可以驱逐它,并从数据存储中正确地获取新创建的API密钥。

请参阅群集指南以确保为此类失效事件正确配置了群集。

手动缓存失效

在某些情况下,实体架构的cache_key属性不够灵活,并且必须手动使其缓存无效。原因可能是插件没有通过传统的foreign =“parent_entity:parent_attribute”语法定义与另一个实体的关系,或者因为它没有使用来自其DAO的cache_key方法,或者甚至因为它以某种方式滥用缓存机制。

在这些情况下,您可以手动将自己的订户设置为Kong正在收听的相同失效频道,并执行您自己的自定义失效工作。

要监听Kong内部的失效通道,请在插件的init_worker处理程序中实现以下内容:

function MyCustomHandler:init_worker()
  -- listen to all CRUD operations made on Consumers
  kong.worker_events.register(function(data)

  end, "crud", "consumers")

  -- or, listen to a specific CRUD operation only
  kong.worker_events.register(function(data)
    kong.log.inspect(data.operation)  -- "update"
    kong.log.inspect(data.old_entity) -- old entity table (only for "update")
    kong.log.inspect(data.entity)     -- new entity table
    kong.log.inspect(data.schema)     -- entity's schema
  end, "crud", "consumers:update")
end

一旦上述侦听器适用于所需的实体,您就可以根据需要对插件已缓存的任何实体执行手动失效。 例如:

kong.worker_events.register(function(data)
  if data.operation == "delete" then
    local cache_key = data.entity.id
    kong.cache:invalidate("prefix:" .. cache_key)
  end
end, "crud", "consumers")

扩展Admin API

您可能已经知道,Admin API是Kong用户与Kong通信以设置其API和插件的地方。他们可能还需要能够与您为插件实现的自定义实体进行交互(例如,创建和删除API密钥)。这样做的方法是扩展Admin API,我们将在下一章详细介绍:扩展Admin API

微服务 API 网关 Kong 插件开发 – 实现自定义逻辑

简介

Kong插件允许您在 request/response 的生命周期中的几个入口点注入自定义逻辑(使用 Lua 语言),因为它由Kong代理。为此,必须实现base_plugin.lua 接口的一个或多个方法。这些方法将在命名空间下的模块中实现:kong.plugins。<plugin_name> .handler

Module

kong.plugins.<plugin_name>.handler

可用的请求上下文

插件接口允许您覆盖handler.lua文件中的以下任何方法,以在Kong的执行生命周期的各个入口点实现自定义逻辑:

函数名 LUA-NGINX-MODULE Context 描述
:init_worker() init_worker_by_lua 在每个 Nginx 工作进程启动时执行
:certificate() ssl_certificate_by_lua 在SSL握手阶段的SSL证书服务阶段执行
:rewrite() rewrite_by_lua 从客户端接收作为重写阶段处理程序的每个请求执行。在这个阶段,无论是API还是消费者都没有被识别,因此这个处理器只在插件被配置为全局插件时执行
:access() access_by_lua 为客户的每一个请求而执行,并在它被代理到上游服务之前执行
:header_filter() header_filter_by_lua 从上游服务接收到所有响应头字节时执行
:body_filter() body_filter_by_lua 从上游服务接收的响应体的每个块时执行。由于响应流回客户端,它可以超过缓冲区大小,因此,如果响应较大,该方法可以被多次调用
:log() log_by_lua 当最后一个响应字节已经发送到客户端时执行

所有这些函数都使用一个参数,该参数由Kong在调用时给出:插件的配置。此参数是Lua表,并包含用户根据插件的架构(在schema.lua模块中描述)定义的值。有关插件模式的更多信息将在下一章中介绍。

handler.lua规范

handler.lua文件必须返回一个表,该表实现了您希望执行的函数。为简洁起见,这里有一个注释示例模块,它实现了所有可用的方法:

-- 扩展基本插件处理程序是可选的,因为Lua中没有真正的接口概念,
-- 但是基本插件处理程序的方法可以从子实现中调用,
-- 并将在“error.log”中打印日志(其中打印所有日志)。
local BasePlugin = require "kong.plugins.base_plugin"
local CustomHandler = BasePlugin:extend()

-- 你的插件处理程序的构造函数。
-- 如果要扩展基本插件处理程序,它的唯一作用就是用名称实例化自己。
-- 该名称是您的插件名称,因为它将打印在日志中
function CustomHandler:new()
  CustomHandler.super.new(self, "my-custom-plugin")
end

function CustomHandler:init_worker()
  -- 最终,执行父实现
  -- (将记录您的插件正在进入此上下文)
  CustomHandler.super.init_worker(self)

  -- 在此实现任何自定义逻辑
end

function CustomHandler:certificate(config)
  -- 最终,执行父实现
  -- (将记录您的插件正在进入此上下文)
  CustomHandler.super.certificate(self)

  -- Implement any custom logic here
end

function CustomHandler:rewrite(config)
  -- Eventually, execute the parent implementation
  -- (will log that your plugin is entering this context)
  CustomHandler.super.rewrite(self)

  -- Implement any custom logic here
end

function CustomHandler:access(config)
  -- Eventually, execute the parent implementation
  -- (will log that your plugin is entering this context)
  CustomHandler.super.access(self)

  -- Implement any custom logic here
end

function CustomHandler:header_filter(config)
  -- Eventually, execute the parent implementation
  -- (will log that your plugin is entering this context)
  CustomHandler.super.header_filter(self)

  -- Implement any custom logic here
end

function CustomHandler:body_filter(config)
  -- Eventually, execute the parent implementation
  -- (will log that your plugin is entering this context)
  CustomHandler.super.body_filter(self)

  -- Implement any custom logic here
end

function CustomHandler:log(config)
  -- Eventually, execute the parent implementation
  -- (will log that your plugin is entering this context)
  CustomHandler.super.log(self)

  -- Implement any custom logic here
end

-- 该模块需要返回创建的表
-- 让Kong 可以执行这些功能。
return CustomHandler

当然,插件本身的逻辑可以抽象到另一个模块中,并从处理程序模块调用。许多现有的插件在逻辑冗长时已经选择了这种模式,但它是完全可选的:

local BasePlugin = require "kong.plugins.base_plugin"

-- 实际的逻辑是在这些模块中实现的
local access = require "kong.plugins.my-custom-plugin.access"
local body_filter = require "kong.plugins.my-custom-plugin.body_filter"

local CustomHandler = BasePlugin:extend()

function CustomHandler:new()
  CustomHandler.super.new(self, "my-custom-plugin")
end

function CustomHandler:access(config)
  CustomHandler.super.access(self)

  -- 从“access”中加载的模块执行任何函数,
  -- 例如,`execute()`并将插件的配置传递给它。
  access.execute(config)
end

function CustomHandler:body_filter(config)
  CustomHandler.super.body_filter(self)

  -- Execute any function from the module loaded in `body_filter`,
  -- for example, `execute()` and passing it the plugin's configuration.
  body_filter.execute(config)
end

return CustomHandler

有关实际处理程序代码的示例,请参阅Key-Auth插件的源代码

插件开发套件

在这些阶段中实现的逻辑很可能必须与请求/响应对象或核心组件交互(例如访问缓存、数据库……)。Kong提供了一个插件开发套件(简称PSK),一组Lua函数和变量,插件可以使用这些Lua函数和变量来执行各种网关操作,确保它们与将来的Kong版本向前兼容。

当您试图实现一些需要与Kong交互的逻辑时(例如检索请求头、从插件生成响应、记录一些错误或调试信息……),您应该参考插件开发工具包

插件执行顺序

一些插件可能依赖于其他插件的执行来执行一些操作。例如,依赖于消费者身份的插件必须在身份验证插件之后运行。考虑到这一点,Kong定义了插件执行之间的优先级,以确保顺序得到遵守。

你的插件的优先级可以通过一个属性来配置,在返回的handler table 中一个数字:

CustomHandler.PRIORITY = 10

优先级越高,相对于其他插件的阶段(如:access()、:log()等),插件的阶段执行得越快。 已有捆绑插件的当前执行顺序为:

插件 优先级
pre-function +inf
zipkin 100000
ip-restriction 3000
bot-detection 2500
cors 25000
jwt 1005
oauth2 1004
key-auth 1003
ldap-auth 1002
basic-auth 1001
hmac-auth 1000
request-size-limiting 951
acl 950
rate-limiting 901
response-ratelimiting 900
request-transformer 801
response-transformer 800
aws-lambda 750
azure-functions 749
prometheus 13
http-log 12
statsd 11
datadog 10
file-log 9
udp-log 8
tcp-log 7
loggly 6
syslog 4
galileo 3
request-termination 2
correlation-id 1
post-function -1000

在Kong的插件中使用自建数据表的问题

目前正在开发的kong 插件中需要用到自己新建表,然后对其进行读写,但是由于kong的版本升级原因,有一些问题在官方文档中没有提到,导致一直读取失败,主要注意的点如下:

1.迁移文件的差异

kong的版本>= 1.0

迁移文件的名字为000_base_xxx.lua,其中格式格式如下:

return {
   postgres = {
       up = [[
         CREATE TABLE IF NOT EXISTS "xxxxx" (
           "id"	uuid	NOT NULL   DEFAULT uuid_generate_v4()   PRIMARY KEY,
           "xx"	int	NOT NULL,
           "xx"	bool,
           "xx"	json,
           "xx"	json
         );
       ]],
   },
   cassandra ={
       up =[[

       ]]
   }
}

kong的版本小于1.0版本

迁移文件的名字为postgres.luacassandra.lua,其中格式如下: 此为postgres.lua

 return {
  {
    name = "2015-07-31-172400_init_keyauth",
    up = [[
      CREATE TABLE IF NOT EXISTS keyauth_credentials(
        id uuid,
        consumer_id uuid REFERENCES consumers (id) ON DELETE CASCADE,
        key text UNIQUE,
        created_at timestamp without time zone default (CURRENT_TIMESTAMP(0) at time zone 'utc'),
        PRIMARY KEY (id)
      );

      DO $$
      BEGIN
        IF (SELECT to_regclass('public.keyauth_key_idx')) IS NULL THEN
          CREATE INDEX keyauth_key_idx ON keyauth_credentials(key);
        END IF;
        IF (SELECT to_regclass('public.keyauth_consumer_idx')) IS NULL THEN
          CREATE INDEX keyauth_consumer_idx ON keyauth_credentials(consumer_id);
        END IF;
      END$$;
    ]],
    down = [[
      DROP TABLE keyauth_credentials;
    ]]
  }
}

2.daos.lua的差异

daos.lua的格式也是有差异的,但是这部分的差异在文档中是没有体现的

kong的版本>= 1.0

local typedefs = require "kong.db.schema.typedefs"

local xxx = {
   primary_key = { "id" },
   name = "app_config",
   fields = {
       { id = typedefs.uuid },
       { xx = { type = "string", required = false, unique = true }, },
       { xx = { type = "string", required = false, unique = true } },
       { xx = { type = "string", required = false } },
       { xx = { type = "string", required = false } },
       { xx = { type = "string", required = false } }
   }
}
return {
   zz = xxx,
}

kong的版本小于1.0版本

-- daos.lua
local SCHEMA = {
  primary_key = {"id"},
  table = "keyauth_credentials", -- the actual table in the database
  fields = {
    id = {type = "id", dao_insert_value = true}, -- a value to be inserted by the DAO itself (think of serial ID and the uniqueness of such required here)
    created_at = {type = "timestamp", immutable = true, dao_insert_value = true}, -- also interted by the DAO itself
    consumer_id = {type = "id", required = true, foreign = "consumers:id"}, -- a foreign key to a Consumer's id
    key = {type = "string", required = false, unique = true} -- a unique API key
  }
}
return {keyauth_credentials = SCHEMA} -- this plugin only results in one custom DAO, named `keyauth_credentials`

尤其注意fields字段的结构差异,不然很容易弄混

3.调用差异

kong的版本>= 1.0

-- 通过某个字段查询
local app_configs, err = kong.db.app_config:select_by_app_key(app_key)
-- 通过主键查询
local app_group_configs, err = kong.db.app_group_config:select({ id = group_id })

kong的版本小于1.0版本

local app_configs, err = kong.dao.app_config:find()
local app_configs, err = kong.dao.app_config:find_all()

微服务 API 网关 Kong 插件开发 – 访问数据存储区

原文地址:https://docs.konghq.com/1.1.x/plugin-development/access-the-datastore/ (不能保证所有的翻译都是准确无误的,所有如有翻译的不准确或错误之处,请一定记得查看原文,并欢迎留言指出)。

简介

Kong通过我们称为“DAOs”的类与模型层交互。本章将详细介绍与数据存储交互的可用API。Kong支持两个主数据存储:Cassandra 3.x.xPostgreSQL 9.5+

kong.db

Kong 的所有实例表示为:

  • 描述实体在数据存储区中与哪个表相关的模式,对其字段的约束,如外键,非空约束等…此schema是插件配置章节中描述的表。
  • DAO类的一个实例映射到当前正在使用的数据库(Cassandra或PostgreSQL)。此类的方法使用模式并公开方法来插入,更新,查找和删除该类型的实体。

Kong的核心实体是:Services, Routes, Consumers 和 Plugins。所有这些都可以作为数据访问对象(DAO)通过kong.db全局单例访问:

-- Core DAOs
local services_dao = kong.db.services
local routes_dao = kong.db.routes
local consumers_dao = kong.db.consumers
local plugins_dao = kong.dao.plugins

来自Kong的核心实体和插件中的自定义实体都可以通过kong.db.*

The DAO Lua API

DAO类负责在数据存储区中的给定表上执行的操作,通常映射到Kong的实体。所有底层支持的数据库(目前是Cassandra和PostgreSQL)都遵循相同的接口,从而使DAO与所有这些兼容。 例如,插入服务和插件非常简单:

local inserted_service, err = kong.db.services:insert({
  name = "mockbin",
  url = "http://mockbin.org",
})

local inserted_plugin, err = kong.db.plugins:insert({
  name = "key-auth",
  service_id = { id = inserted_service.id },
})

有关在插件中使用的DAO的实际示例,请参阅 Key-Auth plugin 的源代码