feat(conf) allow user-specified OpenResty install path #8412
Conversation
locao
added
the
pr/ready (but hold merge)
flrgh
changed the title
|
note: no tests on this pR |
Kong detects and decides which nginx binary to use by searching a couple hard-coded paths: * /usr/local/openresty/nginx/sbin * /opt/openresty/nginx/sbin ...before finally exec-ing out to check PATH for a found nginx executable. Therefore, if OpenResty is installed at one of the hard-coded paths, it is always used, leaving the operator no means of specifying any alternative. In most workflows, this is not a problem at all, but during local development and testing it can be limiting. Changing the behavior to search PATH first is one possible way of addressing this, but it is backwards-incompatible in ways that will likely cause headaches for operators, developers, package maintainers, and CI pipeline owners. Therefore, this development quality-of-life-inspired change introduces a new environment variable (KONG_OPENRESTY_PREFIX) that short-circuits the aforementioned behavior. When this variable is set, Kong uses it exclusively for locating the nginx binary. Using KONG_OPENRESTY_PREFIX instead of something like KONG_NGINX_BIN allows us to expand its usage later on (i.e. potentially having a cascading effect on LUA_PATH/LUA_CPATH).
flrgh
force-pushed
the
feat/cli-custom-resty-prefix
branch
from
c713bfa to
ae7eb69
Compare
|
Test coverage has been added. |
|
@flrgh This is a nice idea, but I would like to point out that Maybe |
This is a fair point, and I'm not married to |
flrgh
changed the title
flrgh
removed
the
pr/ready (but hold merge)
|
yay! nice work there @flrgh! |
Summary
I maintain several different installations of OpenResty (both vanilla and Kong-flavored) on my machine for dev/testing of different projects.
The first time I went to run the Kong test suite locally, I spent a half hour or so scratching my head and cursing the sky over this error:
But I prepended the correct NGINX bin dir to my PATH already--why doesn't it work?!
As I would soon discover, Kong searches some common OpenResty system/default paths before consulting PATH, making it impossible to use a non-standard OpenResty installation for running the Kong cli, busted, etc. if system OpenResty is already installed.
The commit message has some more details, but in short, with this change, operators can use a custom OpenResty install with Kong by setting
openresty_prefixopenresty_path.Why not just update things so that we search PATH first?
This would be a nice improvement, and in my opinion would nicely correct things as to not violate the principle of least surprise. However, that would be a breaking change with potential far-reaching, headache-inducing impact as operators, package maintainers, and CI pipeline owners now suffer through the same debug session that I went through.
Why
openresty_prefixopenresty_path and not nginx_bin?Kong is tightly-coupled to OpenResty than vanilla NGINX, so it "feels" more cohesive this way, to me at least. Also this leaves the door open to expand our usage of this variable. For instance, I think it would be nice if it had a cascading effect on the default values of lua
package.path/package.cpath.Why use
openresty_prefixopenresty_path exclusively instead of inserting it at the head of the search list?Because the operator told us explicitly which path to use, and if it doesn't exist, we should fail fast rather than potentially falling back to another version of OpenResty that happens to exist on the same filesystem.
For discussion:
Is it okay for this to slide in as an undocumented, not-exactly-public-but-not-completely-private/internal feature, or do we need to make it a fully-documented first-class citizen of the conf_loader? IMO the latter would be nice, but I stopped short of that because I think it would need to be more fleshed-out first--potentially incorporating some of the other behaviors I mentioned (re: luaI'm adding it to the Kong config.package.path).