How to import configuration into kong cluster using deck

1

I can see deck dump that dumps all the configurations in the yaml file, but I dont see any deck import. Can you please guide me how to use deck to import configurations into kong with preserving what is already deployed in the kong cluster.

2

You can use deck diff and deck sync commands to import the configuration into Kong.
These commands will tell you the difference in the state of the configuration between the database and the config file and apply those changes.

3

Thanks for replying. I noticed that when I did deck diff it said that it will delete the existing configuration in the db and create all the configuration in the yaml file. I don’t want this behaviour. What I need is to leave alone what is in the db and only add new configuration from the yaml file. Is this behaviour possible? It appears deck will delete everything that is present in the db and then recreate all configurations from the yaml file. Please confirm

4

You have two options:

  • You can use deck dump to export what is present in the DB.
    Then add your new configuration in the newly generated config file. Then deck diff will only add the new configuration without deleting the existing one.
  • If you are using Kong 1.1 or later, you can use select_tags functionality, which will leave all the existing configuration as is and only create the configuration you specify via the YAML file.
5

Thank you Harry appreciate it. we are enterprise 0.35-1 customer, does both options are available to us?

6

The second option will be available to you in Kong Enterprise 0.36.

Since you are an Enterprise customer, you have another option:

You can use workspaces. You can leave the existing configuration in the default workspace.
You can then create a new workspace and then point decK to use the new workspace. decK will then manage configuration for the specific workspace only.

7

so you are suggesting rather than doing diff between db and yaml file, just create a new workspace and then import the new configuration in the new workspace. so for example we create a workspace1 then we import the configuration file in ws1 this way we keep creating new workspaces and import the configurations in that

8

by the way I followed first option which is diff first and I saw following

creating service bbbb
creating service xxxx
creating service rrrr
creating route PolicyServiceRoutes
creating route rrrr
creating route rrrrrr
creating plugin rate-limiting-advanced on service fffff
creating plugin rate-limiting-advanced on service 3333
creating plugin rate-limiting-advanced on service 55555
deleting plugin rate-limiting-advanced on service zaaaaaa
deleting route ccc
deleting route 4444-service-route
deleting service xxxxxx
deleting service rrrrr

Then when I did deck sync, it deleted everything I had in the db and recreated everything from the yaml file. This is not what I wanted I just wanted it to update incrementally not remove existing stuff. Not good at all

9

Not sure what you are doing here but this is what works:

deck dump 
# this creates a kong.yaml file with all your DB configuration in it

# edit the file to add your service and route and whatever else you need

deck diff
# this will show only the entities you are creating

deck sync
# this will actually apply the diff
10

Thanks, I did the following

deck dump

I did this in a lower environment and created kong.yaml

Then I copied the above generated yaml file to the uat environment

deck diff

This showed that it was creating everything coming over from dev environment and deleting everything in the new uat environment

deck sync

It created all the services that came in the kong.yaml from dev but deleting everything that was present in the db

11

That sounds right.

One obvious thing that I forgot to mention is that apply it against the same database.

If you want to combine the configuration of two different envs, then dump those configurations, merge them and then apply.

Your YAML file is the source of truth.
Whatever the configuration of Kong should look like, should be present in the YAML file.

12

ah that explains the behavior :slight_smile: . Since in my case yaml file came from dev environment it became the source of truth compared to the db in the uat environment. This, when I did the sync it basically deleted what was in the db and created everything in the yaml file. so like you said dump from each environment need to be merged , resolved and then synced in the target environment otherwise there could be an issue. Can we document this so no one else has a problem :slight_smile:

13

This should be obvious but if it not, I’d welcome a PR welcome!

15

Is this documented ? If yes, please share the link