{"id":23543796,"url":"https://github.com/jimdelois/api-gateway-configs","last_synced_at":"2025-10-08T20:05:27.026Z","repository":{"id":56638538,"uuid":"140979924","full_name":"jimdelois/api-gateway-configs","owner":"jimdelois","description":"A collection of open-source API Gateway configurations","archived":false,"fork":false,"pushed_at":"2020-10-27T17:50:49.000Z","size":642,"stargazers_count":4,"open_issues_count":0,"forks_count":1,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-04-24T00:29:36.779Z","etag":null,"topics":["api-gateway","aws","aws-cloudformation","kong","kong-admin-gui","kong-api","kong-gateway"],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/jimdelois.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2018-07-14T21:42:53.000Z","updated_at":"2021-09-06T14:12:47.000Z","dependencies_parsed_at":"2022-08-15T22:20:49.444Z","dependency_job_id":null,"html_url":"https://github.com/jimdelois/api-gateway-configs","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/jimdelois/api-gateway-configs","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jimdelois%2Fapi-gateway-configs","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jimdelois%2Fapi-gateway-configs/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jimdelois%2Fapi-gateway-configs/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jimdelois%2Fapi-gateway-configs/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/jimdelois","download_url":"https://codeload.github.com/jimdelois/api-gateway-configs/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jimdelois%2Fapi-gateway-configs/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":279000704,"owners_count":26082819,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-10-08T02:00:06.501Z","response_time":56,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["api-gateway","aws","aws-cloudformation","kong","kong-admin-gui","kong-api","kong-gateway"],"created_at":"2024-12-26T07:11:39.127Z","updated_at":"2025-10-08T20:05:26.982Z","avatar_url":"https://github.com/jimdelois.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"**NOTE:** This repository will eventually contain configurations for other OSS Gateways (such as [Gravitee](https://gravitee.io/), [API Umbrella](https://apiumbrella.io/), etc).  [Kong](https://konghq.com/kong/) is currently the only configured Gateway at this time and, thus, remains at the root of the project. This repository will be re-organized once additional Gateways are added.\n\n# Kong\n\n## Overview\n\nThe AWS CloudFormation configuration in this repository is capable of providing the following infrastructure:\n\n![Kong AWS Infrastructure](./aws/Kong-Application-Diagram.png)\n*Some elements omitted*\n\n## Setup / Deployment\n\nThe Kong API Gateway and the associated Konga Admin UI each need their own backing store and their respective schemas correctly installed. Both applications support multiple stores, so to keep things simple and consolidated, we choose the only overlap: Postgres.\n\nKong and Konga both provide their own \"migrations\" management mechanism so an initial setup in either AWS or on one's local will require a couple of extra steps to ensure the database is up-to-date.\n\n### AWS Installation (CloudFormation)\n\n#### Preparation\n\n##### Configuration Parameter Files\n\nSeveral of the CloudFormation templates included within this library are parameterized for flexibility and, in some cases, security. Although the CloudFormation templates may be uploaded to the AWS Console and any parameters may be provided there, the recommended approach (and that which is documented here) is to use the AWS CLI tool. For this method, JSON-formatted files are required to define these parameters during command execution.\n\nThis library provides a set of [sample parameter files](aws/cloudformation/parameters-samples/) to use as a starting point. It is recommended to copy these files into the `aws/cloudformation/parameters/` directory, which is ignored from this repository. There, they may be modified with your own personal configurations without becoming a part of this repository's commit history.\n\nAlternatively, it may be more convenient to symlink the `parameters` directory to a separate, VCS-managed project.\n\n##### Working Directory\n\nThe commands below are shown as executed from the [cloudformation directory](aws/cloudformation/).\n\n```\ncd aws/cloudformation/\n```\n\n\n#### Install the Database\n\nCreate the database independently, as it is extremely time/resource intensive which may\nimpede any modifications to the balance of the stack in the future:\n\n```\naws cloudformation create-stack --stack-name kong-database --template-body file://kong.database.stack.yml --parameters file://parameters/kong.database.stack.json\n```\n\n#### Install the Application\n\nUsing a reviewable change set, create the rest of the stack which installs and starts the entire application:\n\n```\naws cloudformation create-change-set --stack-name kong --change-set-type CREATE --change-set-name InitialRevision --template-body file://kong.stack.yml --parameters file://parameters/kong.stack.json\n```\n\nReview the requested change set:\n\n```\naws cloudformation describe-change-set --change-set-name \"InitialRevision\" --stack-name kong\n```\n\nExtract the ARN and execute the change set:\n\n```\nCHANGESET_ARN=\naws cloudformation execute-change-set --change-set-name $CHANGESET_ARN\n```\n\n**NOTE**: It's possible that the application will thrash a bit if the migrations haven't been run, as it will detect invalid schemas and shut down. Run the migrations, below, and monitor for eventual stability.\n\n#### Run the Schema Migrations\n\nWhether installing a fresh schema or updating an existing one, DB migrations will need to be performed for the the Kong and Konga backing stores.\n\nDepending on the configuration, it may be desirable to scale the EC2 group first, ensuring that there is capacity in the cluster for deploying and executing these tasks.\n\n##### Extracting the AutoScaling Group Name\n\nWe haven't named our AutoScaling Group so as to avoid resource replacement should the need arise to adjust it.  For this reason, we must to extract the name of the group, which has been dynamically generated.  We can list all the groups and pluck out then one we need (which should be obvious):\n\n```\naws autoscaling describe-auto-scaling-groups --query \"AutoScalingGroups[].AutoScalingGroupName\"\n```\n\nOr, if we want the lengthier version of pulling out exactly the correct one:\n\n```\naws autoscaling describe-auto-scaling-groups --query \"AutoScalingGroups[?Tags[?Key == 'aws:cloudformation:logical-id' \u0026\u0026 contains(Value, 'KongECSInstanceAutoScalingGroup')]].AutoScalingGroupName\"\n```\n\n##### Scale the Group Up\n\n```\nGROUP_NAME=\naws autoscaling set-desired-capacity --auto-scaling-group-name $GROUP_NAME --desired-capacity 2 --honor-cooldown\n```\n\nCheck in on these instances with:\n\n```\naws ecs list-container-instances --cluster Kong\n```\n\n##### Perform the Migrations\n\nExecute the migrations by performing the following:\n\n```\n# Kong\naws ecs run-task --cluster Kong --task-definition kongmigration --count 1\n\n# Konga\naws ecs run-task --cluster Kong --task-definition kongamigration --count 1\n```\n\nExtract the Task ARN from that last command and copy it.  This particular migration is performed by running the Konga application in `dev` mode - as such, it will not actually terminate itself and it must be stopped manually:\n\n```\nTASK_ARN=\naws ecs stop-task --cluster Kong --task $TASK_ARN --reason \"Migrations Completed\"\n```\n\n##### Scale the Group Back Down\n\n```\nGROUP_NAME=\naws autoscaling set-desired-capacity --auto-scaling-group-name $GROUP_NAME --desired-capacity 1 --honor-cooldown\n```\n\n#### Install the Auto-Scaling Policies (Optional)\n\nImplementing Auto-Scaling in AWS is done by attaching scaling policies to existing resources.  This one-way dependency of the former on the latter allows us to completely decouple the two. Not only does this make Auto-Scaling entirely optional, it also yields smaller and more manageable/targeted CloudFormation Stack files.\n\nThis could further be broken down into EC2 Instance Auto-Scaling and ECS Service Auto-Scaling. For now, both configurations are managed in the same Stack.\n\nTo install Auto-Scaling Policies:\n\n```\naws cloudformation create-stack --stack-name kong-autoscaling --template-body file://kong.scaling.stack.yml\n```\n\n**TODO:** The Auto-Scaling stack can (and should) be made highly configurable and parameterized.\n\n#### Install Dashboards (Optional)\n\nCloudFormation can manage CloudWatch Dashboards, as well. To keep things reasonably organized and manageable, we separate these into a dedicated stack, as well.  To install:\n\n```\naws cloudformation create-stack --stack-name kong-dashboards --template-body file://kong.dashboards.stack.yml\n```\n\n**TODO:** Do.\n\n#### BONUS: CI/CD Pipeline Auto-Configuration of the API Gateway\n\nAs can be seen in the Stack configs, the Admin API of Kong is tucked away and protected from public access, allowing ingress only from the Konga UI service (which is auth protected by default). However, it is possible to configure the Admin API to be exposed through Kong itself using a [loopback configuration](https://docs.gelato.io/guides/advanced-kong-integration).\n\nNote that the Kong API Gateway makes it possible to import and export configurations.  At the point that the Admin API is exposed (and protected by tokens, etc), any automated process may import configurations, thus making it possible for a CI/CD pipeline for an actual API application to self-register.  Further, this allows for the storage of API Gateway configuration as code, local to the API's repository.  Alternatively, normal HTTP requests may be sent to the Admin API for configuration, as well.\n\nWhile this is extremely powerful, the strategies and options for it are beyond the scope of this documentation.\n\n### Running Locally\n\nThe following will start the Postgres Database service, and then fire up an instance of the Kong\nimage, within which a database migration script will be invoked. This supplies the Kong Gateway\nwith the schema it needs to operate.\n\n```\ndocker-compose up kong-migrate\n```\n\nSimilarly, the Konga UI app needs a backing schema, as well.  To invoke this, ensure that the `konga` stack definition includes `NODE_ENV: dev`, and issue another:\n\n```\ndocker-compose up konga\n```\n\nThis process will need to be terminated (`^C`) when it appears that it is complete.\n\nFinally, restore `NODE_ENV: production` and run the app with:\n\n```\ndocker-compose up -d konga\n```\n\n#### Reverse Proxy\n\nNote that the `docker-compose.yml` file is prepared with a few environment variables intended to be used with the [NGinx Proxy project](https://github.com/jwilder/nginx-proxy). With a working knowledge of that toolset, running also on the bridged network, it becomes trivial to augment the local gateway with SSL and domain names.  \n\nSSL may be terminated at the NGinx Proxy, and a domain name may also be associated with the Konga Admin UI. Note that, for every API that is to be used behind Kong, there will need to be a `VIRTUAL_HOST` domain created in the environment config pointing to the Kong service. As every person's usage of Kong and DNS will be different, it is recommended to extract these configurations to a local `docker-compose.override.yml` which is ignored from this repository. An example file may look like:\n\n```\nversion: '2.2'\n\nservices:\n  kong:\n    environment:\n      VIRTUAL_HOST: .my-api.local.lan,.my-other-api.local.lan,.etc-api.local.lan\n  konga:\n    environment:\n      VIRTUAL_HOST: .konga-ui.local.lan\n```\nNote also that the NGinx Proxy service could also be defined within this file if it is desired to be one-to-one with running Kong.\n\nAt this point, near-production configurations of API applications and the gateway may be obtained on the local environment.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjimdelois%2Fapi-gateway-configs","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjimdelois%2Fapi-gateway-configs","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjimdelois%2Fapi-gateway-configs/lists"}