このページは、まだ日本語ではご利用いただけません。翻訳中です。
旧バージョンのドキュメントを参照しています。 最新のドキュメントはこちらをご参照ください。
CI-driven Configuration
Configuration as code
decK can be, or rather should be, used in a CI pipeline to push out configuration Kong.
It is advisable to store configuration of Kong in a Git repository (or any other Version Control System, or VCS) and then perform GitOps on Kong’s configuration:
- Any time a change needs to be performed, ask the developer to open a
Pull or Merge Request, which can be reviewed by other humans.
You should use
deck validate
anddeck diff
commands in the CI to validate and see if the target changes will be performed or not. Although unlikely, it is possible that adeck sync
command might fail even if the above two pass. If this happens, a human has to intervene and resolve the conflict or error manually. - Once the configuration change is merged in, the CI should execute
deck diff
again (to have a log of what is changing), followed bydeck sync
.
You should also have a cronjob
in your CI or any other system, which verifies
if the source of truth, meaning Kong’s database is in the exact same state as
you want it to be (the state file in VCS repository).
Unless you do this step, you do not have a truly declarative configuration
as your are configure Kong but are never verifying. The system could be
out of sync and can go undetected until another change is performed.
Any time you use decK within an automated environment, including a
deck ping
command in the beginning of your script can ease debugging
in the future, as it usually rules out connectivity issues between decK and Kong.