Kong API Gateway + Docker Demo

Monolith vs Microservices

Before we discuss the API, API Gateway or Kong Gateway, let’s talk about what is monolith and microservices architecture.

Normally when we start to develop a new application, we will keep all the code in a single repository, it will contain the front end code, business logic, and data access layer, this is a very conversational 3 tier or MVC (Model, View, Control) model. If the application is small and the development team is small, this is the effective way to do the development.

But when your team add more features to the application, the code base will grow rapidly, any minor code change may involve the whole deployment of the code base, you also need to run the test for the whole system, and it may end up with longer deployment time.

On the other hand, microservice architecture recommends that we should break our monolith application into smaller services based on their service or function. There are some pros and cons in the microservice architecture as well, the biggest advantage is we break our codebase into small manageable chunks, every single service can use its own technology stack as well as different programming languages, with that, every microservice able to be deployed using its own pipeline.

Microservices do come with some disadvantages, as all the microservices have their datastore to keep the data isolated from others, so the only way for data exchange between those services is via the API that is exposed, hence it may increase system complexity.

What is API Gateway?

An API gateway is a reverse proxy that allows your organization to offer APIs as a product to internal or external clients via a centralized ingress point. An example of a client might be the front end of your application in the form of a web page, internal services that need to interact with your application, or third-party client websites. API gateways enable communication between different internal and external business applications and can be used to create an abstraction layer between clients and the underlying APIs.

On top of that, an API Gateway also comes with additional features on top of proxying your traffic to the target endpoint, those features such as authentication, traffic control, transformations, logging and caching, which vary from product to product.

Some of the examples of API Gateway that are available in the market

Open-sourceProprietary
Kong API GatewayAWS API Gateway
TykGCP Cloud Endpoint
OcelotAzure API Gateway
Goku API GatewayApigee
Express GatewayIBM API Connect
API Man3 Scale
Loopback API FrameworkMuleSoft Anypoint API Management
API UmbrellaAkana
DreamFactoryWSO2 API Manager

What is Kong API Gateway?

Kong API Gateway is a widely adopted, open-source API Gateway and it makes connecting APIs and microservices across hybrid or multi-cloud environments easier and faster. It provides a flexible abstraction layer that securely manages communication between clients and microservices via API.

Kong API Gateway is written in Lua script running in Nginx, and leverages the OpenResty framework, it is one of the world’s most popular open-source API Gateway which has more than 31.3k stars in the Github repository, it builds for multi-cloud and hybrid, and optimized for microservices and distributed architectures.

Kong was originally built at Mashape to secure, manage, and extend over 15,000 APIs and Microservices for its API Marketplace, which generates billions of requests per month for over 200,000 developers. Today Kong is used in mission-critical deployments at small and large organizations. Here are some characteristics:

  • Scalable: Kong easily scales horizontally by simply adding more machines, meaning your platform can handle virtually any load while keeping latency low.
  • Modular: Kong can be extended by adding new plugins, which are easily configured through a RESTful Admin API.
  • Runs on any infrastructure: Kong runs anywhere. You can deploy Kong in the cloud or on-premise environments, including single or multi-datacenter setups and for public, private, or invite-only APIs.

Kong API Gateway package and modes

  • Kong Gateway (OSS): an open-source package that contains only the basic API gateway functionality and open-source plugins, you can configure the open-source gateway using the admin API or with the declarative configuration (decK).
  • Kong Gateway: available in Free, Plus and Enterprise mode
    • Free Mode: Additional admin GUI on top of open-source functionality
    • Plus Mode: More features than the open-source version, but only available through the Konnect Cloud (SAAS)
    • Enterprise subscription: Full features available, self-managed and hosting, it also includes the additional tools include
      • Dev Portal: API documentation portal, able to create a custom page, manage API versions and secure developer access
      • Vitals: Monitoring tools to view the node health
      • RBAC: Role-based access control
      • Enterprise Plugins: Advance plugin develop and support by Kong

How does Kong work?

Kong Server

Kong server which builds on top of Nginx as its core engine to process all the API requests and execute the plugin base on the configuration to provide the functionalities. Kong API Gateway exposes two endpoints:

  • Proxy endpoint: to forward the request from client/service to the upstream API, by default is listening on port 8000 for HTTP traffic and port 8443 for HTTPS traffic
  • Admin endpoint: to manage and configure the server, it’s use port 8001 (HTTP) and port 8444 (HTTPS)

As a security best practice, Admin API ports are for internal use and should be firewalled.

Kong Datastore

Kong uses an external datastore to keep all the configuration for the server, the datastore that is currently supported by Kong including Casandra (will be deprecate in version 4) and Postgresql. You may configure your gateway using the admin API and Kong will store it in the datastore, and multiple Kong nodes can retrieve the configuration from the centralised datastore.

Kong DB-less mode and declarative configuration

Other than an external datastore to keep the configuration data, Kong also supports DB-less mode, which will keep all the configuration in a JSON or YAML formatted configuration file, thus Kong reads this file to get configuration directives and write it to the node’s memory.

This mode is most suitable for the immutable deployment method where you can manage your Kong using the CI/CD tool, and all the configuration directives are also stored in the static file in your git repo. However you can’t make any update or change to the server using the admin API as it’s only read-only access, any update or change to your configuration may need to update directly to the configuration file and reload the server.

Moreover, some useful plugins are not compatible with this mode, since they require a database by design.

Konga – More than just another Kong GUI

Konga is an open-source GUI tool that enables you to manage your Kong API Gateway with ease. It helps to manage all Kong admin API objects and multiple Kong nodes. It’s also able to provide the features to backup, restore as well as migrate Kong nodes using the snapshots.

Setup the demo stacks

In this demonstration, I will set up the following services using the docker-compose.yaml:

  1. Postgresql
  2. Kong API Gateway
  3. Konga
  4. Nginx (act as the load balancer)

Postgresql will be used as the datastore for the Kong server as well as Konga, once the datastore is up, will use the kong database migration command to bootstrap the datastore then only install the Kong server. Once the server is ready, the compose file will be spinning up the Konga.
The last step of the compose file will be spinning up the Nginx as the load balancer sitting in front of the Kong server.

Once the setup is done, I will use Terraform code to configure the API Gateway.

This is the folder structure for the demo application, and the code can be found in: https://github.com/david2331/kong-api-gateway

docker-compose.yaml

version: "3"

networks:
 kong-net:
  driver: bridge

services:

  #######################################
  # Postgres: The database used by Kong
  #######################################
  kong-database:
    image: postgres:9.6
    restart: always
    networks:
      - kong-net
    environment:
      POSTGRES_PASSWORD: kong
      POSTGRES_USER: kong
      POSTGRES_DB: kong
    ports:
      - "5432:5432"
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "kong"]
      interval: 5s
      timeout: 5s
      retries: 5

  #######################################
  # Kong database migration
  #######################################
  kong-migration:
    image: kong:latest
    command: "kong migrations bootstrap"
    networks:
      - kong-net
    restart: on-failure
    environment:
      KONG_PG_HOST: kong-database
      KONG_DATABASE: postgres
      KONG_PG_PASSWORD: kong
    links:
      - kong-database
    depends_on:
      - kong-database

  #######################################
  # Kong: The API Gateway
  #######################################
  kong:
    image: kong:latest
    restart: always
    networks:
      - kong-net
    environment:
      KONG_DATABASE: postgres
      KONG_PG_HOST: kong-database
      KONG_PG_USER: kong
      KONG_PG_PASSWORD: kong
      KONG_PROXY_LISTEN: 0.0.0.0:8000
      KONG_PROXY_LISTEN_SSL: 0.0.0.0:8443
      KONG_ADMIN_LISTEN: 0.0.0.0:8001
    depends_on:
      - kong-migration
      - kong-database
    healthcheck:
      test: ["CMD", "curl", "-f", "http://kong:8001"]
      interval: 5s
      timeout: 2s
      retries: 15
    # ports:
    #   - "8001:8001"
    #   - "8000:8000"
    expose:
      - "8001"  # admin endpoint
      - "8000"  # proxy endpoint
      
  #######################################
  # Konga database prepare
  #######################################
  konga-prepare:
    image: pantsel/konga:next
    command: "-c prepare -a postgres -u postgresql://kong:[email protected]:5432/konga_db"
    environment:
      DB_ADAPTER: postgres
      DB_HOST: kong-database
      DB_USER: kong
      DB_PASSWORD: kong
    networks:
      - kong-net
    restart: on-failure
    links:
      - kong-database
    depends_on:
      - kong-database

  #######################################
  # Konga: Kong GUI
  #######################################
  konga:
    image: pantsel/konga:next
    restart: always
    networks:
        - kong-net
    environment:
      DB_ADAPTER: postgres
      DB_HOST: kong-database
      DB_USER: kong
      DB_PASSWORD: kong
      TOKEN_SECRET: km1GUr4RkcQD7DewhJPNXrCuZwcKmqjb
      DB_DATABASE: konga_db
      NODE_ENV: production
    depends_on:
      - kong-database
    ports:
      - "1337:1337"


  #######################################
  # Nginx: Load Balancer
  #######################################
  nginx:
    image: nginx:latest
    networks:
        - kong-net
    restart: always
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      - kong
    ports:
      - "8000:8000"
      - "8001:8001"

nginx.conf

user  nginx;

events {
    worker_connections   1000;
}
http {
        server {
              listen 8000;
              location / {
                proxy_pass http://kong:8000;
              }
        }

        server {
              listen 8001;
              location / {
                proxy_pass http://kong:8001;
              }
        }
}

To deploy the stack, just go to the kong folder and run the command “docker-compose up -d” as follows.

$ cd kong

$ docker-compose up -d
Creating network "kong-tribal-knowledge_kong-net" with driver "bridge"
Creating kong-tribal-knowledge_kong-database_1 ... done
Creating kong-tribal-knowledge_konga_1          ... done
Creating kong-tribal-knowledge_konga-prepare_1  ... done
Creating kong-tribal-knowledge_kong-migration_1 ... done
Creating kong-tribal-knowledge_kong_1           ... done
Creating kong-tribal-knowledge_nginx_1          ... done

$ docker ps
CONTAINER ID   IMAGE                COMMAND                  CREATED          STATUS                             PORTS                                                                   NAMES
4335462ac32c   nginx:latest         "/docker-entrypoint.…"   29 seconds ago   Up 16 seconds                      80/tcp, 0.0.0.0:8000-8001->8000-8001/tcp, :::8000-8001->8000-8001/tcp   kong-tribal-knowledge_nginx_1        
567705d65ad3   kong:latest          "/docker-entrypoint.…"   30 seconds ago   Up 17 seconds (health: starting)   8000-8001/tcp, 8443-8444/tcp                                            kong-tribal-knowledge_kong_1
11750a90b25a   pantsel/konga:next   "/app/start.sh"          31 seconds ago   Up 30 seconds                      0.0.0.0:1337->1337/tcp, :::1337->1337/tcp                               kong-tribal-knowledge_konga_1        
4d75fc17210c   postgres:9.6         "docker-entrypoint.s…"   34 seconds ago   Up 31 seconds (healthy)            0.0.0.0:5432->5432/tcp, :::5432->5432/tcp                               kong-tribal-knowledge_kong-database_1

$ http :8001
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Length: 10104
Content-Type: application/json; charset=utf-8
Date: Thu, 31 Mar 2022 02:32:47 GMT
Server: nginx/1.21.6
X-Kong-Admin-Latency: 1403

{
    "configuration": {
        "admin_acc_logs": "/usr/local/kong/logs/admin_access.log",
        "admin_access_log": "logs/admin_access.log",
        "admin_error_log": "logs/error.log",
        "admin_listen": [
            "0.0.0.0:8001"
        ],
        "admin_listeners": [
            {
                "backlog=%d+": false,
                "bind": false,
                "deferred": false,
                "http2": false,
                "ip": "0.0.0.0",
                "listener": "0.0.0.0:8001",
                "port": 8001,
                "proxy_protocol": false,
                "reuseport": false,
                "ssl": false
            }
        ],
...
...
    "plugins": {
        "available_on_server": {
            "acl": true,
            "acme": true,
            "aws-lambda": true,
            "azure-functions": true,
            "basic-auth": true,
            "bot-detection": true,
            "correlation-id": true,
            "cors": true,
            "datadog": true,
            "file-log": true,
            "grpc-gateway": true,
            "grpc-web": true,
            "hmac-auth": true,
            "http-log": true,
            "ip-restriction": true,
            "jwt": true,
            "key-auth": true,
            "ldap-auth": true,
            "loggly": true,
            "oauth2": true,
            "post-function": true,
            "pre-function": true,
            "prometheus": true,
            "proxy-cache": true,
            "rate-limiting": true,
            "request-size-limiting": true,
            "request-termination": true,
            "request-transformer": true,
            "response-ratelimiting": true,
            "response-transformer": true,
            "session": true,
            "statsd": true,
            "syslog": true,
            "tcp-log": true,
            "udp-log": true,
            "zipkin": true
        },
        "enabled_in_cluster": []
    },
    "tagline": "Welcome to kong",
    "timers": {
        "pending": 10,
        "running": 0
    },
    "version": "2.8.0"
}        

To scale the Kong

$ docker-compose scale kong=5

Starting kong-tribal-knowledge_kong_1 ... done
Creating kong-tribal-knowledge_kong_2 ... done
Creating kong-tribal-knowledge_kong_3 ... done
Creating kong-tribal-knowledge_kong_4 ... done
Creating kong-tribal-knowledge_kong_5 ... done

Configure Kong using Terraform

In the terraform script, I will create the following item:

  1. 2 x consumers
  2. Route, services and upstream base on Swagger UI
  3. Global rate-limiting plugin
  4. Global syslog plugin

First, initialize the terraform provider

$ cd kong-configuration

$ terraform init
Initializing the backend...

Initializing provider plugins...
- Reusing previous version of greut/kong from the dependency lock file
- Reusing previous version of hashicorp/random from the dependency lock file
- Using previously-installed greut/kong v5.3.0
- Using previously-installed hashicorp/random v3.1.1

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Terraform plan to view the change and apply change to the Kong

$ terraform plan 

random_integer.weight: Refreshing state... [id=552]
kong_plugin.rate_limit: Refreshing state... [id=31be8c1e-f2c6-4886-b8b2-39f58020a89a]  
kong_service.service2[4]: Refreshing state... [id=ffc1bc7c-3826-4bb5-a02b-9acb49e928f5]
kong_service.service2[1]: Refreshing state... [id=af00c576-6237-4201-8e14-4ba76a841aa2] 
kong_consumer.consumer[0]: Refreshing state... [id=33fcb87a-5af4-4422-888d-1417d9a1eef6]
kong_consumer.consumer[1]: Refreshing state... [id=1dd80a3b-c07a-4287-a96c-572e45ad91e1]
kong_plugin.syslog: Refreshing state... [id=7f8fea2b-b8bf-4ca3-8bce-b9e2fa972b3d]       
kong_service.service2[3]: Refreshing state... [id=a4d7f9c8-d9f9-407b-a474-45f66924f3df] 
kong_service.service2[2]: Refreshing state... [id=fc41dcff-2916-4f50-be59-5027779a6314] 
kong_service.service2[0]: Refreshing state... [id=cf2ad336-5e1c-4b6e-b8fb-5ff4eb571df7] 
kong_upstream.petstore: Refreshing state... [id=526e56c5-1f59-4660-a232-52e4731e4134]
kong_target.petstore_upstream_target[0]: Refreshing state... [id=526e56c5-1f59-4660-a232-52e4731e4134/4a441ab1-c1d1-4156-a685-2a682064af40]
kong_service.service: Refreshing state... [id=014f90f3-ed9a-4155-bf7f-563756358f69]
kong_route.api_route2[2]: Refreshing state... [id=9c6165d6-8dad-4f0c-924d-75f67c8c6724]
kong_route.api_route2[0]: Refreshing state... [id=bb250ca8-b3ce-4ef1-ade2-45e2dff60cfc]
kong_route.api_route2[3]: Refreshing state... [id=75162952-60d9-48d7-8248-29b7943e89a9]
kong_route.api_route2[4]: Refreshing state... [id=95f31b93-36a0-4643-9504-a19736bd63ba]
kong_route.api_route2[1]: Refreshing state... [id=4f754fb9-14fb-4818-bfc7-0ceb185c2d24]
kong_route.api_route: Refreshing state... [id=e466a799-9c84-4aff-8c4a-aee6e1c5d44c]    

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the last "terraform apply":

  # kong_consumer.consumer[0] has been deleted
  - resource "kong_consumer" "consumer" {
      - id       = "33fcb87a-5af4-4422-888d-1417d9a1eef6" -> null
      - username = "Contoso" -> null
      
  ...   
  
              + healthy {
                  + http_statuses = (known after apply)
                  + successes     = (known after apply)
                }

              + unhealthy {
                  + http_failures = (known after apply)
                  + http_statuses = (known after apply)
                  + tcp_failures  = (known after apply)
                  + timeouts      = (known after apply)
                }
            }
        }
    }

Plan: 18 to add, 0 to change, 0 to destroy.

───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── 

$ terraform apply --auto-approve
kong_plugin.syslog: Refreshing state... [id=7f8fea2b-b8bf-4ca3-8bce-b9e2fa972b3d]
kong_consumer.consumer[1]: Refreshing state... [id=1dd80a3b-c07a-4287-a96c-572e45ad91e1]
kong_service.service2[4]: Refreshing state... [id=ffc1bc7c-3826-4bb5-a02b-9acb49e928f5]
kong_service.service2[0]: Refreshing state... [id=cf2ad336-5e1c-4b6e-b8fb-5ff4eb571df7]
kong_service.service2[3]: Refreshing state... [id=a4d7f9c8-d9f9-407b-a474-45f66924f3df]
kong_service.service2[2]: Refreshing state... [id=fc41dcff-2916-4f50-be59-5027779a6314]
kong_service.service2[1]: Refreshing state... [id=af00c576-6237-4201-8e14-4ba76a841aa2]
kong_upstream.petstore: Refreshing state... [id=526e56c5-1f59-4660-a232-52e4731e4134]
kong_plugin.rate_limit: Refreshing state... [id=31be8c1e-f2c6-4886-b8b2-39f58020a89a]
kong_consumer.consumer[0]: Refreshing state... [id=33fcb87a-5af4-4422-888d-1417d9a1eef6]
random_integer.weight: Refreshing state... [id=552]
kong_service.service: Refreshing state... [id=014f90f3-ed9a-4155-bf7f-563756358f69]
kong_target.petstore_upstream_target[0]: Refreshing state... [id=526e56c5-1f59-4660-a232-52e4731e4134/4a441ab1-c1d1-4156-a685-2a682064af40]
kong_route.api_route2[4]: Refreshing state... [id=95f31b93-36a0-4643-9504-a19736bd63ba]
kong_route.api_route2[1]: Refreshing state... [id=4f754fb9-14fb-4818-bfc7-0ceb185c2d24]
kong_route.api_route2[3]: Refreshing state... [id=75162952-60d9-48d7-8248-29b7943e89a9]
kong_route.api_route2[2]: Refreshing state... [id=9c6165d6-8dad-4f0c-924d-75f67c8c6724]
kong_route.api_route2[0]: Refreshing state... [id=bb250ca8-b3ce-4ef1-ade2-45e2dff60cfc]
kong_route.api_route: Refreshing state... [id=e466a799-9c84-4aff-8c4a-aee6e1c5d44c]

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the last "terraf..orm apply":

... ...

kong_route.api_route2[2]: Creating...
kong_route.api_route2[4]: Creating...
kong_target.petstore_upstream_target[0]: Creating...
kong_service.service: Creating...
kong_service.service: Creation complete after 0s [id=5f00f525-6bc6-48ec-bcda-675cfe02c644]
kong_route.api_route: Creating...
kong_route.api_route2[4]: Creation complete after 0s [id=379465e8-51e2-4497-9904-293d114e0282]
kong_route.api_route2[3]: Creation complete after 0s [id=4436c8bd-7bb4-486a-8703-0477b6eed643]
kong_route.api_route2[1]: Creation complete after 0s [id=7c0ae361-0701-457c-99a8-3e2ea99b7671]
kong_route.api_route2[0]: Creation complete after 0s [id=96cd273b-ed3a-4f01-8747-0f647141b6af]
kong_route.api_route2[2]: Creation complete after 0s [id=07fbc81b-1013-4da9-b78a-f1eb7209a58e]
kong_route.api_route: Creation complete after 0s [id=03cd725a-d41a-4e6a-bcfa-3ee03f421566]
kong_target.petstore_upstream_target[0]: Creation complete after 0s [id=2d211237-e0b6-48d5-8986-baba5439e614/8b7b3e32-5aea-40fc-9d15-bcf829849d67]

Apply complete! Resources: 18 added, 0 changed, 0 destroyed.

Up now, we have already successfully deployed our Kong stack with configuration.

Now we can log in to the Konga GUI at the URL: http://localhost:1337, it will ask to create the admin account on the first login.

Once you login to the Konga, you will need to setup the connection to your node, in this demo, the Kong admin API exposes via the Nginx, so the admin URL I just input http://nginx:8001

Once you done connected to the Kong node, it will show the live state of your Kong node. From the left menu, you can configure all the item that available in the Kong gateway including services, routes, consumer, plugins, upstream and certificates. Because I already configure the Kong gateway using the terraform script, so you can just browse on each tabs to see the configuration.

This is the current status for the Kong node showing in Konga GUI
Service configuration for the Kong node
Route configuration for the Kong Node
Consumers configuration in Kong node
2 global plugin being enable – rate-limiting and syslog

Next we can test the API gateway by issue the REST request to the end point. If you wish to get the full list of the API, feel free to download the swagger petstore postman collection at Swagger Petstore | Swagger Petstore | Postman API Network

$ http :8000/pet/10

HTTP/1.1 200 OK
Access-Control-Allow-Headers: Content-Type, api_key, Authorization
Access-Control-Allow-Methods: GET, POST, DELETE, PUT
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Content-Disposition
Connection: keep-alive
Content-Length: 133
Content-Type: application/json
Date: Tue, 05 Apr 2022 10:18:54 GMT
RateLimit-Limit: 5
RateLimit-Remaining: 4
RateLimit-Reset: 7
Server: nginx/1.21.6
Via: kong/2.8.0
X-Kong-Proxy-Latency: 251
X-Kong-Upstream-Latency: 1003
X-RateLimit-Limit-Minute: 5
X-RateLimit-Remaining-Minute: 4

{
    "category": {
        "id": 1,
        "name": "Dogs"
    },
    "id": 10,
    "name": "ss",
    "photoUrls": [
        "string"
    ],
    "status": "available",
    "tags": [
        {
            "id": 0,
            "name": "string"
        }
    ]
}

$ http :8000/store/inventory

HTTP/1.1 200 OK
Access-Control-Allow-Headers: Content-Type, api_key, Authorization
Access-Control-Allow-Methods: GET, POST, DELETE, PUT
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Content-Disposition
Connection: keep-alive
Content-Length: 43
Content-Type: application/json
Date: Tue, 05 Apr 2022 10:20:20 GMT
RateLimit-Limit: 5
RateLimit-Remaining: 4
RateLimit-Reset: 41
Server: nginx/1.21.6
Via: kong/2.8.0
X-Kong-Proxy-Latency: 5
X-Kong-Upstream-Latency: 1012
X-RateLimit-Limit-Minute: 5
X-RateLimit-Remaining-Minute: 4

{
    "approved": 57,
    "delivered": 50,
    "placed": 100
}

To teardown the stack

$ docker-compose down
Stopping kong-tribal-knowledge_nginx_1         ... done
Stopping kong-tribal-knowledge_kong_1          ... done
Stopping kong-tribal-knowledge_konga_1         ... done
Stopping kong-tribal-knowledge_kong-database_1 ... done
Removing kong-tribal-knowledge_nginx_1          ... done
Removing kong-tribal-knowledge_kong_1           ... done
Removing kong-tribal-knowledge_kong-migration_1 ... done
Removing kong-tribal-knowledge_konga-prepare_1  ... done
Removing kong-tribal-knowledge_konga_1          ... done
Removing kong-tribal-knowledge_kong-database_1  ... done
Removing network kong-tribal-knowledge_kong-net

Reference

Sample Project Code: GitHub – david2331/kong-api-gateway: Deploying kong, konga using docker-compose and terraform

Konga: Konga – More than just another GUI to Kong Admin API

Kong: https://konghq.com/kong/

Terraform: Terraform by HashiCorp

Terraform Kong Provider: Terraform Registry

Swagger Petstore: Swagger UI

Kong CE Admin API Collection for Postman: Kong | Postman API Network

Swagger Petstore API Collection for Postman: Swagger Petstore | Swagger Petstore | Postman API Network

Leave a Reply

google.com, pub-3772983857049267, DIRECT, f08c47fec0942fa0
%d bloggers like this: