1

We're trying to set up Kong using Helm. We have a custom plugin that we want to load and enable, as part of the deployment process. The plugin has migrations, so folder structure looks like:

plugin-folder
|- handler.lua
|- schema.lua
|- daos.lua
|- migrations
   |- init.lua
   |- 000_base.lua

Now, we've gotten helm to install Kong and we've managed to load the plugin, by creating a configMap, using the root of the folder as --from-path when creating the configMap. Unfortunately, configMaps are flat, so the created map did not include the migrations, and it doesn't look like it can.

This seems to suggest, that using configMaps/secrets for loading custom plugins into Kong just won't work, if you need to run migrations.

We've tried to create the configMap from a packed .rock file as well - this did not work, far as I could see.

Edit 1

By reading the values.yml file that is available in the Helm charts for kong, I've come across this:

# Custom Kong plugins can be loaded into Kong by mounting the plugin code
# into the file-system of Kong container.
# The plugin code should be present in ConfigMap or Secret inside the same
# namespace as Kong is being installed.
# The `name` property refers to the name of the ConfigMap or Secret
# itself, while the pluginName refers to the name of the plugin as it appears
# in Kong.
# Subdirectories (which are optional) require separate ConfigMaps/Secrets.
# "path" indicates their directory under the main plugin directory: the example
# below will mount the contents of kong-plugin-rewriter-migrations at "/opt/kong/rewriter/migrations".
plugins: {}
  # configMaps:
  # - pluginName: rewriter
  #   name: kong-plugin-rewriter
  #   subdirectories:
  #   - name: kong-plugin-rewriter-migrations
  #     path: migrations

So, in other words, you use another configmap to mount in the migrations folder. This works now and Kong loads the plugin and sees the migrations folder.

HOWEVER, another problem immediately presented itself: Kong didn't run those migrations. Instead, the init container for Kong (the wait-for-db container) just got stuck in a loop. It saw that the database was ready, but there were migrations available, so it never moved on.

What we're seeing is:

nginx: [error] init_by_lua error: /usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:20: New migrations available; run 'kong migrations up' to proceed
stack traceback:
        [C]: in function 'error'
        /usr/local/share/lua/5.1/kong/cmd/utils/migrations.lua:20: in function 'check_state'
        /usr/local/share/lua/5.1/kong/init.lua:506: in function 'init'
        init_by_lua:3: in main chunk

Edit 2

Turns out that uninstalling and installing made it work. Seems a glitch caught it in a loop the first time round - second time, no such problems.

Peter Lind
  • 37
  • 7

0 Answers0