GitLab Pages config update

mentioned in merge request !196 (closed)

Hi @john.p.potter if you read the upstream documentation, a custom domain and SAN certificate is required for pages https://docs.gitlab.com/ee/administration/pages/index.html#prerequisites

We will not be straying away from the current configuration to match upstream recommendations.

I'm not sure you are reading that document correctly. There are two ways to run Gitlab pages, one with a user-specific custom domain and one with the default pages custom domain.

The current configuration of this Gitlab helm chart forces the user to use option #1. This merge request would let that instead be configurable as it is in the upstream Gitlab helm chart. This MR simply makes it so the BigBang virtual service can support both modes of operation.

Do you have any examples or more information of what you are trying to do? We deployed a PoC using this setup several months ago following the upstream guides so more information on why suddenly this is not working would be helpful.

Their guides and existing deployments also state that pages-custom-domains runs on container port 80 which is why the virtualservice is configured as such.

From that page you linked earlier, https://docs.gitlab.com/ee/administration/pages/index.html#configuration there are a few ways to configure GitLab Pages. The most basic way is with wildcard domains, which is what we're trying to enable with this MR. The BB charts force you into using custom domains, which, if also using TLS requires the customers or admins to get their own certificates and also additional DNS configuration. With the wildcard domain your Pages site would be https://<namespace>.pages.bigbang.dev/<project_slug> So, a wildcard DNS entry and wildcard cert of *.pages.bigbang.dev will cover all your Pages sites. With Custom Domains, you additionally setup custom domains such as cutomerproject.com and need the additional DNS records and certificates for those custom domains.

Also, the gitlab-pages (not custom-domains one) container uses port 8090, as is also referenced in this network policy https://repo1.dso.mil/big-bang/product/packages/gitlab/-/blob/main/chart/templates/bigbang/networkpolicies/ingress-istio-pages.yaml#L22.

Yep I am tracking all of that, the PoC we used was for a SAN certificate *.pages.bigbang.dev and worked with all of the existing configuration and following their upstream guide. The pages pod listens on 8090 but the service is configured for 80 hence them not matching up, they worked in the PoC months ago and haven't changed since it looks like.

You are correct though this MR does not stray away from the default so we will get it merged in for BigBang 2.10.0 .

Can we get eyes/action on this?

added community-contribution triage-kind triage-priority labels

added kindenhancement priority7 labels and removed triage-kind triage-priority labels

set weight to 0

Is there a specific way for us to fork this such that the pipelines will run on your runners? Or do we need to add one for this?

@ryan.j.garcia @ortiz.jacob @ryan.thompson.44 Could one you possibly add the labels to the MR !196 (closed) for test-ciinfra, the gitlab package, and maybe test-cirelease? If I understand the explanation correctly in the MR?

Thank you