Blog
Engineering
June 16, 2020
6 min read

GitOps to Configure Kong: How to Set Up GitHub Actions Using decK

Takafumi Ikeda
Disclaimer: There has been a proposal made in the GitHub community to replace the “master” reference in Git branch names given its negative connotation as it pertains to slavery. At this time, no decisions have been made from Git and GitHub to change this. We have left the branch name as is to reflect the Git and GitHub default branch name. We will update the language accordingly if there are any official changes made by Git and GitHub.

Added on 14th April 2021: GitHub had changed the default branch name to "main" so we updated this post accordingly.

Kong’s fast, lightweight and scalable API management solution helps improve developer productivity by automating the delivery of API management. One way Kong automates API management is through a continuous integration and continuous delivery (CI/CD) process by leveraging Kong's decK (declarative configuration for Kong) and GitHub Actions.

Kong's decK provides a command line interface (CLI) to manage Kong in a declarative way. This allows organizations to manage their configuration in Git repositories, manage version control and leverage GitOps to automate the application of the configuration.

From a business perspective, establishing a CI/CD process accelerates innovation, increases quality and provides better customer satisfaction.

In this blog post, I will navigate through how to set up GitHub Action with decK to start GitOps for Kong. By the end of this post, we will be able to open a pull request (PR) in GitHub that will:

  • Validate the configuration being applied via `deck validate` and list how the configuration will change via `deck diff`
  • Apply the new configuration via `deck sync` when you merge the pull request

To accomplish these, we will set up two workflows - one on a pull request and the other on merge to master. The PR action will do `deck diff` and the merge to master will do `deck sync`, respectively.

Prerequisites

  • Access to GitHub or GitHub Enterprise Server
  • Access to GitHub Actions as part of your GitHub subscriptions
  • Kong instance is already set up (this post assumes you're using Kong Enterprise, but the Kong Gateway open source version should work as well)
  • Kong instance can be reached from GitHub Actions (if your instance is behind a corporate firewall, GitHub's self-hosted runner would be a good option)
  • decK is installed

Preparation

Let's start by creating directories to store the configurations:

In my case, I have an existing Kong environment; therefore, I will first export my existing configuration with deck dump.

Please make sure the `–kong-addr` option points to your Kong Admin API base url, and add the `–headers` option to embed your admin token if your Kong is configured with `rbac: on`. For Kong Enterprise users, the `–all-workspaces` will export all configurations from each workspace.

This command will return no output when successfully executed:

NOTE: Please note that your Kong configuration may contain sensitive information. Please take proper precautions to protect your declarative config.

In my case, Kong has three workspaces, which are IT, LOB and default, as you can see below.

Now, you have declarative configuration files on the file system. Let's store those in a Git repository.

You have now successfully stored the files into a local gGit repository. Let's push them to GitHub by first creating a repo in GitHub, Choose either public or private for this post.

When you are creating a repo in GitHub, please make sure not to initialize README for the following step work.

After the repo is created, you will see the instructions below:

With the Github repository created, we can now add and push to it:

Now, you have successfully set up your Git repository for Kong configuration. You can see the yaml file(s) in GitHub like below:

Set Up GitHub Actions

Let's set up a GitHub Action to automatically deploy configurations to Kong.

To accomplish this most easily, we need to create several files on the same Git repository, as demonstrated below:

First, create action.yaml, which states the basic definition of the action, including the base image it relies on and the parameters to run:

We need to create a Dockerfile as defined in the yaml file. There's a Docker image for decK we can use as a base image.

Next, we need to create an entrypoint.sh file as referenced in the Dockerfile. This script will execute the decK commands against the files under the directory specified in action.yaml. The script also makes sure only several sub-commands are going to run, such as ping, validate, diff and sync.

Make sure to give this file permission to execute:

Now, we have successfully set up the action. Let's create a workflow file that runs the action.

Workflow files should be located under `.github/workflow/` directory.

Let's create the `.github/workflow/` directory as shown below:

We will set up two workflows - one on a pull request and the other on a merge event. The action on the pull request will validate that the configuration being deployed is valid and shows the difference between the current Kong configuration and the configuration being applied. This allows the developer and/or PR reviewers to validate that the configuration is correct. The action on the merge will apply the new configuration to Kong.

Set Up Workflow on a Pull Request

First, we will set up the workflow on a pull request event that validates the configuration. Let's create `.github/workflows/CI.yaml` with your favorite editor, as shown below.

NOTE: I'm using a Kong Enterprise instance with RBAC enabled. If your instance has RBAC disabled, remove the `–headers ${{ secrets.KONG_HEADERS }}”` from the options section of each step in the workflow.

The workflow will execute four steps sequentially:

  • Check out the source codes on the step "checkout"
  • Execute the `deck ping` command to confirm decK can connect to Kong
  • Execute `deck validate` to confirm the configuration file is valid
  • Execute `deck diff` to show the difference between the configuration file and the current configuration of Kong

Notice in the "options" section there are additional variables like `${{ secrets.KONG_ADDR }}`. These variables refer to secrets stored in GitHub, which allow the actions to reference data securely. See more detail about this functionality here: https://help.github.com/en/actions/configuring-and-managing-workflows/using-variables-and-secrets-in-a-workflow.

Next, let's push all the files we created to GitHub now.

After successfully pushing the latest changes to GitHub, the repository should look like this:

Let's now set the secrets that the action will use by going to the GitHub UI, Settings and Secrets section on the side panel.

Add a new secret for KONG_ADDR, and if RBAC is turned on in your Kong installation, add another secret for KONG_HEADERS, which contains "Kong-Admin-Token:***".

We're all set! Let's confirm the action on a pull request works.

Open a Pull Request to Trigger the Workflow

Let's open a pull request by modifying the Kong configuration file(s). In my case, I'm going to modify kong/LOB.yaml. I've changed the retry value 130 to 13 on the "retries" section under "httpbin_anything" services object.

Next, I'll create a new branch, commit this change to the branch and push it to GitHub. Then I'll open a new pull request in the GitHub UI. If you are not familiar with how to open a pull request, please see: https://guides.github.com/activities/hello-world/.

After successfully opening a pull request, the GitHub Action should start running.

We can see the result of the action in the "Checks" tab in the pull request as shown below.

Reviewing the results of the Action, we should see the results of the decK commands. In particular, deck diff shows how the Kong configuration will change when the changes are merged.

Set Up Workflow on a Merge Event

Let's set up another workflow to apply the new Kong configuration on a merge event.

To do this, please create another yaml file under `.github/workflows` directory. Let's call it "sync.yaml" like below:

NOTE: I'm using a Kong Enterprise instance with RBAC enabled. If your instance has RBAC disabled, remove the `–headers ${{ secrets.KONG_HEADERS }}”` from the options section of each step in the workflow.

With this action, when changes are pushed to the master branch or a pull request is merged to master, the `deck sync` command will run to apply the configuration to Kong.

After the workflow has successfully finished, we can verify the new configuration was successfully applied. Let's validate using Kong Manager.

Congratulations! We have successfully set up a CI/CD pipeline to manage the Kong configuration declaratively using GitHub Actions!

For your convenience, I've created a reusable GitHub Action for decK, which you can fork and modify for your environment: https://github.com/ikeike443/decK-action.

Conclusion

In this post, we configured how to set up GitHub Actions to configure Kong declaratively with GitOps using decK. If you have any questions, please feel free to contact me on GitHub.

Happy hacking!

Topics:Automation
|
decK
|
GitOps