Separate Ingress support for gitlab vs minio/registry
As noted here: https://gitlab.com/charts/helm.gitlab.io/merge_requests/112#note_58072340
Ideally some of the nginx settings used would be different between gitlab and the registry. In omnibus we already have these differences, things like disabling the cache buffering for registry, and having it's max client body size set to unlimited.
In order to have this level of control, it appears that we should have a seperate Ingress objects for GitLab, and one for Registry. (atm it looks like minio could share the registry's if that is easier, or could have it's own)
In order to support using a upstream nginx chart in the future (https://gitlab.com/charts/helm.gitlab.io/issues/218) we should move all our ingresses out of the NGINX chart when we make this change.
Some comments from the issue:
jplum: I'll have to research if we can set per-path settings, otherwise, we'll indeed have to have separate Ingresses, which would then cause the need for two
loadBalancerIP
s, which complicates things a fair amount.
jplum: It looks like the ConfigMap handles the global behaviors, and Annotations handle per-rule settings, which appear to be tied to the
ingress
resource itself.
jplum: My previous comment in regards to the
loadBalancerIP
may be inaccurate, as that is tied to theservice
/daemonset
, not to theIngress
.
jplum: We certainly could split the Ingress rules between web/bulk/* with some rework, if that is deemed worth time. The complexity will grow, but the fine grained control could be useful in production deployments.
cc\ @WarheadsSE