Kong - custom plugins returning: custom-plugin plugin is enabled but not installed; Kong - custom plugins returning: custom-plugin plugin is enabled but not installed; docker docker

Kong - custom plugins returning: custom-plugin plugin is enabled but not installed;


Check these resources out:

Bug Report from Kong: https://github.com/Kong/kong/issues/4696

I don't think it's the luarocks' problemIndeed, I installed kong in docker whose image is built by a dockerfile.In my docker file, I went into the folder which store the custom plugins,and then traverse and luarocks make them by shell.It looks like:#install private pluginscd APIGPluginsfor dir in `ls`; do    if [ -d $dir ]; then      cd $dir;      luarocks make;      cd ../;    fidoneand then, I run the docker images for a container by the directive:sudo docker run -d --name kong \    -e "KONG_DATABASE=off" \    -e "KONG_DECLARATIVE_CONFIG=/etc/kong/kong.yml" \    -e "KONG_PLUGINS=apig-response-transform" \    -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-plugin:v4As u see, I set the kong plugin by the docker run env variable parameter for enable the plugin instead of setting in the kong.conf.The logs were generated by directive of docker logs "container ID"It works when I tried to install another custom plugin in this way,but not work when install the custom plugin I described before

Update

you need to install the lua-package manager luarocks


See if one of the instructions from Kong/kong-plugin-zipkin issue 5 (another plugin which depends on kong.plugins.custom-plugin.handler) would work for kong.plugins.custom-plugin.handler itself.

The gist of it is that the plugin should be available to Kong on disk, and added to the custom_plugins configuration property.

You can achieve this via various ways:

Don't forget that you can also specify configure Kong with environment variables, so using -e KONG_CUSTOM_PLUGINS=my-custom-plugin would also work.

The plugin also needs to be in the LUA_PATH (like PATH, but for Lua modules).

So, in short, one of the possible solutions would be to use volumes and environment variables:

  • Mount the plugin's code: -v /path/to/my-custom-plugin:/etc/kong/plugins/my-custom-plugin
  • Add the directory containing custom plugins to the LUA_PATH: -e KONG_LUA_PACKAGE_PATH=/etc/?.lua (Kong requires kong.plugins.custom-plugin.handler, which translates to /etc/kong/plugins/my-custom-plugin/handler.lua)
  • Instruct Kong to load the plugin with: -e KONG_CUSTOM_PLUGINS=my-custom-plugin

Follwing that, check first if this is a KONG_LUA_PATH problem, as in Kong/kong issue 3394.

This was about plugin migration, but might have an impact here as well.

as a short term solution, you should set your LUA_PATH environment variable to point to your custom plugin's installation path
(instead of lua_package_path in kong.conf or KONG_LUA_PACKAGE_PATH).

E.g. I just moved:

export KONG_LUA_PACKAGE_PATH="/path/to/some-custom-plugin/?.lua;;"

to:

export LUA_PATH="/path/to/some-custom-plugin/?.lua;$LUA_PATH"

And ran kong migrations up again, which successfully ran the plugin's migration.

That is because lua_package_path is only for runtime Kong (within nginx), and is not being considered by the CLI (the kong migrations command)

If I just commented the lua_package_path in kong.conf and exported LUA_PATH as you mentioned, it started giving me this error:

./kong:3: module 'luarocks.loader' not found:

The shell from which I am executing kong migrations up never had LUA_PATH set, even before. It appears luarocks internally creates LUA_PATH if it is not already set in the shell.

So the additional step I had to perform was to get the current LUA_PATH that's set internally by running "luarocks path" command and then take the result of that, and append my custom login plugin path to it and then export that LUA_PATH to get this to work.

Again, even this your current issue is not about migration, one of those variables might help.