apisix
apisix copied to clipboard
feat: I want to specify multi xxx.yaml or a conf dir (like nginx include instruction) for apisix router config, can apisix support this by providing start options
Description
Here, i talk about stand alone mode. we all know apisix.yaml is the only one router config file. can we support multi config file. and when we start apisix, we could specify the router config file.
Since many cases, we keep two config files , one for fixed and will not change, and another used for dynamic changes.
We have discussed this before. Using multiple yaml files in the standalone mode is too complex. It would be easier to solve it in an agent which prepares the yaml file.
In nginx, we can specify a dir to include all .conf file below include vhost/.conf; can we support this also, I guss it's useful in many cases.
@wyaow Could you introduce the backgrounds that why you want such a feature? We do can solve it technically, but we'll be more interested in the cause.
+1, a single standalone apisix instance serves multiple sites, prefer multiple config files or a conf dir
@wyaow Could you introduce the backgrounds that why you want such a feature? We do can solve it technically, but we'll be more interested in the cause.
It's common, to let the business team to maintain their own router config, And we should only add include instruction in apisix.conf.
Indeed, IMHO standalone mode cuts out the flexibility that the default mode carries when managing multiple sources of routes configuration ( multiple teams mantaining multiple CRDs defined routes ) without the need of an external tool. I'm trying to undersand whether i should try to use standalone mode, but managing a single configmap to configure many websites and projects routes doesn't seem a nice way to go . Since i'm not willing to operate the ETCD Cluster that the control plane depends on ( I'm on EKS and can't use the cluster's ETCD, so I have to manage my own ), this would enable scaling the configuration managent on multiple teams scenarios, without the operational overhead of managing the ETCD cluster or other configuration centers ( Consul, etc) and sticking to kubernetes core features, such as configmaps and volumeMounts. Maybe a sidecar reading files from a folder and appending the files, rewriting it on changes should suffice too, right?
This issue has been marked as stale due to 350 days of inactivity. It will be closed in 2 weeks if no further activity occurs. If this issue is still relevant, please simply write any comment. Even if closed, you can still revive the issue at any time or discuss it on the [email protected] list. Thank you for your contributions.
This issue has been closed due to lack of activity. If you think that is incorrect, or the issue requires additional review, you can revive the issue at any time.