Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Blueprint: Self service for redirects on about.gitlab.com

On this page

Idea/Problem Statement

The Marketing team needs to be able to configure 301 redirects when paths change on the about.gitlab.com. Until now this was done by creating issues in the infrastructure project and then someone from the infrastructure team had to edit a role in the chef-repo and apply the change. This is manual, slow and laborsome.

A solution to this would be to automate this process, see

approaches that were considered:

Regardless of which direction we decide to go, the solution needs to be tested in a staging environment. Thus the need to create about.staging.gitlab.com

The current configuration of about.gitlab.com is described here

Reverse proxy in front of about.gitlab.com

At the moment there is no reverse proxy in front of about-src.gitlab.com. Traffic from Fastly as well as from the Internet goes directly to nginx.

We would need to set up the proxy and implement something that would reconfigure it dynamically.

ingress controller

This idea is mentioned here for brainstorming, it's here because functionally reconfiguring dynamically proxies is exactly what ingress controller is doing. Using a yml file user defines configuration that is then translated into proxy config and applied instantaneously. It's not relevant since we're not using k8s at the moment.

reconfigure Fastly

This approach is much simpler (no need to configure another service) and faster (301s from the backend are not cached by Fastly). It also doesn't involve expiration of the existing cache (we use ETags with long expiration times so an introduction of a 301 would not be reflected in Fastly without dumping the cache).

see below for the work that would be involved

use Ruby

implement using Ruby. There are already scripts written in Ruby in www-gitlab-com repo in the bin/ directory.

use Golang

functionally the same as Ruby CI job in a Golang docker container, use go run

serverless

the function invocation would have to send the contents of the yml file from the repository to the function. The function itself would have to be managed separately, e.g. using terraform or manually over a WebUI. So there would have to be two runtimes with two sets of credentials: one for triggering the function and another for the execution of it. It's easier to set this up as a CI job - the yml file is already there, there are less moving parts.

what needs to be done

- sources: /some-old-path/ 
  target: /some-new-path/
- sources:
    - /another-old-path/
    - /another-old-path-as-well/
  target: /some-other-new-path/

staging for about.gitlab.com

what needs to be done

FAQ

why not create the VM in GCP?

the purpose of staging is to mirror prod as close as possible, for that reason, if we wanted to deploy staging on GCP we would have to move prod as well. That's not within the scope of this work

why not in k8s?

we are still in the process of formulating our approach for switching to k8s. This change has to happen fast. Once it's deployed and we stop blocking the Marketing team, we can look into moving to k8s. We are not cutting ourselves from switching with this work. The change would be fairly easy, it would be a matter of updating config in Fastly and pointing it to a new backend service

what would have to be done if we wanted to do it in k8s: