Are you looking to only manage plugin config/enable? And/or,
Add plugins that aren’t natively with a Kong deployment?
If just the first item, we use some basic scripts & curl to manage configuration in what call “bootstrap”. This is separate than plugins we use for API policies. Those are managed through the admin api proxy endpoint. That process is handled in our CI/CD process and leveraged changes triggered from our source code management system.
we are trying to implement CI/CD process for the KONG?
Can you please let us know how this is been done? We have something like DEV, QA, LIVE environment. In most of our use cases the downstream URL’s and Consumer credentials varies between all these environment.
We use a different sub-domain for our gateway cluster in each env and then use the same policy details (with exceptions like OAuth client/secrets, where they apply).
For the credentials piece, we built a platform services portal that allows people to generate JSON files leveraging some similar principles and approaches as eJSON (https://github.com/Shopify/ejson). This allows us to publish the full policy in source code. The gateways have the upstream private key. We’re not 100% automated as we’re still executing some local scripts to manage the final deployment. Our API platform team is two people
The repo setup includes an individual repo for the policy. Design and API code are kept separate. This allows developers to build new images (for their API code) and deploy. The policy repo contains a JSON file for each policy resource type (key-auth, policy, oauth, etc.). There’s a secrets JSON file that has a prefix for the env key (like, prod_, stage_ and dev_ - as a prefix to the key authentication_client_id). We then use a basic template in the JSON files to interpolate values based on the target (using some conditionals and mapping - if KONG_ENV=PROD then go_get_prod_values … you know, deep machine learning stuff)