Geo: Support GitLab Pages
gitlab-com/migration#29 (closed) is tracking how GitLab Pages can be migrated smoothly to GCP.
For Geo, we may want to consider separate question: What more needs to be done to support GitLab Pages on the secondary?
I believe Pages works as the following:
- User sets up domain information in the project settings
- This update to the domain kicks off an update to the GitLab Pages domain manifest file
- User pushes to a GitLab Pages project
- This kicks off a CI build
- This build kicks off a Sidekiq worker that extracts the archive to a directory
- The GitLab Pages daemon is responsible for reading a manifest file and serving out domains
The secondary doesn't hook into the changes, so it never sees step 2 and will never update the domain manifest file.
Other than that, is there anything else that prevents the secondary from mirroring the primary GitLab Pages instance?
Other things that have to be addressed:
- Making GitLab Pages work with hashed storage
- Destroying a project on the secondary does not clean up the GitLab Pages
Geo product discovery conclusion
I've opened a number of issues for Geo to support Pages. Here is the plan so far, in rough order:
- Always keep a copy of the currently-deployed version of a Pages site gitlab-org/gitlab-ce#45888 Weight: 3
- Geo: Support GitLab Pages access control on secondaries gitlab-org/gitlab-ee#9336 Weight: 5
- Geo: Replicate new GitLab Pages deploys on secondaries gitlab-org/gitlab-ee#9337 Weight: 5
- Geo: Handle rename/move/delete of Pages gitlab-org/gitlab-ee#9347
- Geo: Ensure GitLab Pages works after failover gitlab-org/gitlab-ee#9339 Weight: 3
- Recreate GitLab Pages deployment artifacts that were removed on deploy gitlab-org/gitlab-ee#9346 Weight: 5
- Geo: Backfill GitLab Pages on secondaries gitlab-org/gitlab-ee#9341 Weight: 10
All of this is open for discussion.