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:
about.gitlab.comand write a script that would dynamically reconfigure the proxy
go run) or serverless (GCP cloud function or knative)
Regardless of which direction we decide to go, the solution needs to be tested in a staging environment. Thus the need to create
The current configuration of
about.gitlab.com is described here
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.
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.
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
implement using Ruby. There are already scripts written in Ruby in
www-gitlab-com repo in the
functionally the same as Ruby
CI job in a Golang docker container, use
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.
www-gitlab-com/data/redirects.yml, start with the following content and use this format:
- sources: /some-old-path/ target: /some-new-path/ - sources: - /another-old-path/ - /another-old-path-as-well/ target: /some-other-new-path/
about-gitlab-com.jsonand apply it
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
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: