Skip to content

Latest commit

 

History

History
114 lines (82 loc) · 3.36 KB

Readme.dev.md

File metadata and controls

114 lines (82 loc) · 3.36 KB
Raw

This document is intended for Developers

Testing

Unit tests are not fully done yet

Performance test was done using K6 and 1400 up to 5800 virtual users.

Have a look at the table below:

Virtual Users Kong Served Kong Failed % Failed AWS Gateway served AWS Failed % Failed
1400 1026502 76084 6.90% 1086040 50 0
2200 1037397 337255 24.53% 1093566 655754 37.48%
2800 1037481 389040 27.27% 1044843 849726 44.85%
3500 1044854 327536 23.86% 843754 2005030 70.38%
5800 1044899 285553 21.46% 668146 3936820 85.49%

Based on the results above, we assume that this plugin and Kong is more reliable than AWS API Gateway, at least in the case when a lot of users have to be served.

Plugin Development

Below you will find some actions you might want to perform during plugin development

  • restarting dev env

    pongo down && pongo run --no-cassandra && pongo shell

  • starting kong

    kong migrations bootstrap --force && kong start

  • inspect logs

    Run the command on pongo host machine.

    pongo tail

  • reloading kong

    kong reload

  • exporting ENV var used below

    export kong_proxy_url=http://localhost:8000
export kong_admin_url=http://localhost:8001
export service_name=echo 
export plugin_name=aws-request-signing
export lambda_host=example.com

  • exporting Token used to AssumeRoleWithWebIdentity

    export auth_token=

  • Configuring a simple service + route + plugin

    curl -i -X POST \
 --url $kong_admin_url/services/ \
 --data "name=$service_name" \
 --data "url=http://$lambda_host/"
 
curl -i -X POST \
 --url $kong_admin_url/services/$service_name/routes \
 --data "paths[]=/$service_name"
 
curl -i -X POST \
 --url $kong_admin_url/services/$service_name/plugins/ \
 --data "name=$plugin_name" \
 --data 'config.aws_assume_role_arn=arn:aws:iam::100000000000:role/lambda-access-role' \
 --data 'config.aws_assume_role_name=lambda-access-role'\
 --data 'config.aws_region=eu-west-1' \
 --data 'config.aws_service=lambda' \
 --data 'config.override_target_host=someString.lambda-url.eu-west-1.on.aws' \
 --data 'config.override_target_port=443' \
 --data 'config.override_target_protocol=https'

  • Simple Kong call

    curl -v -H "Authorization: Bearer $auth_token" $kong_proxy_url/$service_name

  • Complex Kong call

    curl -v -H "Authorization: Bearer $auth_token" -H "Content-Type: application/json" $kong_proxy_url/$service_name?query=true --data '{"username":"xyz","password":"xyz"}'

  • Just like above with forced credentials refresh

    curl -v -H "Authorization: Bearer $auth_token" -H "Content-Type: application/json" -H "x-sts-refresh: true" $kong_proxy_url/$service_name?query=true --data '{"username":"xyz","password":"xyz"}'

  • Change upstream of the service

    curl -i -X PATCH \
 --url "$kong_admin_url/services/$service_name" \
 --data "url=https://new.example.com/"