Mashape powers API Driven Software with many leading products including Kong (Open-Source API Gateway), Galileo (API Analytics), Marketplace (API Hub) and Gelato (Dev Portals)

Kong

Microservice architecture is nowadays almost a standard for backend development. An API gateway is an excellent way to connect a group of microservices to a single API accessible to users. API gateways are available from cloud providers such as AWS/Azure/Google Cloud Platform and Cloudflare. Kong is a scalable API gateway built on open source and can be an excellent alternative if you don't want to have your system locked into a particular vendor. This tutorial shows an example using Kong API gateway, , and . The illustration below shows you the final architecture we are going to build in this guide Ory Kratos Ory Oathkeeper The full source code for this tutorial is available on github What we will use gateway can be an excellent solution for an ingress load balancer and API gateway if you do not want vendor lock-in of any cloud API Gateways in your application. Kong uses and Lua. OpenResty extends Nginx with Lua scripting to use Nginx's event model for non-blocking I/O with HTTP clients and remote backends like PostgreSQL, Memcached, and Redis. OpenResty is not an Nginx fork, and Kong is not an Openresty fork. Kong uses OpenResty to enable . Kong OpenResty API gateway features acts like an identity and access proxy for our microservices. It allows us to proxy only authenticated requests to our microservices, so we don't need to implement middleware to check authentication. It can also transform requests, for example, convert session auth into JWT for a back-end service. Oathkeeper is the authentication provider; it handles all first-party authentication flows: username/password, forgot password, MFA/2FA, . It also provides OIDC/social login capabilities for example, "Login with GitHub". Kratos and more Building simple microservices Let's say we have two microservices: and . They are pretty simple and serve only to test our API gateway, but you can switch them out for more complex components. hello world The "World" microservice exposes a API endpoint and returns a simple JSON message: /world package main

import (
	"encoding/json"
	"log"
	"net/http"
)

type Response struct {
	Message string `json:"message"`
}

func helloJSON(w http.ResponseWriter, r *http.Request) {
	response := Response{Message: "World microservice"}
	w.Header().Set("Content-type", "application/json")
	w.WriteHeader(http.StatusOK)
	json.NewEncoder(w).Encode(response)
}
func main() {
	http.HandleFunc("/world", helloJSON)
	log.Fatal(http.ListenAndServe(":8090", nil))

} The "Hello" microservice exposes a API endpoint and returns a simple JSON message: /hello package main

import (
	"encoding/json"
	"log"
	"net/http"
)

type Response struct {
	Message string `json:"message"`
}

func helloJSON(w http.ResponseWriter, r *http.Request) {
	response := Response{Message: "Hello microservice"}
	w.Header().Set("Content-type", "application/json")
	w.WriteHeader(http.StatusOK)
	json.NewEncoder(w).Encode(response)
}
func main() {
	http.HandleFunc("/hello", helloJSON)
	log.Fatal(http.ListenAndServe(":8090", nil))

} We now want to secure access to these microservices and let only authenticated users access these endpoints. Okay. Let's start hacking, shall we? Ory Kratos setup Follow the guide to set up Ory Kratos. In this tutorial, you only need a docker-compose file with the following configuration: Quickstart postgres-kratos:
    image: postgres:9.6
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_USER=kratos
      - POSTGRES_PASSWORD=secret
      - POSTGRES_DB=kratos
    networks:
      - intranet

  kratos-migrate:
    image: oryd/kratos:v0.8.0-alpha.3
    links:
      - postgres-kratos:postgres-kratos
    environment:
      - DSN=postgres://kratos:secret@postgres-kratos:5432/kratos?sslmode=disable&max_conns=20&max_idle_conns=4
    networks:
      - intranet
    volumes:
      - type: bind
        source: ./kratos
        target: /etc/config/kratos
    command: -c /etc/config/kratos/kratos.yml migrate sql -e --yes

  kratos:
    image: oryd/kratos:v0.8.0-alpha.3
    links:
      - postgres-kratos:postgres-kratos
    environment:
      - DSN=postgres://kratos:secret@postgres-kratos:5432/kratos?sslmode=disable&max_conns=20&max_idle_conns=4
    ports:
      - '4433:4433'
      - '4434:4434'
    volumes:
      - type: bind
        source: ./kratos
        target: /etc/config/kratos
    networks:
      - intranet
    command: serve -c /etc/config/kratos/kratos.yml --dev --watch-courier

  kratos-selfservice-ui-node:
    image: oryd/kratos-selfservice-ui-node:v0.8.0-alpha.3
    environment:
      - KRATOS_PUBLIC_URL=http://kratos:4433/
      - KRATOS_BROWSER_URL=http://127.0.0.1:4433/
    networks:
      - intranet
    ports:
      - "4455:3000"
    restart: on-failure


  mailslurper:
    image: oryd/mailslurper:latest-smtps
    ports:
      - '4436:4436'
      - '4437:4437'
    networks:
      - intranet Some notes on the network architecture: HTTP and are the public and admin API's of Ory Kratos. :4433 :4434 HTTP for Mailslurper - a mock Email server. You can get an activation link by accessing . :4436 http://127.0.0.1:4436 HTTP for the UI interface that allows one to start sign-up/login/recovery flows. :4455 After running you can open to test your configuration. docker-compose up http://127.0.0.1:4455/welcome Configuring Ory Oathkeeper Now we can start configuring our gateways for this example. Kong is the entry point for the network traffic. Ory Oathkeeper would be accessible from the internal network only in this case. Let's review our architecture diagram from before: Oathkeeper checks sessions and proxies traffic to our microservice while Kong provides ingress load balancing. We can even set up to have a more robust configuration for our service. Here is how we configure the access rules for Ory Oathkeeper: Round-Robin DNS -
  id: "api:hello-protected"
  upstream:
    preserve_host: true
    url: "http://hello:8090"
  match:
    url: "http://oathkeeper:4455/hello"
    methods:
      - GET
  authenticators:
    -
      handler: cookie_session
  mutators:
    - handler: noop
  authorizer:
    handler: allow
  errors:
    - handler: redirect
      config:
        to: http://127.0.0.1:4455/login
-
  id: "api:world-protected"
  upstream:
    preserve_host: true
    url: "http://world:8090"
  match:
    url: "http://oathkeeper:4455/world"
    methods:
      - GET
  authenticators:
    -
      handler: cookie_session
  mutators:
    - handler: noop
  authorizer:
    handler: allow
  errors:
    - handler: redirect
      config:
        to: http://127.0.0.1:4455/login The Ory Oathkeeper configuration: log:
  level: debug
  format: json

serve:
  proxy:
    cors:
      enabled: true
      allowed_origins:
        - "*"
      allowed_methods:
        - POST
        - GET
        - PUT
        - PATCH
        - DELETE
      allowed_headers:
        - Authorization
        - Content-Type
      exposed_headers:
        - Content-Type
      allow_credentials: true
      debug: true

errors:
  fallback:
    - json

  handlers:
    redirect:
      enabled: true
      config:
        to: http://127.0.0.1:4455/login
        when:
          -
            error:
              - unauthorized
              - forbidden
            request:
              header:
                accept:
                  - text/html
    json:
      enabled: true
      config:
        verbose: true

access_rules:
  matching_strategy: glob
  repositories:
    - file:///etc/config/oathkeeper/access-rules.yml

authenticators:
  anonymous:
    enabled: true
    config:
      subject: guest

  cookie_session:
    enabled: true
    config:
      check_session_url: http://kratos:4433/sessions/whoami
      preserve_path: true
      extra_from: "@this"
      subject_from: "identity.id"
      only:
        - ory_kratos_session

  noop:
    enabled: true

authorizers:
  allow:
    enabled: true

mutators:
  noop:
    enabled: true Ory Oathkeeper now looks up a valid session in the request cookies and proxies only authenticated requests. It redirects to login UI if there's no cookie available. ory_kratos_session Adding Kong Now all that is needed is to configure Kong: services:
  kong-migrations:
    image: "kong:latest"
    command: kong migrations bootstrap
    depends_on:
      - db
    environment:
      <<: *kong-env
    networks:
      - intranet
    restart: on-failure

  kong:
    platform: linux/arm64
    image: "kong:latest"
    environment:
      <<: *kong-env
      KONG_ADMIN_ACCESS_LOG: /dev/stdout
      KONG_ADMIN_ERROR_LOG: /dev/stderr
      KONG_PROXY_LISTEN: "${KONG_PROXY_LISTEN:-0.0.0.0:8000}"
      KONG_ADMIN_LISTEN: "${KONG_ADMIN_LISTEN:-0.0.0.0:8001}"
      KONG_PROXY_ACCESS_LOG: /dev/stdout
      KONG_PROXY_ERROR_LOG: /dev/stderr
      KONG_PREFIX: ${KONG_PREFIX:-/var/run/kong}
      KONG_DECLARATIVE_CONFIG: "/opt/kong/kong.yaml"
    networks:
      - intranet
    ports:
      # The following two environment variables default to an insecure value (0.0.0.0)
      # according to the CIS Security test.
      - "${KONG_INBOUND_PROXY_LISTEN:-0.0.0.0}:8000:8000/tcp"
      - "${KONG_INBOUND_SSL_PROXY_LISTEN:-0.0.0.0}:8443:8443/tcp"
      - "127.0.0.1:8001:8001/tcp"
      - "127.0.0.1:8444:8444/tcp"
    healthcheck:
      test: ["CMD", "kong", "health"]
      interval: 10s
      timeout: 10s
      retries: 10
    restart: on-failure:5
    read_only: true
    volumes:
      - kong_prefix_vol:${KONG_PREFIX:-/var/run/kong}
      - kong_tmp_vol:/tmp
      - ./config:/opt/kong
    security_opt:
      - no-new-privileges

  db:
    image: postgres:9.6
    environment:
      POSTGRES_DB: kong
      POSTGRES_USER: kong
      POSTGRES_PASSWORD: kong
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "kong"]
      interval: 30s
      timeout: 30s
      retries: 3
    restart: on-failure
    networks:
      - intranet

  hello: The docker-compose creates three containers db container with PostgreSQL database to store the configuration of services/routes for our API gateway. kong-migrate to run migrations against the database. kong container that exposes port for proxying traffic and port with admin API. 8000 8001 As the last step, we need to create a service for Kong and configure routes. #!/bin/bash

# Creates an secure-api service
# and proxies network traffic to oathkeeper
curl -i -X POST \
  --url http://localhost:8001/services/ \
  --data 'name=secure-api' \
  --data 'url=http://oathkeeper:4455'

# Creates routes for secure-api service
curl -i -X POST \
  --url http://localhost:8001/services/secure-api/routes \
  --data 'paths[]=/'\ Testing You can open or in your browser and there are two possible scenarios: http://127.0.0.1:8000/hello http://127.0.0.1:8000/world You receive (or ). {"message": "Hello microservice"} "World microservice" The browser redirects you to . http://127.0.0.1:4455/login Further steps mutator to have the identity accessible as JWT token for your microservices. Configure id_token the password policy to better suit your use case. Configure . Add two-factor authentication Consider using instead of having an additional reverse proxy inside your network. authentication based on subrequest result can be an excellent plugin to use oathkeeper as a decision API for Kong. Kong auth request

Secure Microservices with Kong and Ory

Since 2003, I have used as my primary tool for developing applications and services. Nineteen years ago, I was impressed both by the small amount of RAM required to use the IDE and the refactoring abilities included with the 1.x release. IntelliJ Developing in Java does not require me to use the IntelliJ IDEA product. Other developers on my current project use Eclipse or VS Code, but these tools are not required. When you can write your components, services, and applications with a simple text editor and terminal session, you’ll end up with the same compiled Java code. So, why do I spend the money on IntelliJ every year? Because IntelliJ IDEA is designed to make things easier for developers—which equates to me being far more productive. For example, right-clicking on a class provides me with the option to relocate the class in a matter of seconds. When IntelliJ finds an opportunity to remove duplicate code, it creates the new shared code and correctly updates the locations that depend on the centralized method. IntelliJ is an excellent source of validation during code reviews too. While this example might seem a little elementary, I wonder why more software engineers are not taking a similar approach when building their services. Spring Boot Services and Kubernetes Let’s assume your feature team has standardized the use of for API services. As a result of your team’s hard work and detailed design, your APIs are viewed as successful by public consumers. Your organization decides to use for these services. Spring Boot Kubernetes For each Spring Boot service your team develops, this is what the high-level lifecycle looks like: A Spring Boot service is initialized, and custom code is added. That service is containerized into a image, which is ultimately deployed into Kubernetes. Docker By using Kubernetes, we get the following advantages: A collection of Spring Boot-base Docker containers are placed into a “Pod” to act as a single application. This allows each Spring Boot service to be laser-focused on a given aspect of the resulting API. One or more Pods can be grouped to form the resulting API service, which can be configured for discoverability, observability, horizontal scaling, and load balancing. Rolling updates and canary deployments are utilized to lead to a stable consumer experience. If you are interested in using Kubernetes with Spring Boot, check out the following URL: Spring Boot Kubernetes Based on the success of these popular APIs, let’s imagine that executive leadership would like to monetize the services to gain revenue from the most active consumers. A free tier will still be available, but limits on API usage will be introduced. While the team could implement some custom logic at the Spring Boot level, this does not make sense. What we need is a centralized way to handle this new requirement. Kong Ingress Controller to the Rescue Last year, I started getting familiar with the product suite as part of a long-term solution state for one of my clients. The scenario I described above mirrors situations I have encountered over the last five years: Centralizing common components is key for a successful microservices implementation. Kong If you want to read more about Kong, check out my publication from last May: How I Stopped Coding Repetitive Service Components with Kong For the use case mentioned above, we could handle the following components at the API gateway level: Application registration (key-auth) Rate limiting Centralized logging Since Kong Gateway is open source and a “leader” in the 2021 Gartner Magic Quadrant for Full Lifecycle API Management, Kong Gateway is a safe way to handle these common components. Knowing that Kong also provides an ingress controller for use within Kubernetes further validates the product decision. You can find everything you need to get started with Kong Ingress Controller (KIC) on this GitHub page: Kong Ingress Controller for Kubernetes The illustration below shows the desired design for the two services: Requests arrive at Kubernetes for API Service #1 or #2. The Kong Ingress Controller intercepts the requests and validates the API key provided. Based on that information, the controller determines if the consumer making the request has exceeded its request limit. If the rate limit has not been exceeded, the request is forwarded to the appropriate service. However, if the rate limit is exceeded, then a 429 (Too Many Requests) HTTP response will be returned. In all cases, the logging module can be easily configured to track all incoming requests, including all the metadata being provided by the API consumer. The Value of This Design When we take a step back and look at the resulting architecture and design, we quickly see the benefits: Spring Boot services are true microservices, each laser-focused on a single aspect of the API. Docker allows the Spring Boot services to be self-contained and distributed at any point within the development lifecycle. Kubernetes provides the ability to group those purpose-driven Docker images into Pods, which act as a single application. Those Pods are then grouped to surface as API services in our example. Shared components—like application registration, rate limiting, and logging—exist in one centralized location within Kong Gateway. Kong Ingress Controller becomes the middleware layer between Kong Gateway and Kubernetes to leverage all shared components. As a result of this model, feature team developers working on Spring Boot services only need to focus on the work provided by their product owner to improve or extend the service. These developers do not need to worry about API keys, rate limiting, or any other shared component managed elsewhere. DevOps engineers supporting the Kubernetes implementation do not have to architect any custom design aspects to handle those shared components either. That’s because Kong Gateway is built to accommodate those needs and works well via the Kong Ingress Controller. Conclusion Since 2021, I have been trying to live by the following mission statement, which I feel can apply to any IT professional: “Focus your time on delivering features/functionality which extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” - J. Vester At the start of this post, I talked about how I prefer IntelliJ IDEA over a text editor and terminal session. In reality, the core reason ties directly to my personal mission statement. The IDEA product allows me to focus on the right things; meanwhile, it handles the repetitive tasks related to writing original source code. Similarly, Spring, Docker, Kubernetes, and Kong have provided solutions and frameworks to work toward the same mission. Every aspect noted above can be traced to a single source of truth for a given item. As a result, there is no duplication of services or functionality across the application landscape. If you find yourself implementing the same process a second time, it is certainly time to consider refactoring your design. If your service tier falls into a similar modal as I’ve discussed here and you are not utilizing Kong Gateway or Kong Ingress Controller, they should certainly be on your shortlist of products to review when you are ready to refine your service design. Have a really great day!

How to Use Kong Ingress Controller with Spring Boot Services

Cómo usar el controlador Kong Ingress con Spring Boot Services

Many developers and DevOps engineers have been deploying in front of their -based applications. While the extensive library of can add a lot of flexibility and power to your deployments, you might encounter the occasional use case where you need a custom plugin that’s just not found in the library. Kong Gateway microservices built-in plugins Fortunately, you can use Go to create and run plugins for Kong Gateway. This post will cover how to get set up for writing Kong plugins. We’ll look at the parts of the request/response lifecycle that you can tap into, and we’ll walk through an example of how to put it all together. Custom plugins for Kong are achievable using a Go-specific plugin server that uses the sidecar model to load and run a plugin written in Go dynamically. Communication between the plugin and the plugin server is done through a Unix domain socket. Luckily, all of this is made simple through Kong’s (PDK). Go Plugin Development Kit Why would you write your own plugin? Ultimately, the ability to write your own Go plugin and integrate it with Kong Gateway provides nearly limitless flexibility during the request and response lifecycle. A classic example would be simple request and response enrichment: Imagine adding or removing headers to influence request routing or incorporating customized request validation or logging requests for auditing. Harnessing Kong Gateway’s power while building in custom gateway logic for your unique business case gives you the best of both worlds. Enough talk. Let’s get to it. Development setup For this example, we’ll assume that you have already done the following: Installed Go locally on your machine. Installed Kong to manage the service configuration, though you can also configure Kong using the Admin API. Installed decK The first step for environment setup is to create a directory and our Go mod file: $ mkdir kong-go-plugin
$ cd kong-go-plugin/
~/kong-go-plugin$ go mod init kong-go-plugin
go: creating new go.mod: module kong-go-plugin Next, we run and to build the plugin server: go get go build ~/kong-go-plugin$ go get -d -v github.com/Kong/go-pluginserver
go: downloading github.com/Kong/go-pluginserver v0.6.1
go: downloading github.com/Kong/go-pdk v0.6.0
go: downloading github.com/ugorji/go v1.2.1
go: downloading github.com/ugorji/go/codec v1.2.1
go get: added github.com/Kong/go-pluginserver v0.6.1
~/kong-go-plugin$ go build github.com/Kong/go-pluginserver By default, Kong expects to be in , but you can modify this behavior by changing the value for in your Kong configuration. For the sake of consistency, let’s move the newly built binary to the default location. go-pluginserver /usr/local/bin go_pluginserver_exe ~/kong-go-plugin$ sudo mv go-pluginserver /usr/local/bin/ One other default that we’ll want to modify is which defaults to . This is where Kong looks for our Go plugins. For this example, we’ll use , so if you’re following along, you’ll need to update your configuration to match. go_plugins_dir off $HOME/goplugins/ Before diving into the code, one last thing is that consistency issues can occur. They normally manifest as error messages like the following: failed to open plugin kong: plugin.Open("/path/go-plugins/myplugin"): plugin was built with a different version of package github.com/Kong/go-pdk/bridge If you do run into that message, check out the documentation for more info on possible root causes. Now that we set up our development environment, we can start coding our plugin! here Coding time! Our next step is to write the plugin and verify it works as expected. We’ll start with a simple bit of code to add a header to a response. If you’re following along, you can copy this directly into a file called : goplug.go package main

import (
	"github.com/Kong/go-pdk"
)

type Config struct {
	Attach bool
}

func New() interface{} {
	return &Config{}
}

func (c *Config) Access(kong *pdk.PDK) {
	if c.Attach {
		kong.ServiceRequest.SetHeader("x-goplug", "Set by custom go plugin")
	}
} If you’ve worked with Go before, this should be pretty straightforward. That said, you can find more details in the . The documentation explains the structs and functions, and it provides a full list of the phases you can tap into. We’re using the phase at this point, so we can attach the header before it gets proxied to the upstream service. This is useful in cases where you want to add data to the response based on some incoming criteria that the upstream service can use. Kong Go Plugin Documentation Access Next, we need to build our plugin and “install” it with go build -buildmode plugin goplug.go && mv goplug.so ~/goplugins/ After that, we restart Kong to ensure it has picked up our new plugin. ~/kong-go-plugin$ sudo kong restart Now, our plugin is loaded and ready to use, but we still need a service to use it on. I’ve used and added the following to a file to test out the plugin. All you need to do is run once you’ve created the file. decK kong.yaml deck sync kong.yaml _format_version: "1.1"
services:
- host: mockbin.org
  name: example_service
  port: 80
  protocol: http
  plugins:
  - name: goplug
    config:
      attach: true
  routes:
  - name: mocking
    paths:
    - /mock
    strip_path: true With our plugin loaded and service created, we’re ready for a test. Simply make a curl request to the service and we’ll see the plugin in action! ~/kong-go-plugin$ curl -s  -i -X GET http://localhost:8000/mock/request \
| grep "x-goplug"
x-goplug: Set by custom go plugin Success! For good measure, let’s tie into one more phase of the request and response lifecycle. In this next function, we’ll tap into the phase to add a debugging header in case our plugin runs into issues. Response func (c *Config) Response(kong *pdk.PDK) {
	v := runtime.Version()
	kong.Response.AddHeader("x-goplug-go-version", v)
} Add the above function to , then repeat the process to rebuild the plugin. Next, restart Kong. When we rerun our curl command, we see that is included with the request to the upstream service, but it is removed before sending a response back to the client. goplug.go x-goplug $ curl -s -i -X GET http://localhost:8000/mock/request \
| grep "x-goplug-go-version"
x-goplug-go-version: go1.16.5 Let’s draw some parallels to real-world applications. We’ve shown here how you can take data from a request and turn that into actionable information, ready to be processed by an upstream service fronted by Kong Gateway. What’s even better is that all of this background work is transparent to the client. We’ve also shown how you can modify the response to the client. With this ability, you can ease troubleshooting or even pass back rate-limiting data (such as the number of remaining API requests per day or per hour) to keep your customers informed of their utilization. Wrap up In this post we’ve covered a lot, so let’s wrap it up with a brief review. Here’s what we’ve covered: What you need to develop Go plugins for use with Kong Gateway Why you might build a custom plugin rather than use a plugin that’s built-in with Kong Gateway Set up a local development environment that supports creating Go-based Kong plugins Used that local development environment to tap into the request/response lifecycle to modify the data on the fly Now that the process is down, it’s easily repeatable for whatever use case you may have for Go-based Kong plugin development. You can find the Kong documentation for Go support on along with some other . Kong’s website examples and walkthroughs

Kong Plugins as Microservices: Writing a Single-Plugin Server for Kong in Go

Insomnia is a desktop app from that’s great for building, debugging, and testing backend APIs. While ad hoc manual testing is nice, wouldn’t it be even better to include our API tests in our continuous integration (CI) pipelines? With Inso, Kong Insomnia’s CLI tool, we can! Kong Inso allows you to run your automated API tests directly from the command line, which means setting up a workflow with GitHub Actions is a snap. In this article, we’ll create a simple server with Node.js and , write API tests using , and then run these tests in our CI pipeline with and . Express Kong Insomnia Inso GitHub Actions Demo App: A Nintendo Game Database We’ve built a game database that contains info about every game ever published. The app is a server that implements a REST API with endpoints to get data about the games, categories, developers, publishers, and release years. NES You can . find the complete code on GitHub Using Kong Insomnia for Manual Testing While developing an API, rapid feedback cycles help ensure your API works the way you want and returns the data you expect. Kong Insomnia is perfect for this kind of ad hoc testing. To get started with our NES game API, we created a new inside Kong Insomnia. We left the information in the Design tab blank and headed over to the Debug tab to start making requests. Below, we have requests for each API endpoint our server provides. We can run each request inside Kong Insomnia, and the resulting data is displayed in the UI. Design Document Writing Tests with Kong Insomnia Manually hitting our API endpoints is great for ad hoc testing and debugging, but ultimately what we want is an automated test suite that ensures our app is behaving correctly. in the Test tab within the desktop app. Kong Insomnia allows you to write tests The tests are written by selecting one of the requests from the Debug tab and then making assertions about the data the server returns. You can run individual tests or an entire suite of tests. As you can see below, we’ve written tests for each of our API endpoints for a total of 11 tests in our test suite. These tests (and the information in our Design Document) can be synced with Git and included in our code repo. That way, anyone with the Kong Insomnia desktop app can also run these requests and tests. To , simply click the “Setup Git Sync” button at the top of the app. sync Kong Insomnia with Git From there, you can provide the relevant details to connect Kong Insomnia with your project’s Git repo. Syncing Kong Insomnia with your Git repo requires an authentication token. You can easily within your account settings in GitHub. create a personal access token Running Tests from the Command Line with Inso We now have a set of requests and a suite of tests within Kong Insomnia that help us with our debugging and testing. But we haven’t automated the running of these tests yet, so let’s do that now. This is where Kong Insomnia’s CLI, Inso, comes into play. Inso is installable as an npm package, so we’ve added that as a dev dependency to our project: . yarn add --dev insomnia-inso To make running our test suite simple, we’ve created an npm script in our file. The following script : . That means we can simply run to run our tests from the command line any time we want. package.json runs our tests with Inso "test": "inso run test \"NES Games API Test Suite\"" yarn test Integrating Inso with GitHub Actions Now for the culmination of everything we’ve set up so far: running our automated tests as part of a continuous integration pipeline. It’s nice that we can run our tests from the command line, but right now, we don’t have them running automatically for us anywhere. We really want our test suite to be run on every new pull request. Doing so will ensure that the tests pass before merging any new code into the master branch. This is continuous integration at its finest. allow us to configure any continuous integration we’d like by using YAML files. We’ve created a directory and a file inside it. This file is reproduced in full below: GitHub Actions .github/workflows unit-tests.yml name: NES Games API CI

on:
  push:
    branches:
      - master
  pull_request:
    branches:
      - master

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout branch
        uses: actions/checkout@v2

      - name: Use Node.js 14.x
        uses: actions/setup-node@v2
        with:
          node-version: 14.x
          cache: 'yarn'

      - name: Install dependencies
        run: yarn install --frozen-lockfile

      - name: Start server and run unit tests
        run: yarn ci:start-and-test As you can see, our workflow checks out our current branch, uses Node v14, installs our dependencies with yarn, and then runs a custom script to start our app’s server and run the API tests. This workflow is triggered whenever code is pushed to the master branch or a new pull request is opened against the master branch. This script is another npm script we’ve added to our file. Using the npm packages and , we use this script to start our server, run the API tests, and then kill the server once the tests finish. The full list of npm scripts in our file is reproduced below: ci:start-and-test package.json wait-on concurrently package.json "scripts": {
  "ci:start-and-test": "concurrently -k -s=first \"yarn start\" \"yarn ci:test\"",
  "ci:test": "wait-on http://localhost:3000 && yarn test",
  "format": "prettier --write .",
  "format-watch": "onchange . -- prettier --write {{changed}}",
  "start": "node index.js",
  "test": "inso run test \"NES Games API Test Suite\""
}, And now, we have a beautiful working CI pipeline! We can test that everything is working properly by creating a small pull request in our repo. After making the pull request, we can see that our CI pipeline is running: If we click the Details button to see more info, we can see the individual steps of our workflow being run: Once the job passes, the results are reported back to the pull request as seen below: We did it! All checks have passed. The last thing we could do for completeness is require that all checks pass in GitHub before pull requests can be merged. We can do this in the repo’s settings within GitHub: If you’d like to explore another potential CI setup, the Kong team also has their own you can use that installs Inso as part of a job in the CI pipeline with their . example workflow setup-inso GitHub Action Conclusion So, what have we accomplished today? Quite a lot, actually! We’ve created a server using Node.js and Express. We’ve created ad hoc requests within Kong Insomnia to help with the development and debugging of our API. We’ve written tests inside Kong Insomnia and learned to run them from the command line using Inso. And finally, we’ve created a CI pipeline with GitHub Actions to run our API tests as part of every pull request for our repo. Kong Insomnia, Inso, and GitHub Actions have worked together to help us develop our app with confidence. Our continuous integration pipeline has prepared us to deploy our app at any time. Success! To go further, we could merge this workflow into a broader strategy for managing the entire API development lifecycle — design and development within Kong Insomnia, deployment with Inso integrated with our CI pipeline, and management and maintenance with a tool like . Kong Gateway Thanks for reading, and happy coding!

CI for APIs with the Kong Insomnia CLI and GitHub Actions

There are events in our life that seem to be just routine, but then unexpectedly, they have a profound impact on our journey. For me, one event was attending the 2008 Gartner conference in Orlando, Florida. That event not only introduced me to the Salesforce ecosystem for the very first time but also to concepts like: (via an impressive session by Roy Schulte) Service-Oriented Architecture and Web 2.0 Mashups RESTful API Design While I had modest expectations for the event, those few days in central Florida became a key aspect of focus for the next 13 years of my career, far exceeding any expectations I could have ever imagined. Along the way, I learned many lessons from projects and initiatives focused on these very concepts. In this article, I will dive into several lessons learned from projects that placed RESTful APIs at the core of an application’s design. The RESTful API Pitfalls The RESTful API software style provides an easy manner for client applications to gain access to the resources (data) they need to meet business needs. In fact, it did not take long for Javascript-based frameworks like Angular, React, and Vue to rely on RESTful APIs and lead the market for web-based applications. This pattern of RESTful service APIs and frontend Javascript frameworks sparked a desire for many organizations to fund projects migrating away from monolithic or outdated applications. The RESTful API pattern also provided a much-needed boost in the technology economy, which was still recovering from the impact of the . Great Recession Fast-forward several agile iterations into this new development paradigm, and two pitfalls have been repeatedly encountered more than they have been avoided: An outdated application design was ultimately replaced with a very large RESTful API and an equally large Javascript framework. This created challenges with coordinating future features and enhancements; basically, one monolith was replaced by another. A legacy application design employed multiple RESTful APIs and componentized clients utilizing Javascript frameworks, but a single database was utilized. The result of this design led to data ownership conflicts, a higher-than-expected number of database connections, and higher costs to support/maintain a large database. Below is an example of how pitfall #2 played out, with several services competing for resources from a single database: Unfortunately, I have also seen these same scenarios with greenfield development opportunities, where there is a preference to use a single database for an entire collection of microservices. Microservices Should Begin With the Database In most programming languages, it is possible to create a fully functional application using a single file. In Java, everything could be in the same class file and stemmed from simply calling the method: main() public class SingleClassApplication {
    public static void main(String[] args) {
        // Start doing something really cool here
    }
} However, this approach is not very supportable, nor does it facilitate easy contribution from multiple developers. There is also the concept of “ownership” (or system of record) when it comes to aspects of an application. In cases where more than one service or function claims to be the owner of something (like a customer), challenges arise when business rules differ. The same scenario can occur when multiple RESTful APIs claim ownership of a given object. These same concepts translate to the database layer when employing a RESTful API design. Consider the following guideline: A single RESTful API should be considered the system of record for a given aspect of the application. As such, the corresponding data tier should leverage a data store focused solely on that aspect of the application. The illustration below provides a microservices design that adheres to this guideline: A successful microservice design begins with the database. Once in place, scaling to meet customer demand for the given service does not have an impact on any other service. Counterpoint: What About Database Constraints? My recommended approach is to isolate a given microservice with a dedicated database. This allows the count and size of the related components to match user demand while avoiding additional costs for elements that do not have the same levels of demand. Database administrators are quick to defend the single-database design by noting the benefits that constraints and relationships can provide when all of the elements of the application reside in a single database. As an example, a single database design can prevent a request to remove a customer if there are orders associated with the customer queued for deletion. While that is definitely a benefit to having a single database, consider the following points before opting to utilize a single database for all microservices: Compare the long-term value gained by using a single database with the associated costs for scaling a single, large database. What is the expected cost to scale and support a single database design in the future? What is the risk and value of having these constraints enforced at the API layer instead?  Keep in mind that a single microservice would be considered the owner of a given database, so the business logic would not allow things like deleting a customer with active orders. Consider the benefits of using an event-driven (or message-based) design to handle the situations where how one microservice handles a request depends on the response from another microservice. While this is similar to a single application/single database design, the ability to scale and allocate dedicated processing power when needed can be isolated and controlled. Certainly, constraints and relationships should be implemented and enforced, even when the database supports only a dedicated service instance. Common Elements Should Be Abstracted Adopting a true microservices design can lead to side effects if not planned appropriately. The biggest challenge I continue to see is the duplication of common components and the service-tier layer. The list below provides examples of elements that are often duplicated inside each microservice: authentication caching logging monitoring security In fact, consider this illustration, which I introduced in my “ ” article earlier this year. Use the Kong Gateway to Stop Coding Repetitive Service Components Like all aspects of the development lifecycle, we should always focus on keeping things as (don’t repeat yourself) as possible. This includes elements that can be abstracted and processed at a common level or a different level of the application stack. DRY One approach I often recommend is a distributed microservices abstraction layer approach provided by . Kong Placing Kong at the Center of the Ideal Design allows the complexity of service-tier APIs to be reduced to a collection of endpoints (or URIs) focused on meeting a collection of business needs and functionality. Often-duplicated components (like authentication, logging, and security) are handled by the gateway and can be removed from the service-tier design. Kong Gateway With each RESTful microservice maintaining a dedicated database instance and the duplicate components abstracted, a collection of purpose-driven microservices would appear as illustrated below: Inter-service communication is handled via a messaging tier utilizing common , such as: enterprise integration patterns - invoke another service to perform a background action Command Message - request information from another service Document Message - broadcast information to anyone listening on a given topic Event Message - make a request to another service and listen for a response Request-Reply With this design in place, consider some real-life benefits: If the Node.js service experiences higher-than-expected usage, the cost to scale up to meet demands is isolated to the service and dedicated database. If any single service realizes that a data store change is preferred (such as SQL to NoSQL), the new design can be deployed with little (if any) impact on any of the other services—provided the RESTful API URIs are not changed. A change in any of the abstracted layer components (for example, using a new logging approach) can be made at the Kong Gateway layer and have no impact on the underlying services. Conclusion Starting in 2021, I have been trying to live by the following mission statement, which I feel can apply to any IT professional: “Focus your time on delivering features/functionality which extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” - J. Vester While the primary objective of this article is to move toward a true microservice design that includes a dedicated database, Kong provides core aspects for a true microservice design that are scalable and easy to adopt. In fact, Kong Gateway allows developers to keep things DRY, introducing common components to reside in the distributed microservices abstraction layer. Remember, “microservices” includes the word “micro,” which is often defined as “extremely small.” It is important to keep this basic premise in mind during any microservice implementation. Feature developers utilize packages and classes to group their program code for supportability and maintainability. Within those classes, methods and functions are defined—often employing a rule that each block of code is small and easy to digest. To me, an ideal function or method is one that I can review without ever having to touch my mouse. Microservices should be an extension of the same rules programmers have been following for decades: keep things small, purpose-driven, and efficient … keep things “micro.” To reach that goal, the design must include the database. Have a really great day!

Breaking Up a Monolithic Database with Kong

, take a back seat, there's a new player in town! NGINX For many developers out there, NGINX would be the primary choice for reverse proxy. However at , our API platform for banking integrations, we moved on to something more exciting! Decentro API development has moved from a single stack monolithic architecture to the majestic microservices architecture. This requires a gateway server that should manage redirection, proxying, and security over multiple requests. This means our old faithful NGINX has become a little outdated. (Let’s not even talk about Apache HTTP Server here!) Even if you run a monolithic application, The API Gateway is still a good pick. Apart from proxying, there are many other benefits. The API Gateways should give us the developer the ability to: Scale: As you grow, so should your application Provide security: Applying SSL is just scratching the surface Have a GUI: This would make life 10 times easier Be Intuitive: Should be self-explanatory “ ” But what does it do? You may ask. Good question. Suppose we have an API stack with multiple APIs spanning over a bunch of microservices. Let’s look at the diagram: Here you can see the API Gateway is the lord and the savior for the application instances running behind it. It proxies the requests to the requisite application instance (as a reverse proxy). Now your endpoint can be independent of the microservice it caters to. So if you want to have multiple endpoints (e.g., /docs, /documents, /documentation) connected to the same application, you can. Just reverse proxy it, baby! Farewell, NGINX! Here at Decentro, we used to work with NGINX as our reverse proxy server. But we grew out of it. We had to log in to our instance to reload NGINX via CLI and had to learn to manage configurations when using NGINX. It didn’t have consumer-level handling for API management. We needed something extra. After logging our heads together for quick brainstorming and crossing the Is’ & Ts’ on the Pros/Cons list, we found the one! Dhumm… Dhumm… Dhumm… Did you feel it? Here comes ! KONG Source: Github As is evident from the image above, Kong provides a lot of features out of the box. No recompilation. No command-line configuration. No extra cost. Kong comes with its own RESTful Admin APIs. It is built on top of OpenResty (an extension of NGINX) and LuaJIT. These provide access to all kinds of configurations that can be made available. We have done another addition on top of it by adding the Konga dashboard to manage Kong via a GUI. Kong API Gateway Structure The API structure in Kong is pretty simple. Services – The logical representation of your microservice or monolithic application Routes – The logical representation of endpoints that are accessible within the service. Consumers – The clients that are going to be using the services.Plugins – This is where the magic happens. Plugins can be applied to either of the above entities mentioned. So let’s talk about an example. We have a microservice that takes care of sending emails.  We'll declare a Service with the name “emails” (Pretty innovative.. yep!). This will contain the details of the application server, which it will reverse proxy for. Now let’s make Routes for this service. So we have two kinds of emails to be sent. Transactional – Sent by the API Marketing – Sent by the marketing department to let the clients know about the new features of our awesome product. Now, we will put an API Key authentication plugin on top of the “emails” service. This will ensure that no bad actors try to get access to our APIs. Rate-limit Plugins We will also add a rate-limit plugin (to limit the number of API hits) on the different routes. Transactional (600 per minute) – Since this API is triggered by other flows, we need a high rate limit. Marketing (1 per minute) – Since this is manually triggered, we don’t need to go beyond 1 per minute In order to further enhance our security, we will allow only certain IP addresses to be able to access our transactional email route as it will be triggered only by our internal systems, and we know the IP address range for our internal systems. We will set it open to the world (Potentially insecure) for the marketing emails as the marketing peeps should be able to access it from any cafe that they wish to work out of. Now we want only authorized consumers to access the APIs, so we will set up a consumer and add the API authentication credentials for them to use. Now our email service is ready to serve consumers. We can integrate it into our code and give it to the marketing peeps for them to use it manually. Wrapping Things Up As you can see, using Kong as an API Gateway is simple and takes the hassle of managing APIs. Kong provides many other features like upstreams, certificate management, request and response transformation, serverless code execution, logging, and CORS, which are very helpful when you wish to develop APIs quickly. NGINX and other reverse proxy servers are simply blown out of the water by the ease of configurability and sheer dexterity that KONG provides out of the box. We rest our case, thus!

Why We Switched from NGINX Is to KONG API Gateway

Por qué cambiamos de NGINX a KONG API Gateway

Kubernetes has become the name of the game when it comes to container orchestration. It allows teams to deploy and scale applications to meet changes in demand while providing a great developer experience. The key to handling modern dynamic, scalable workloads in Kubernetes is a networking stack that can deliver API management, a service mesh and an ingress controller. allows users to manage the routing rules that control external user access to the service in a Kubernetes cluster from the same platform. Kong Ingress Controller This article will look at how you can use for full-stack application deployments with Kubernetes. By full-stack, we mean Kong can handle: Kong Containers Container networking Pod networking Service networking Host networking Load balancing Rate limiting HTTPS redirects Let's get started by creating our cluster. Installing Kind Kubernetes With Kind, you can run local Kubernetes clusters using Docker. It was designed for testing Kubernetes but is perfect for local K8 development like we will do in this example. There are quite a few ways to install Kind, depending on your operating system. If you have a Mac, you can install it quickly with Homebrew: brew install kind If you are on a Windows machine and have Chocolatey installed, the command is just as simple: choco install kind If you have Go and Docker installed, you can run the following command to install kind: GO111MODULE= go get sigs.k8s.io/kind@v0 "on" .10 .0 For more installation options, see the . Kind quickstart Once Kind is installed, you need to create a cluster:: kind create cluster After making the cluster, you can interact with it using kubectl. To list your clusters, run: kind get clusters It should return kind, the default cluster context name. Now run the following to point kubectl to the kind cluster: kind kubeconfig export If you set up Kind correctly, running the following command will give you details about your cluster: kubectl cluster-info Installing Kong Ingress Controller Now that we have a cluster running, we can install Kong quickly by applying the manifest directly with the following command: kubectl create -f https: //bit.ly/k4k8s Now run the following command to get details on kong-proxy: kubectl -n kong get service kong-proxy You will notice that the external IP is still pending. Kind only exposes the Kubernetes API endpoint, and so the service is not accessible outside of the cluster. Since we are using Kind, we will have to run a port forward to do this. This command does not get daemonized, so you will have to open another console window to run other commands. kubectl -n kong port-forward --address localhost, svc/kong-proxy : 0.0 .0 .0 8080 80 Next, we need to set an environment variable with the IP address from where we want to access Kong. This will be localhost since we are using a port forward. PROXY_IP=localhost: export 8080 You can curl the IP now or visit in a browser and should see: { : } "message" "no Route matched with those values" Deploying an Example App Now let's deploy something that will return some results. Kubernetes has multiple example applications available in a . We are going to deploy the with these commands: Github repo Guestbook App kubectl apply -f https: kubectl apply -f https: kubectl apply -f https: kubectl apply -f https: //k8s.io/examples/application/guestbook/mongo-deployment.yaml //k8s.io/examples/application/guestbook/mongo-service.yaml //k8s.io/examples/application/guestbook/frontend-deployment.yaml //k8s.io/examples/application/guestbook/frontend-service.yaml Now, if we run kubectl get services, we will see two new services: We can also query the pods to make sure their status is ‘Running’: kubectl get pods -l app.kubernetes.io/name=guestbook -l app.kubernetes.io/component=frontend To test it, you can run another port forward really quick with: kubectl port-forward svc/frontend : 8000 80 You will find the guestbook running at . We will now set up the Kong Ingress Controller. http://localhost:8000/ Expose the App to the Internet Now we can use the Kong Ingress Controller, so we need to set up a resource to serve traffic. We can create a proxy for our application with the following command: echo | kubectl apply -f - '
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: guestbook
  annotations:
    konghq.com/strip-path: "true"
    kubernetes.io/ingress.class: kong
spec:
  rules:
  - http:
  	paths:
  	- path: /
        pathType: Prefix
        backend:
          service:
            name: frontend
            port:
              number: 80
' Now you will see the guestbook app at . http://localhost:8080/ Using Plugins as Services in Kong With Kong Ingress, we can execute plugins on the service level. That way, Kong will execute a plugin whenever a request is sent to a specific service, no matter which ingress path from where it came. If we want to add rate limits to our app, we can add the rate limiting plugin to our Kubernetes installation with the following command: echo | kubectl apply -f -
kongplugin.configuration.konghq.com/rl-by-ip created "
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rl-by-ip
config:
  minute: 5
  limit_by: ip
  policy: local
plugin: rate-limiting
" Once you install the plugin, you can apply the konghq.com/plugins annotation on our Guestbook with the following command: kubectl patch svc frontend \
  -p '{"metadata":{"annotations":{"konghq.com/plugins": "rl-by-ip\n"}}}' If you curl the guestbook app, you will see that rate limiting has been set up. If you plan on testing the Guestbook frequently during this example, you may want to set the limit higher, or you will run into a Kong error that says the rate limit has been exceeded. Configuring an HTTPS Redirect So far, the app is running on HTTP, and we want it to run on HTTPS. If we want to tell Kong to redirect all the HTTP requests, we can update its annotations to HTTPS and issue a 301 redirect with this command to patch the ingress entry: kubectl patch ingress guestbook -p '{"metadata":{"annotations":{"konghq.com/protocols":"https","konghq.com/https-redirect-status-code":"301"}}}' To test this using kind, set up another port-forward with the following command: kubectl -n kong port-forward --address localhost, svc/kong-proxy : 0.0 .0 .0 8443 443 You can now access a "secure" version of the guestbook at . It will not have a certificate, so you will run into warnings in your browser. Let's look at how we can add certificates. https://localhost:8443 Adding the Cert-Manager You can install the cert-manager with the following command: kubectl apply -f https: //github.com/jetstack/cert-manager/releases/download/v1.3.1/cert-manager.yaml Once the images pull down, you can verify that it is running with this command: kubectl get all -n cert-manager You should see something like this: Since we have Kubernetes running locally with a port-forward, the IP address for the Kong proxy is 127.0.0.1. If you weren’t using a port forward, you could run the following command to find the IP address: kubectl get -o jsonpath= service -n kong kong-proxy "{.status.loadBalancer.ingress[0].ip}" But since we are using a port forward, this command will return nothing. If this were in production, you would then set up DNS records to resolve your domain to the IP address you just retrieved. Once that is done, you can request a certificate from Let's Encrypt by running the following, making sure to change the email: echo | kubectl apply -f - "apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
  namespace: cert-manager
spec:
  acme:
    email: user@example.com #change this email
    privateKeySecretRef:
      name: letsencrypt-prod
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
    - http01:
      ingress:
        class: kong" Next, you will have to update your ingress resource to provide a certificate with the following command, changing the domain to your own: echo | kubectl apply -f - '
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: guestbook-example-com
  annotations:
    kubernetes.io/tls-acme: "true"
    cert-manager.io/cluster-issuer: letsencrypt-prod
    kubernetes.io/ingress.class: kong
spec:
  tls:
  - secretName: guestbook-example-com
    hosts:
    - demo.example.com #change this domain/subdomain
  rules:
  - host: demo.example.com #change this domain/subdomain
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: guestbook
            port:
              number: 80
' Once that is updated, the cert-manager will start to provision the certificate and the certificate will be ready soon. Missing a Tool in Your K8s Stack? Kong may be the missing tool in your Kubernetes stack. can implement authentication, HTTPS redirects, security certificates, and more across all your Kubernetes clusters. Using Kong, you can control your containers, networking, load balancing, rate limiting and more from one platform. It truly is the choice for full-stack ingress deployments. Kong Ingress Controller Also published on: https://dzone.com/articles/kubernetes-full-stack-example-with-kong-ingress-co

How to Use Kong for Full-stack Application Deployments with Kubernetes

It's time to have some fun. Sure, tell your colleagues or your family that you're doing research, experimenting with some new tech—because that is what we'll be doing—but just don't let them see you playing Minecraft! Here's the scenario: You're organizing a full-day class for local STEM students. You need to run your own Minecraft servers to ensure a kid-friendly multiplayer environment, restricted only to your students. One server won't be enough, so you'll run two servers simultaneously, expecting your load balancer to handle sending students to Server A or Server B, depending on the load. Minecraft In this article, we're going to explore port forwarding and load balancing with . We're going to do this by spinning up multiple Minecraft servers, and then placing Kong Gateway in front of these upstream services to handle port forwarding and load balancing. Kong Gateway Before we dive in, let's briefly cover a few important technology concepts. Key Concepts Port Forwarding Port forwarding is receiving network requests on a certain port of a machine and forwarding those requests to a different port. A router, firewall or API gateway usually handles this task. For example, you might have a web server listening on port 3000 and a database server listening on port 5000. Your API gateway would listen for requests from outside your network. Requests addressed to port 80 would be forwarded by the gateway to your web server at port 3000. Meanwhile, requests addressed to port 5432 would be forwarded to your database server at port 5000. Load Balancing Load balancing is the task of distributing multiple requests to a server in a balanced manner across numerous replicas of that server. A specific piece of hardware or software called a load balancer usually handles this. The outside world is unaware that there are multiple replicas of a server running. They believe they’re making requests to a single server. The load balancer, however, distributes the request load to prevent any one server from being overwhelmed. In the case of a replica failing completely, the load balancer ensures that requests only go to healthy nodes. Kong Gateway Kong Gateway is a thin API gateway layer that sits in front of upstream services, capable of performing these port forwarding and load balancing tasks. Whether those upstream services are web servers or databases or even Minecraft game servers, Kong is the front-door greeter to all requests. In addition to traffic control, Kong Gateway can manage , request transformations, analytics, and logging. authentication TCP Stream Support One aspect of our Minecraft project that sets it apart from deploying a typical web server or database is that Minecraft requires an established connection between the Minecraft client (the gamer) and server. Rather than expecting stateless HTTP requests, we'll need to handle TCP connections with streaming data. Fortunately, Kong Gateway fully supports TCP streaming. Our project approach We're going to walk through this project step-by-step: Spin up a single, local Minecraft server without any port forwarding. Spin up a Minecraft server on a non-default port, configuring Kong Gateway to port forward requests to that server. Spin up two Minecraft servers on different ports, configuring Kong Gateway to load balance and port forward connection requests. As you can see, we'll start simple, and we'll slowly build on complexity. What you'll need to get started You don't need a lot of familiarity with Minecraft to progress through this mini-project. Since it’s easiest to spin up Minecraft servers within Docker containers, basic familiarity with Docker may be helpful. actually You will need to on your local machine. Lastly, if you want to test that our project results are successful, you'll need to and log in as a paid owner of the game. The free trial of Minecraft doesn't allow connecting to multiplayer servers, which is what we'll be running for our project. install Docker Engine install the Minecraft game client Are you ready to do this? Here we go! Step 1: Single Minecraft Server with Default Port In this first step, we want to spin up a single Minecraft server on our local machine. We'll use the default port for the server, and then we'll connect our game client to the server. It’s simple to deploy the Minecraft server as a Docker container, with the Docker image found . here In a terminal window, we'll run this command to pull down the server image and spin it up in a container: ~$ docker run -p : -e EULA= itzg/minecraft-server

Unable to find image locally
latest: Pulling itzg/minecraft-server
...

Status: Downloaded newer image itzg/minecraft-server:latest
...

[init] Checking files.
[init] Setting initial memory to G and max to G
[init] Starting the Minecraft server...
...

[Server thread/INFO]: Preparing start region dimension minecraft:overworld
[Worker-Main /INFO]: Preparing spawn area: %
...

[Server thread/INFO]: Done ( s)! For help, type ... 25000 25565 true 'itzg/minecraft-server:latest' from for for JSON 1 1 for -5 1 40.436 "help" As our container starts up, it downloads the Docker image for the Minecraft server. Once the image downloads, it starts up the server, and we see the log messages of the server startup. Here's an explanation of flags and options we provided to docker run in our command: specifies a port on the host (your local machine) that Docker should bind to a port on the container. In this case, our local machine's port 25000 will point to the container's port 25565. By default, Minecraft servers run on port 25565. Typically, you will always bind to the container's port 25565, regardless of the port on the host that you choose to use. -p provides an environment variable that the Docker container needs to use when starting up the server within the container. The Minecraft server application requires that you accept the EULA upon startup. Providing this environment variable is the Docker way to do that. -e EULA=true Lastly, we specify the name of the Docker image (on ), which contains the Minecraft server. DockerHub With our server running, let's see if we can connect to the server at localhost:25000. Open up the Minecraft Launcher client and click on "Play". The actual Minecraft game should launch. For game options, click on "Multiplayer". Next, click on "Direct Connection". For server address, enter localhost:25000. Our local port 25000, of course, is bound to the container running our Minecraft server. Finally, we click on "Join Server". And… we're in! If you look back at the terminal with the command, you'll recall that it continues to output the log messages from the Minecraft server. It might look something like this: docker run ...
 
[User Authenticator # /INFO]: UUID player familycodingfun is b4fb92b c6 a-bf32-fea282fc8a25
[Server thread/INFO]: familycodingfun[ 1 of 8 -24 -423 /172.17.0.1:53248] logged in with entity id 282 at (243.5, 65.0, -138.5)
[Server thread/INFO]: familycodingfun joined the game The server notes that a new player (my username is ) has joined the game. Our single game server setup is complete. Now, let's add Kong Gateway and port forwarding to the mix. For now, we'll exit the game and then kill our Docker container with the server. familycodingfun Step 2: Minecraft Server with Kong Gateway and Port Forwarding Next, we'll put Kong Gateway in front of our Minecraft server and take advantage of port forwarding. If you were running a private network, you might forbid requests from outside the network to reach your Minecraft server port. At the same time, you might expose a single port on which Kong listens. Kong, as the API gateway, would listen to requests on that port and then forward those requests to your Minecraft server. Doing so ensures that any requests that want to go to a Minecraft server must go through Kong first. Although we'll be working within localhost, we'll set up this kind of port forwarding through Kong. Just like in our previous step, we want our Minecraft server to run on port 25000. Meanwhile, Kong will listen on port 20000. Kong will take TCP connection requests on port 20000 and forward them to the Minecraft server at port 25000. Install and Setup Kong The first step is to . The vary depending on your unique setup. After installing Kong, we'll need to set up the initial configuration file. In your folder, you'll see a template file called . We will copy this file and rename it as , which is the file that Kong will look to for its startup configuration: install Kong Gateway installation steps /etc/kong kong.conf.default kong.conf ~$ cd /etc/kong
/etc/kong$ sudo cp kong.conf.default kong.conf
/etc/kong$ tree
.
├── kong.conf
├── kong.conf.default
└── kong.logrotate directories, files 0 3 In , we'll need to make the following three edits: kong.conf # PATH: kong/kong.conf

#
# Around line Uncomment and set TCP listening on port #

stream_listen = : #
# Around line Uncomment and set database to off
#
 
database = off

#
# Around line Uncomment and set to a file we /etc/ 368. for 20000 127.0 .0 .1 20000 922. 1106. 're about to create.
#                   Use the absolute path to a project folder
#

declarative_config = /PATH/TO/MY/project/minecraft-kong.yml The configuration tells Kong to listen for streaming TCP traffic. We're telling Kong to listen on port 20000 for this. For the needs of this mini project, we can configure Kong using its style. Kong will not need to use a database (database = off), and all of our configurations for port forwarding and load balancing will be stored in a single YAML file. That is the file path that we've set above. stream_listen DB-less and Declarative configuration declarative_config Write Declarative Configuration File Before we start up Kong, we need to write that file with our port forwarding configuration. In a project folder (that matches the path you specified above), open up a new file called : minecraft-kong.yml minecraft-kong.yml # PATH: ~ necraft-kong.yml

_format_version: services:
  - name: Minecraft-Server-A
    url: tcp: routes:
      - name: Server-A-TCP-Routes
        protocols: [ , ]
        destinations:
          - ip: port: /project/mi "2.1" //localhost:25000 "tcp" "tls" 127.0 .0 .1 20000 In this file, we declare a new named Minecraft-Server-A. The server uses the TCP protocol, listening on localhost port 25000, so we set these values together as the service's url. Next, we define a for the service, which associates our service with a URL path or an incoming connection destination that Kong will listen for. We provide a name for our route, telling Kong to listen for requests using TCP/TLS on the destination that we specified in our file: ip 127.0.0.1 and port 20000. Service entity Route kong.conf Start Up Minecraft Server and Kong We’ve written all of our configuration for this step. Let's start up our Minecraft server in Docker. Remember, we want our host (our local machine) to be ready on port 25000, binding that port to the standard Minecraft server port of 25565 on the container: ~/project$ docker run -p 25000:25565 -e EULA=true itzg/minecraft-server That command might take a little time to run as the server starts up. Now, in a separate terminal window, we'll start up Kong: ~/project$ sudo kong start With our server up and running, we go back to our game client and, just like above, choose "Multiplayer" and try to establish a "Direct Connection" with a game server. We know that we could connect directly to localhost:25000, since that's the actual host port bound to the container's port; rather, we want to test Kong's port forwarding. We want to connect to the supposed game server on localhost:20000, pretending that we're the casual user who is unaware that port 20000 points to a port forwarding gateway. Click on "Join Server." Like Step 1, your connection should be successful, and you'll have entered the Minecraft world. Our TCP connection request to localhost:20000 went to Kong Gateway, which then forwarded that request to port 25000, our actual Minecraft server. We have port forwarding up and running! Step 3: Load-Balancing Two Minecraft Servers We will spin up two Minecraft servers for the final step in our mini-project, listening on ports 25000 and 26000. Previously, when we only had one Minecraft server, Kong would naturally forward TCP requests at port 20000 to that sole Minecraft server's port. Now, with two Minecraft server ports to choose from, we'll need to use port forwarding and load balancing. Kong Gateway will take TCP connection requests that come to port 20000 and distribute connections evenly between Minecraft Server A and Minecraft Server B. Start Up Minecraft Servers If you haven't done so already, terminate the single Minecraft server that was running in the previous step. We'll start everything up again from a clean state, spinning up each server in its own terminal window. In your first terminal window, run the Docker container for Server A, binding the host's port 25000 to the container's port 25565: ~/project$ docker run -p 25000:25565 -e EULA=true itzg/minecraft-server Then, in a separate terminal window, we will start up Server B, this time binding the host's port 26000 to the container's port 25565: ~/project$ docker run -p 26000:25565 -e EULA=true itzg/minecraft-server Now, we have Servers A and B running, accessible at ports 25000 and 26000, respectively. Edit Declarative Configuration File Next, we want to edit our declarative configuration file ( ), configuring Kong for load balancing. Edit your file to reflect the following: minecraft-kong.yml # PATH: ~ necraft-kong.yml
_format_version: upstreams:
  - name: Minecraft-Servers
    targets:
      - target: localhost: weight: - target: localhost: weight: services:
  - name: Load-Balancing-Service
    host: Minecraft-Servers
    protocol: tcp
    routes:
      - name: Load-Balancing-Route
        protocols: [ , ]
        destinations:
          - ip: port: /project/mi "2.1" 25000 100 26000 100 "tcp" "tls" 127.0 .0 .1 20000 Let's walk through what we've done here. First, we added an (arbitrarily named Minecraft-Servers), which functions as a virtual host for load balancing to multiple services. That's exactly the functionality that we need. We added two to our upstream service. Each target has an address with host and port; in our case, our two targets point to localhost:25000 (Minecraft Server A) and localhost:26000 (Minecraft Server B). Then, we set a weight for each target, which the load balancer uses to distribute load. Even though we've explicitly set the weights evenly to 100, the default for this optional configuration is 100. Upstream Object Target Objects Next, we declared our Service Object, which in this case is our load balancer service. Requests that satisfy the routes we establish will be forwarded to the Minecraft-Servers host, our load balancing upstream object. Similar to our previous step, we configured a route, telling Kong Gateway to listen for TCP/TLS requests destined for 127.0.0.1:20000. Restart Kong Since our Kong configuration has changed, we need to restart Kong for the changes to take effect: ~/project$ sudo kong restart At this point, everything is up and running. We have our two Minecraft servers (Server A and Server B) running in Docker containers in two separate terminal windows. We have Kong configured to listen for TCP on port 20000, forwarding those requests to our load balancer, distributing connections across our two servers. Open the Minecraft game client again. Similar to previous steps, we will attempt to connect to the multiplayer server at localhost:20000 directly. As you connect, keep an eye on your two server terminal windows. As you repeatedly connect to the game, disconnect, and then reconnect, you will at times see a connection log message for Server A, and then at other times a message for Server B. And just like that, we have set up our load balancer to distribute connection requests across our two Minecraft servers! Ready to (Play) Work To recap, we slowly progressed in complexity for our mini-project: We started by simply spinning up a single Minecraft server in a Docker container, using port 25000 for accepting game client connections. Next, we configured Kong Gateway to sit in front of our single server to perform port forwarding. Kong listened on port 20000 for game client connections, forwarding those requests to the port on our host where the Minecraft server was accessible. Lastly, we set up two Minecraft servers to run concurrently. Then, we configured Kong Gateway to act as a load balancer. Kong listened on port 20000 for game client connections, this time funneling them through its load balancing service to distribute connections across our two servers. From here, you have many opportunities for adding complexity. You can add more game servers. For example, if some servers run on machines that can handle a heavier load of connections than others, then you can configure the load balancer to distribute the load unevenly. You can configure health check rules for Kong's load balancer to ensure requests are only forwarded to those servers which are presently healthy. You can even select from a handful of load balancing algorithms besides the default "round-robin" strategy. So, we've had a little fun and learned to use some important tools and concepts along the way. We have discovered that load balancing and port forwarding with Kong Gateway is simple and easy to set up. Yet, even with such ease, these features are extremely powerful. Now that you've got a handle on it, it's time to get to work and face the . Ender Dragon Also published on: https://medium.com/geekculture/load-balancing-minecraft-servers-with-kong-gateway-99e7aee1bbcc

KONG

konghq.com

-- employees

Since n.d.

COMPANY RANKING

KONG

EVERGREEN INDEX #5725

Representing this company? Click here to claim and customize this page!

Kong WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

KONG

konghq.com

-- employees

Since n.d.

COMPANY RANKING

KONG

EVERGREEN INDEX #5725

RELATED COMPANIESRANK

STORIES ABOUT KONG

Representing this company? Click here to claim and customize this page!

Kong WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!