decK

If you are using Terraform and are happy with it, you should continue to use it. decK covers all the problems that Terraform solves and goes beyond it:

• With Terraform, you have to track and maintain Terraform files (*.tf) and the Terraform state (likely using a cloud storage solution). With decK, the entire configuration is stored in the YAML/JSON file(s) only. There is no separate state that needs to be tracked.
• decK can export and back up your existing Kong Gateway’s configuration, meaning, you can take an existing Kong Gateway installation, and have a backup, as well as a declarative configuration for it. With Terraform, you will have to import each and every entity in Kong Gateway into Terraform’s state.
• decK can check if a configuration file is valid or not (validate sub-command).
• decK can quickly reset your Kong Gateway’s configuration when needed.
• decK works out of the box with Kong Gateway features like Workspaces and RBAC.

The two processes will step on each other and might corrupt Kong Gateway’s configuration. You should ensure that there is only one instance of decK running at any point in time.

Kong Gateway has an official declarative configuration format. Kong Gateway can generate such a file with the kong config db_export command, which exports most of Kong Gateway’s database into a file.

You can use a file in this format to configure Kong Gateway when it is running in a DB-less or in-memory mode. If you’re using Kong Gateway in DB-less mode, you can’t use decK for any sync, dump, or similar operations, as they require write access to the Admin API.

If you are using Kong Gateway alongside a database, you need decK because:

• Kong Gateway’s kong config db_import command isn’t sufficient in the following situations:
  • The command is used to initialize a Kong Gateway database, but we don’t recommended using it if there are existing Kong Gateway nodes running, as the cache in these nodes won’t be invalidated when entities are changed or added. In that case, you would need to manually restart all existing Kong Gateway nodes. decK performs all the changes via Kong’s Admin API, meaning the changes are always propagated to all nodes.
  • The command can only add and update entities in the database. It won’t remove the entities that are present in the database but aren’t present in the configuration file.
  • The command needs direct access to Kong Gateway’s database, which may not be possible in your production networking environment.
• decK can easily perform detect drifts in configuration. For example, it can verify if the configuration stored inside Kong Gateway’s database and the configuration inside the config file is the same. This feature is designed for integrating decK with a CI system or a cronjob which periodically checks for drifts and alerts a team if needed.
• deck gateway dump outputs a more human-readable configuration file compared to Kong Gateway’s db_import.

However, decK has the following limitations which may affect your use case:

• If you have a very large installation, it can take some time for decK to sync up the configuration to Kong Gateway. This can be mitigated by adopting distributed configuration for your Kong Gateway installation and tweaking the --parallelism value. Kong Gateways db_import` will usually be faster by orders of magnitude.
• decK can’t export and re-import fields that are hashed in the database. This means that fields like the password of the basic-auth credential can’t be correctly re-imported by decK. This happens because Kong Gateway’s Admin API call to sync the configuration will rehash the already hashed password.

decK is designed to be compatible with open-source and enterprise versions of Kong Gateway.

Yes, decK is compatible with Konnect.

Konnect requires decK v1.40.0 or above. Versions below this will see inconsistent deck gateway diff and sync results.

As of Kong Gateway 3.4, you can’t use Cassandra as a data store, as it is no longer supported by Kong Gateway. You can use decK with earlier versions of Kong Gateway backed by Cassandra. However, if you observe errors during a sync process, you will have to tweak decK’s settings and make a few adjustments.

decK heavily parallelizes its operations, which can induce a lot of load onto your Cassandra cluster. You should consider:

• decK is read-intensive for most parts, meaning it will perform read-intensive queries on your Cassandra cluster, so make sure you tune your Cassandra cluster accordingly.
• decK talks to the same Kong Gateway node that talks to the same Cassandra node in your cluster. Use the --parallelism 1 flag to ensure that there is only request being processed at a time. This will slow down sync process and should be used as a last resort.

Yes. The decK team maintains a JSON schema that you can use to validate YAML files on Github. You can use the schema with a text editor to provide JIT YAML validation. For example, to use the JSON schema with VS Code:

1. Install the Red Hat YAML extension:

    code --install-extension redhat.vscode-yaml
   

   Copied to clipboard!

2. Edit the plugin settings in VS Code:

    "yaml.schemas": {
      "https://json.schemastore.org/kong_json_schema.json": [
          "kong.yml",
          "kong.yaml"
      ]
    }
   

   Copied to clipboard!

3. Verify that it works by opening your existing kong.yml or kong.yaml file.