Kong 2.3.0-rc.1 available

Hi everyone,

We are happy to announce the release candidate for Kong 2.3! :gorilla:

This includes all fixes and adjustments made since we entered feature freeze with Kong 2.3.0-beta.1 last December, and as such there are no new features over that release, and of course no breaking changes with respect to the 2.x series.

If no serious issues are reported, this release will effectively be promoted to the stable 2.3.0 release, so this is now the best time to test the new features and report any issues!

What’s New Since 2.3.0-beta.1
Here’s a summary of the fixes added since the beta release:

  • Core

    • Several fixes were done to the schemas and schemas validations, with great improvements on the cache of full-schema validations, avoiding memory leaks when reloading declarative configs.
    • Kong now uses updated versions of lua-resty-dns-client and lua-resty-healthcheck which use a lot fewer resources than before.
    • Secure connections to Postgres databases is another feature with important fixes in this release.
  • Plugins

    • The serverless-functions plugin now has improved capabilities on sandboxing!

Download
Please note that the download locations for prereleases are kept separate from the final release locations:

:package: You can download packages
:whale2: or use the unofficial kong/kong docker repository
:spiral_notepad: More details and PR links are available at the 2.3.0 Changelog.

Feedback welcome!
Again, we encourage you to try the release candidate and report any issues in Kong’s Github repo. Feedback is extremely welcome!

:gorilla: Happy Konging! :gorilla:

1 Like

We are using kong.conf to configure properties with default values. Some of those values are overridden by environment variable.
However, after upgrading form 2.2.0 to 2.3.0, the environment variables are ignored and the values are set only according to kong.conf.

Can it be related to the following change?

In case it matters - we are running kong with custom nginx configuration (using custom_nginx.template) using those commands

nginx -p <kong-folder> -c nginx.conf
nginx
1 Like

In my experience, this is sometimes caused by a corrupted .kong_env file. This file should be recreated each time Kong is started with the right mix of kong.conf and environment vars. But if it gets corrupted, the new values sometimes get appended at the end and do not replace the originals.

Just remove that file (typically at /usr/local/kong/.kong_env) and restart.

Thanks but it is not the case - we are deleting the file before kong is starting.
It used to work before the upgrade…

So I narrowed the issue:

Our flow is

  1. Run kong prepare -p <kong-dir> --nginx-conf <kong-dir>/custom_nginx.template --conf <kong-dir>/kong.conf
  2. Set some environment variables
  3. Run nginx -p <kong-folder> -c nginx.conf

The env variables that were set after kong prepare are not taking into account although they used to in the previous versions

I attached the wrong suspicious commit. This is the one I meant to mention:

The issue here is that in case you run Kong using the nginx -p <kong-folder> -c nginx.conf command, then .kong_env does not get recreated when Kong starts.
.kong_env is only created by the kong prepare command.

In 2.2.x, when Kong was started it merged values from .kong_env with environment variables starting with KONG_, giving precedence to the environment variables.

In Kong 2.3.x, when Kong is started, it no longer reads environment variables starting with KONG_. Instead, only the Kong prepare command reads environment variables, and writes them (in combination with default values and values from kong.conf) into .kong_env.

The reason is the enclosing of the code which reads environment variables inside an “if” which always evaluates to false, thus that block of code is never entered. It’s inside kong/conf_loader/init.lua:

  if not opts.from_kong_env then
    -- environment variables have higher priority

    local env_name = "KONG_" .. string.upper(k)
    local env = os.getenv(env_name)
    if env ~= nil then
      local to_print = env

      if CONF_SENSITIVE[k] then
        to_print = CONF_SENSITIVE_PLACEHOLDER
      end

      log.debug('%s ENV found with "%s"', env_name, to_print)

      value = env
      escape = true
    end
  end

The condition at the first line above always evaluates to false, because opts.from_kong_env is hardcoded to be true.

As mentioned by Ayala (my collegue), this is the offending commit: