Feature teams
Publish an API through Kong, with its consumers
Describe your API with an OpenAPI document. Add a Kong target and a kong-api deployment. List the consumers and their roles in the same file, and review the change in a plan.
With Joomiz
-
Declare the OpenAPI document
Add an artifact of type
kong-oas. Itspathnames the OpenAPI document in your repository. Joomiz does not check that the file exists.joomiz.yaml, artifacts - id: partner-api-oas type: kong-oas spec: path: src/main/resources/openapi/partner-api.yaml -
Name the Kong control plane
Add a target of type
kong-gateway. It names the Kong control plane that your environment publishes APIs onto.joomiz.yaml, targets - id: test-gateway type: kong-gateway spec: control-plane-name: partner-apis-test -
Publish with consumers
Add a
kong-apideployment. It puts the artifact on the target. Each consumer has anid, anameand optional roles on the API.joomiz.yaml, deployments - id: partner-api-test-gateway-api type: kong-api artifact: partner-api-oas target: test-gateway spec: consumers: - id: partner-portal name: Partner Portal roles: - read - write # ... -
Review a consumer change
Add or remove a consumer, then run
joomiz plan. Only the Kong deployment changes. The jar and the database are not in the plan.$ joomiz plan --environment test deployment/kong-api: succeeded — Planned 1 change ... inventory-api-test-gateway-api (updated): succeeded — Would ... 1 resource type, 1 resource
What you get
- The API, its gateway and its consumers described in one reviewed file.
- A consumer added or removed by a one-line change and a plan.
- A plan that lists only what changed, so reviewers read less.
The rules that still hold
- A
kong-apideployment accepts only akong-oasartifact and akong-gatewaytarget. - One deployment lists at most 100 consumers.
- The platform team decides which Kong control plane names and provisioners exist.
Read more in the docs
Related use cases
Talk to us
Tell us about your platform and the services your teams ship.