How to Manage a DB Less Kong instance.

[jeremyjpj0916]

Are there any OSS approaches to manage the yaml config of a Kong DB-LESS instance. Parse and revise the yaml appropriately?

I was looking at deck but it uses Kongs admin API. What if we just want a way to comprehend whats in a flat yaml and make Kong resource revisions accordingly via config file manipulations and writing it out. Thinking like a git ops revision history model maybe that reads/parses, evaluates, and writes to the yaml for changes. Thoughts?

I suppose the reading could also be done via the admin api for getting the resources, but still need something to make the changes yaml file side... may as well parse the yaml directly imo and also avoid admin API bugs if there were any by using config source yaml directly. Although a good monitoring tool might check what the admin API says is there vs the config periodically and ensure Kong isn't dropping resources in its config.

Also hot reloads that are not impactful for the gateway? Only way via the admin api endpoint /config? Or can the file be replaced on the node and a kong reload be called without breaking existing traffic? Trying to figure out how to architect around db-less treading properly. We will probably one of your biggest users first trying db-less at scale haha.

Best,
-Jeremy

[dndx]

Hello @jeremyjpj0916,

Flat Admin API on YAML files are not reliable as things like decK relies on Kong's Admin API and schema to perform validations of fields. Without the Admin API it can not determine if a config is actually valid or not easily.

What about running a single node Kong instance with Postgres backend and use decK (or kong db_export) for exporting the declarative config from that special instance? Then you can easily push those changes out to individual DB-less Kong nodes.

As of Gitops concerns, declarative config can be stored inside git repos easily and diffed easily as they are plain text files.

There is also Hybrid mode which does most of those work for you automatically.

I guess to summarize, there isn't a solution that does all of those at once, but it should be possible to piece together different tools to achieve some kind of "DB-less" workflow.

[jeremyjpj0916]

Makes sense. I prefer a direct solution to parse and load in the new yaml though. We are experimenting w writing to S3 and storing/pulling from there.