[kong] Refactor listener templates #72
Conversation
Unify the listener templates while retaining support for the legacy admin API listen configuration format.
Unify listener templates and make them more expressive: * Listener strings are now generated by passing the listener/service configuration block (e.g. "proxy") to the "kong.listen" helper, rather than templating each listen string individually. * The admin listen now uses the same configuration format as other listeners, with default values expressing the standard configuration (no service creation, TLS-only listen). Legacy configuration is still supported, but displays a deprecation warning in NOTES.txt. * Listener configuration now allows specifying listen parameters, rather than hard-coding them into the template (though "ssl" is still hard-coded for TLS listens). To avoid too complicated a configuration change, users are still limited to two listens, HTTP and TLS, rather than being able to freely define listens. * CI tests and README.md now account for the above. * NOTES.txt spacing now tries to more closely adhere to 80-char columns.
Add a "kong.adminLocalURL" helper to generate the local URL for the admin API, for use with the ingress controller.
|
|
||
| For example, updating to `env.proxy_listen: 0.0.0.0:4444, 0.0.0.0:4443 ssl` | ||
| will need `proxy.http.containerPort: 4444` and `proxy.tls.containerPort: 4443` | ||
| to be set in order for the service definition to work properly. |
There was a problem hiding this comment.
Is override not possible at all? From the current read, it seems it should be possible.
There will be use-cases that will demand override, and for those, we should mention this.
Thoughts?
There was a problem hiding this comment.
What cases are you thinking of in particular? The simplest I can think of (restricting the listen IP) doesn't seem like it'd be of use in containerized deployments.
While it's still possible, I couldn't think of obvious cases for overriding and figured it would be best left unmentioned.
There was a problem hiding this comment.
OSS users can get very creative sometimes.
We don't need a dedicated section but let's mention this in the env section itself maybe?
There was a problem hiding this comment.
They can be, but it's easier to support them if they aren't. I don't want to document this even though it does work, since IMO it shouldn't appear that it's a standard way of configuring things.
If there are cases where the standard listen config doesn't work, I'd want those to come in via issues for us to try and see if there's a way we can support it without overrides.
The admin API configuration could only set up a single port, either HTTP or HTTPS. Kong/charts#72 added support for dual-stack admin API configuraton using the same templates as other Kong services. Fix #287
What this PR does / why we need it:
Consolidates listeners templates into a single generic template. This DRYs helper template code, makes the listener/service configuration consistent, and paves the way towards consolidating Service/Ingress templates in the future.
KONG_<SERVICE>_LISTENvariables.--kong-urlargument into a newkong.adminLocalURLhelper.Special notes for your reviewer:
PR contains un-squashed commits to show dev history, but should be squashed before merger, as most of the details are irrelevant after review. If merging, please use the commit message from 6451e7f with one additional bullet point:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]
nextbranch and targetsnext, notmaster[kong])