containers
containers copied to clipboard
[bitnami/apisix] Use Apisix-Base build for the default Apisix image
Name and Version
bitnami/apisix:4.3.1
What is the problem this feature will solve?
Allow the usage of plugins that are included with the Apisix-Base version.
What is the feature you are proposing to solve the problem?
When using a plugin that is not included by default gzip
for instance the DataPlane displays the error need to build APISIX-Base to support setting gzip while reading response header from upstream
.
What alternatives have you considered?
No response
@Javirln Is this possible with the current state of Apisix base modules?
@andresbono Is there a way to help in this I am not familiar on how the stack smith prepares the packages for the docker images. Let me know if I can make this task easier 🙏
Hi, thank you for filling this issue! We have created an internal ticket to evaluate your feature request, it seems an interesting addition. If everything looks good, and we can release the container image with APISIX + APISIX-Base we will ask you for feedback.
In the meantime, can you think of any drawbacks of building APISIX with APISIX-Base instead of the regular OpenResty? Is there any current feature that would be lost if we switch to APISIX-Base?
Thank you for your collaboration!!
Hello @andresbono Thanks a lot for dedicating the time to this request 🙏
As far as I can find (in the docs, GitHub repo of APISIX, and its related repos) there would not be any missing feature from the APISIX-Base build compared to the regular OpenResty build.
On the contrary, there are quite a number of Plugins that can be used when using APISIX-Base below is what should (AFAIK) some useful plugins that require this build:
- real-ip: customize how/from where to get the client real IP
- gzip: enable/disable gzip of the proxied traffic at APISIX level
- proxy-cache: allows you enable/disable proxy buffering
-
client-control: allows you to override the
max_body_size
dynamically - prometheus: useful if you work with Prometheus to expose some metrics
An alternative solution would be to build two images apisix
and apisix-base
(not sure of the overhead, besides needing to maintain 1 more docker image of APISIX) this will give the liberty to the user to choose what version of APISIX to deploy. For the Helm chart, the regular APISIX build can be kept as the default docker image.
Let me know how can I help/off-load some of the work on my side if needed 🙏
Any updates?
I'm interested in this too! A lot of useful features are missing in the standard build as already mentioned so providing APISIX built on top of APISIX-Base would be beneficial or at least, steps on how to do so.