关于目录结构:

目录结构是这种, 下面两个是必须有的module, 我假设你跟我一样没有太多的lua背景知识, handler.lua 和 schema.lua 是两个module的名字, 也是两个文件, 文件夹是 simple-plugin

复杂一点的可能像这样

关于如何加入自己plugin:

在/etc/kong/kong.conf文件中你可以找到下面这段

plugins = bundled

plugins = bundled,my-custom-plugin # your plugin name here

自定义插件的命名个规则为 kong.plugins.<plugin_name>.<module_name>

也就是说当你在plugins属性后面添加了你自己的plugin name之后, kong会尝试加载以kong.plugins.my-custom-plugin.<module_name>命名的lua模块

还记得一开始提到的两个必要模块名么, 所以你的模块应该类似 kong.plugins.my-custom-plugin.handler

关于kong到哪里加载这些文件:

还是/etc/kong/kong.conf, 其中属性 lua_package_path 可以用来指定存放自定义插件的路径

官方文档中这样描述这个配置

也就是说如果你配置

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

那么你的handler.lua文件要放在

/usr/local/custom/kong/plugins/<plugin-name>/handler.lua

下面是一个完整例子, 不过这个例子里的plugin是空的, 什么都没做, 我将对应着上面的内容写

关于目录结构:

我只使用了两个文件 ( 文件内容最后再发 )

/shared/kongplugins/kong/plugins/my-custom-plugin/handler.lua

/shared/kongplugins/kong/plugins/my-custom-plugin/schema.lua

关于如何加入自己plugin:

在/etc/kong/kong.conf文件中加入对应的模块名

plugins = bundled,my-custom-plugin

关于kong到哪里加载这些文件:

在/etc/kong/kong.conf文件中加入对应的模块存放文件夹路径

lua_package_path = ./?.lua;./?/init.lua;/shared/kongplugins/?.lua;

最后把kong启动起来, 添加一个global的自定义插件吧


[root@localhost ~]# kong start

2018/11/23 10:42:57 [warn] ulimit is currently set to "1024". For better performance set it to at least "4096" using "ulimit -n"

Kong started

[root@localhost ~]# curl -X POST http://localhost:8001/plugins -d "name=my-custom-plugin"

{"created_at":1542966253000,"config":{},"id":"1029886c-6c18-4d98-9e4d-8565ec47c41e","enabled":true,"name":"my-custom-plugin"}

打开dashboard可以看到

schema.lua文件

return {

no_consumer = true,

fields = {

}

}

handler.lua文件

-- Extending the Base Plugin handler is optional, as there is no real

-- concept of interface in Lua, but the Base Plugin handler's methods

-- can be called from your child implementation and will print logs

-- in your `error.log` file (where all logs are printed).

local BasePlugin = require "kong.plugins.base_plugin"

local CustomHandler = BasePlugin:extend()

 

-- Your plugin handler's constructor. If you are extending the

-- Base Plugin handler, it's only role is to instantiate itself

-- with a name. The name is your plugin name as it will be printed in the logs.

function CustomHandler:new()

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

end

 

function CustomHandler:init_worker()

-- Eventually, execute the parent implementation

-- (will log that your plugin is entering this context)

CustomHandler.super.init_worker(self)

 

-- Implement any custom logic here

end

 

function CustomHandler:certificate(config)

-- Eventually, execute the parent implementation

-- (will log that your plugin is entering this context)

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

 

-- This module needs to return the created table, so that Kong

-- can execute those functions.

return CustomHandler