Enhancing APIOps and Federated API Management with decK 1.24
We are thrilled to announce that we have reached a significant milestone in our journey to provide the best possible developer experience to our Kong user community. We have added a host of new functionality to decK, our declarative management tool for Kong Gateway. These new functions enhance API lifecycle automation (APIOps) capabilities and provide a smoother path to federated API management. These features are now available to everyone and can be found in decK 1.24.0.
Before looking at the new features, let's do a quick recap of API management with decK and federated management.
API management with decK
decK is a popular declarative management tool for Kong Gateway. With decK, users create gateway configurations in a straightforward YAML syntax and build automations for validating and synchronizing them to Kong Gateway. Typically users store these declarative configuration files in source code repositories and build automations using readily available CI/CD tools.
We have learned that as microservice architectures have emerged, users want API management to become less centralized. For example, take a development team with a very domain specific concern. They want to configure an API gateway to pass requests through a serverless function before routing it to their upstream service. Simultaneously, the centralized platform team is tasked with ensuring all APIs conform to the required security policies. What is the best way for these two teams to coordinate the API gateway's configuration while not impeding each other's progress? Federated API management is the solution that allows developer team autonomy and maintains central governance capabilities while permitting shared gateway infrastructure. Let's see how the new decK features can help.
decK file configurations are full configurations. This means, when you synchronize to the gateway, you pass the entire configuration to decK. decK detects necessary changes and enacts them via the gateway Admin API. The full configuration is beneficial as it represents the complete desired state of your gateway. However, as every developer knows, shared files lead to collaboration friction. We've introduced a set of new commands to decK that makes working with partial configurations possible, and will change the way you work with decK files.
Broadly we have introduced two new categories of commands to decK, transformations, and declarative configuration generation. Let's start with transformations.
Transformations
Following the Unix philosophy of keeping components simple and composable, we have added transformations that allow you to build declarative configurations over a sequence of steps. Most developers will be familiar with piping commands on the command line:
ls -l | grep kong
This is how you will work with transformations as well. Transformations can be given a full or a partial configuration file, transform it based on user input, and generate an output that can be written to a file or passed to a subsequent transformation.
Note: All of the new commands operate on decK files only and do not connect to a running gateway. We've organized all of the new commands under a new top-level command named file.
Here is a description of each of the new transformation commands:
deck file patch [flags] [...patch-files] (documentation)
patch is used to apply a partial update to a Kong Declarative configuration using a JSONPath selector syntax. With the patch command, you can precisely target changes to any part of a configuration, without needing the entire file.
deck file merge [flags] filename [...filename] (documentation)
merge brings multiple decK files into one. Top-level arrays are merged by concatenating them and all other keys are copied. In a federated management scenario, merge is a useful stage prior to synchronization to a gateway. If you are building a complex application or an API platform for multiple teams, you will likely have multiple services and code repositories which may have their own decK configuration files. Using CI/CD pipelines, merge can help you bring the configurations together to deploy on shared gateway infrastructure.
deck file add-tags [flags] tag [...tag](documentation)
deck file remove-tags [flags] tag [...tag] (documentation)
Tags are important metadata for your Kong Gateway entities, and we’ve made managing them in your configurations a breeze. Use these transformations to add or remove tags from entities based on a JSONPath selector.
deck file add-plugins [flags] [...plugin-files] (documentation)
Plugins are a critical part of any Kong Gateway deployment, and managing them is an essential task. The add-plugins command is handy for adding plugins to objects that match a given selector or to the global top-level plugins array.
OpenAPI to Kong Generation
OpenAPI is the de facto standard for defining API behavior. Kong has provided the ability to generate declarative configuration from OpenAPI specifications in Insomnia, an open source API development platform since 2021. To better align with operating Kong Gateways, we are moving this functionality into decK. This allows gateway operators to use a single tool for the entire API deployment workflow.
As a result, in this release, we've added a command to generate a Kong Gateway declarative configuration from a provided OpenAPI Specification (OAS) file.
deck file openapi2kong [flags] (documentation)
The openapi2kong command is used to convert an OAS file to a Kong declarative configuration. Typically this would be the first step in a larger pipeline of delivering an API to the gateway. The documentation provides more details on the command usage and examples.
Pipelines
Now that we've seen the new commands added to decK, how can you use them to improve your APIOps capabilities? Using partial configurations and sequences of commands is powerful because they enable organizations to implement a federated approach to API management.
Using common CI/CD tools, you can bring various parts of the configuration together from a single repository, or across many repositories (as is common in a microservices architecture).
Each step of the pipeline is concise and single purpose, but when combined creates a powerful tool for building a full declarative state for your API gateway.
What's next?
We’re thrilled to bring you these latest features, all designed to streamline APIOps workflows.
The full documentation provides the command reference and a user guide. Your feedback has been instrumental in helping us build these new capabilities, and we can’t wait to see how you’ll use them to manage your Kong configurations with greater ease and efficiency.
To provide feedback, please file an issue in the source code repository or contact your Kong representative.
The easiest way to get started with Kong Gateway is with Kong Konnect. Try these new decK features with your Konnect free trial today!