DEVELOPER.md
We encourage community contributions to Kong. To make sure it is a smooth experience (both for you and for the Kong team), please read CONTRIBUTING.md, CODE_OF_CONDUCT.md, and COPYRIGHT before you start.
If you are planning on developing on Kong, you'll need a development
installation. The master branch holds the latest unreleased source code.
You can read more about writing your own plugins in the Plugin Development Guide, or browse an online version of Kong's source code documentation in the Plugin Development Kit (PDK) Reference.
For a quick start with custom plugin development, check out Pongo and the plugin template explained in detail below.
Kong comes in many shapes. While this repository contains its core's source code, other repos are also under active development:
master branch.You can find every supported distribution on the official installation page.
Pongo is a CLI tool that are specific for plugin development. It is docker-compose based and will create local test environments including all dependencies. Core features are running tests, integrated linter, config initialization, CI support, and custom dependencies.
The plugin template provides a basic plugin and is considered a best-practices plugin repository. When writing custom plugins, we strongly suggest you start by using this repository as a starting point. It contains the proper file structures, configuration files, and CI setup to get up and running quickly. This repository seamlessly integrates with Pongo.
This is the hard way to build a development environment, and also a good start for beginners to understand how everything fits together.
Kong is mostly an OpenResty application made of Lua source files, but also requires some additional third-party dependencies, some of which are compiled with tweaked options, and kong runs on a modified version of OpenResty with patches.
To install from the source, first, we clone the repository:
git clone https://github.com/Kong/kong
cd kong
# You might want to switch to the development branch. See CONTRIBUTING.md
git checkout master
Then we will install the dependencies:
Ubuntu/Debian:
sudo apt update \
&& sudo apt install -y \
automake \
build-essential \
curl \
file \
git \
libyaml-dev \
libprotobuf-dev \
m4 \
perl \
pkg-config \
procps \
unzip \
valgrind \
zlib1g-dev
Fedora/RHEL:
dnf install \
automake \
gcc \
gcc-c++ \
git \
libyaml-devel \
make \
patch \
perl \
perl-IPC-Cmd \
protobuf-devel \
unzip \
valgrind \
valgrind-devel \
zlib-devel
macOS
# Install Xcode from App Store (Command Line Tools is not supported)
# Install HomeBrew
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
# Build dependencies
brew install libyaml
Now, you have to authenticate with GitHub to download some essential repos using either one of the following ways:
gh cli and run gh auth login once.Public Repositories (read-only), and set it as GITHUB_TOKEN environment variable.Then you have to make the Rust build system also authenticate with GitHub,
there is nothing you need to do if you were authenticated using gh or git credential helper,
otherwise, you can set theCARGO_NET_GIT_FETCH_WITH_CLI
environment variable to true.
export CARGO_NET_GIT_FETCH_WITH_CLI=true
An alternative is to edit the ~/.cargo/config file and add the following lines:
[net]
git-fetch-with-cli = true
You also have to make sure the git CLI is using the proper protocol to fetch the dependencies
if you are authenticated with
Personal Access Token.
# If you are using the HTTPS protocol to clone the repository
# YOU ONLY NEED TO DO THIS ONLY ONCE FOR THIS DIRECTORY
git config --local url."https://${GITHUB_TOKEN}@github.com/".insteadOf '[email protected]:'
git config --local url."https://${GITHUB_TOKEN}@github.com".insteadOf 'https://github.com'
# If you are using the SSH protocol to clone the repository
# YOU ONLY NEED TO DO THIS ONLY ONCE FOR THIS DIRECTORY
git config --local url.'[email protected]:'.insteadOf 'https://github.com'
git config --local url.'ssh://[email protected]/'.insteadOf 'https://github.com/'
Finally, we start the build process:
# Build the virtual environment for developing Kong
make build-venv
The build guide contains a troubleshooting section if you face any problems. It also describes the build process in detail, if you want to development on the build system itself.
Now you can start Kong:
# Activate the venv by adding some environment variables and populate helper functions
# into your current shell session, following functions are exported:
# `start_services`, `stop_services` and `deactivate`
# For Zsh/Bash:
. bazel-bin/build/kong-dev-venv.sh
# For Fish Shell:
. bazel-bin/build/kong-dev-venv.fish
# Use the pre-defined docker-compose file to bring up databases etc
start_services
# Bootstrap the database
kong migrations bootstrap
# Start Kong!
kong start
# Stop Kong
kong stop
# Cleanup
deactivate
By default, the development environment adds current directory to Lua files search path.
Modifying the lua_package_path
and lua_package_cpath
directives will allow Kong to find your custom plugin's source code wherever it
might be in your system.
Install the development dependencies (busted, luacheck) with:
make dev
If Rust/Cargo doesn't work, try setting export KONG_TEST_USER_CARGO_DISABLED=1 first.
Kong relies on three test suites using the busted testing library:
The first can simply be run after installing busted and running:
make test
However, the integration and plugins tests will spawn a Kong instance and
perform their tests against it. Because these test suites perform their tests
against the Kong instance, you may need to edit the spec/kong_tests.conf
configuration file to make your test instance point to your Postgres/Cassandra
servers, depending on your needs.
You can run the integration tests (assuming both Postgres and Cassandra are
running and configured according to spec/kong_tests.conf) with:
make test-integration
And the plugins tests with:
make test-plugins
Finally, all suites can be run at once by simply using:
make test-all
Consult the test_suites.json json file for more advanced example usage of the test suites and the Makefile.
Finally, a very useful tool in Lua development (as with many other dynamic
languages) is performing static linting of your code. You can use
luacheck
(installed with make dev) for this:
make lint
Kong Gateway supports no-downtime upgrades through its database schema
migration mechanism (see UPGRADE.md). Each schema
migration needs to be written in a way that allows the previous and
the current version of Kong Gateway run against the same database
during upgrades. Once all nodes have been upgraded to the current
version of Kong Gateway, additional changes to the database can be
made that are incompatible with the previous version. To support
that, each migration is split into two parts, an up part that can
only make backwards-compatible changes, and a teardown part that
runs after all nodes have been upgraded to the current version.
Each migration that is contained in Kong Gateway needs to be
accompanied with a test that verifies the correct operation of both
the previous and the current version during an upgrade. These tests
are located in the spec/05-migration/ directory
and must be named after the migration they test such that the
migration kong/**/*.lua has a test in
spec/05-migration/**/*_spec.lua. The presence of a test is enforced
by the upgrade testing shell script
which is automatically run
through a GitHub Action.
The upgrade testing shell script works as follows:
kong migrations bootstrap.setup phase of all applicable migration tests is run.kong migrations up is run to run the up part of all
applicable migrations.old_after_up phase of all applicable migration tests is
run.new_after_up phase of all applicable migration tests is
run.kong migrations finish is run to invoke the teardown part
of all applicable migrations.new_after_finish phase of all applicable migration tests
is run.Upgrade tests are run using busted.
To support the specific testing
method of upgrade testing, a number of helper functions are defined in
the spec/upgrade_helpers.lua module.
Migration tests use functions from this module to define test cases
and associate them with phases of the upgrade testing process.
Consequently, they are named setup, old_after_up, new_after_up
and new_after_finish. Additionally, the function all_phases can be
used to run a certain test in the three phases old_after_up,
new_after_up and new_after_finish. These functions replace the
use of busted's it function and accept a descriptive string and a
function as argument.
It is important to note that upgrade tests need to run on both the old and the new version of Kong. Thus, they can only use features that are available in both versions (i.e. from helpers.lua). The module spec/upgrade_helpers.lua is copied from the new version into the container of the old version and it can be used to make new library functionality available to migration tests.
When developing, you can use the Makefile for doing the following operations:
| Name | Description |
|---|---|
install | Install the Kong luarock globally |
dev | Install development dependencies |
lint | Lint Lua files in kong/ and spec/ |
test | Run the unit tests suite |
test-integration | Run the integration tests suite |
test-plugins | Run the plugins test suite |
test-all | Run all unit + integration + plugins tests at once |
You can follow the steps given below to setup a hybrid mode environment.
Activate the venv
# . bazel-bin/build/kong-dev-venv.sh
Following Deploy Kong Gateway in Hybrid Mode: Generate certificate/key pair to generate a certificate/key pair.
Create CP and DP configuration files, such as kong-cp.conf and kong-dp.conf.
Following Deploy Kong Gateway in Hybrid Mode: CP Configuration to configure CP using kong.conf.
Following Deploy Kong Gateway in Hybrid Mode: DP Configuration to configure DP using kong.conf.
Unset environment variable KONG_PREFIX to ensure configuration directive prefix in configuration file is enabled.
Modify or add the directive prefix to kong-cp.conf and kong-dp.conf
to be prefix=servroot-cp and prefix=servroot-dp,
or other names you want, but make sure they are different.
Use the pre-defined docker-compose file to bring up databases, etc.
# start_services
If it is the first time to start Kong, you have to execute the following command to CP node.
# kong migrations bootstrap -c kong-cp.conf
Start CP and DP. kong start -c kong-cp.conf and kong start -c kong-dp.conf.
To stop CP and DP, you can execute kong stop -p servroot-cp and
kong stop -p servroot-dp in this example.
Names servroot-cp and servroot-dp are set in configuration file in step 7.
If you have a Linux development environment (either virtual or bare metal), the build is done in four separate steps:
Final deployments are typically on a Linux machine or container, so even if all components are multiplatform, it's easier to use it for development too. If you use macOS or Windows machines, setting up a virtual machine is easy enough now. Most of us use the freely available VirtualBox without any trouble.
If you use Linux for your desktop, you can skip this section.
There are no "hard" requirements on any Linux distro, but RHEL and CentOS can be more of a challenge to get recent versions of many packages; Fedora, Debian, or Ubuntu are easier for this.
To avoid long compilation times, give the VM plenty of RAM (8GB recommended) and all the CPU cores you can.
You will need to setup port forwarding on VirtualBox to be able to ssh into the box which can be done as follows:
Now you should be able to ssh <your_name>@127.1 -p 22222 to get SSH prompt. However, this requires us to type a long command and password every time we sign in. It is recommended you set up a public key and SSH alias to make this process simpler:
ssh-keygen -t ed25519.
Just keep hitting Enter until the key is generated. You do not need a password for this key file since it is only used for SSH into your guestcat .ssh/id_ed25519.pub and copy the public key$ mkdir -p .sshvim .ssh/authorized_keyschmod 700 .ssh/ and chmod 400 .ssh/authorized_keys Host dev
HostName 127.1
Port 22222
User <your_user_name>
Now try ssh dev on your host, you should be able to get into the guest directly.
The devcontainer.json file in Kong's project tells VS Code
how to access (or create) a development container with a well-defined tool and runtime stack.
EmmyLua is a plugin for IntelliJ IDEA and VSCode that provides Lua language support. It comes with debugger support that makes it possible to set breakpoints in Lua code and inspect variables. Kong Gateway can be debugged using EmmyLua by following these steps:
Download and install IntelliJ IDEA from here. Note that IntelliJ is a commercial product and requires a paid license after the trial period.
Download and install MS Visual Studio Code from here.
Go to the Settings->Plugins->Marketplace and search for EmmyLua.
Install the plugin.
Go to the Settings->Extensions and search for EmmyLua.
Install the plugin (publisher is Tangzx).
The EmmyLuaDebugger is a standalone C++ program that runs on the same machine as Kong Gateway and that mediates between the IDE's debugger and the Lua code running in Kong Gateway. It can be downloaded from GitHub. The release ZIP file contains a single shared library named emmy_core.so (Linux) or emmy_core.dylib (macOS). Place this file in a directory that is convenient for you and remember the path.
Depending on your Linux version, you may need to compile EmmyLuaDebugger on your own system as the release binaries published on GitHub assume a pretty recent version of GLIBC to be present.
To enable the EmmyLua debugger, the KONG_EMMY_DEBUGGER environment variable must be set to
the absolute path of the debugger shared library file when Kong Gateway is started. It is
also advisable to start Kong Gateway with only one worker process, as debugging multiple worker
processes requires special care. For example:
KONG_EMMY_DEBUGGER=/path/to/emmy_core.so KONG_NGINX_WORKER_PROCESSES=1 kong start
Go to Run->Edit Configurations and click the + button to add a new
configuration. Select Emmy Debugger(NEW) as the configuration type. Enter a descriptive
name for the configuration, e.g. "Kong Gateway Debug". Click OK to save the configuration.
Go to Run->Add Configuration and choose EmmyLua New Debugger. Enter a descriptive name
for the configuration, e.g. "Kong Gateway Debug". Save launch.json.
To connect the EmmyLua debugger to Kong Gateway, click the Run->Debug menu item in IntelliJ
(Run->Start Debugging in VSCode) and select the configuration that you've just created. You
will notice that the restart and stop buttons on the top of your IDE will change to solid green
and red colors. You can now set breakpoints in your Lua code and start debugging. Try setting
a breakpoint in the global access function that is defined runloop/handler.lua and send
a proxy request to the Gateway. The debugger should stop at the breakpoint and you can
inspect the variables in the request context.
busted testsTo debug busted tests, you can set the BUSTED_EMMY_DEBUGGER environment variable to the path
to the EmmyLua debugger shared library. When debugging is enabled, busted will always wait for
the IDE to connect during startup.
The following environment variables can be set to control the behavior of the EmmyLua debugger integration:
KONG_EMMY_DEBUGGER: The path to the EmmyLua debugger shared library.KONG_EMMY_DEBUGGER_HOST: The IP address that the EmmyLua debugger will listen on. The default
is localhost.KONG_EMMY_DEBUGGER_PORT: The port that the EmmyLua debugger will listen on. The default is
9966.KONG_EMMY_DEBUGGER_WAIT: If set, Kong Gateway will wait for the debugger to connect
before starting continuing to start.KONG_EMMY_DEBUGGER_SOURCE_PATH: The path to the source code that the EmmyLua debugger will
use to resolve source code locations. The default is the current working directory.KONG_EMMY_DEBUGGER_MULTI_WORKER: If set, a debugger will be started for each worker process, using
incrementing port numbers starting at KONG_EMMY_DEBUGGER_PORT. The default is to start
only one debugger for worker zero.To control debugger behavior while running busted tests, a similar set of environment variables
prefixed with BUSTED_ instead of KONG_ can be used.