View on GitHub

decK

Declarative configuration for Kong and Kong Enterprise

Design & Architecture

Underlying architecture

Reverse sync

One of the most important features of decK is reverse-sync, whereby decK can detect entities that are present in Kong’s database but are not part of the state file. This feature increases the complexity of the project as the code needs to perform a sync in both directions, from the state file to Kong and from Kong to the state file.

Algorithm

Export and Reset

An export or reset of entities is fairly easy to implement. decK loads all the entities from Kong into memory and then serializes it into a YAML or JSON file. For reset, it instead performs DELETE queries on all the entities.

Diff and Sync

The diff of configuration is performed using the following algorithm:

  1. Read the configuration from Kong and store it in a SQL-like in-memory database.
  2. Read the state file from disk, and match the IDs of entity with their respective counterparts in the in-memory state, if they are present.
  3. Now, for entity of each type we perform the following:
    1. Create: if the entity is not present in Kong, create the entity.
    2. Update: if the entity is present in Kong, check for equality. If not equal, then update it in Kong. These two steps are referred to as “forward sync”.
    3. Delete: Go through each entity in Kong (from the in-memory database), and check if it is present in the state file, if yes, don’t do anything. If no, then delete the entity from Kong’s database as well.

Certain filters like select-tag or Kong Enterprise workspace might be applied to the above algorithm based on the inputs given to decK.

Operational outlook

Based on the above algorithm, one can see how decK can require a large amount of memory and network I/O. While this is true, a few optimizations have been incorporated to ensure good performance:

Choice of language

decK is written in Go because: