... | ... | @@ -599,24 +599,56 @@ The architecture would look something like this: |
|
|
![Static system redesign architecture diagram](static-component/architecture-gitlab-pages.png
|
|
|
)
|
|
|
|
|
|
GitLab pages is designed to scale horizontally: multiple pages servers
|
|
|
can be deployed and fetch their content and configuration through NFS.
|
|
|
They are [rearchitecturing this with Object storage](https://docs.gitlab.com/ee/architecture/blueprints/cloud_native_gitlab_pages/) (ie. S3
|
|
|
through minio by default, or external existing providers) which might
|
|
|
simplify running this but this actually adds complexity to a
|
|
|
previously fairly simple design. Note that they have tried using
|
|
|
CephFS instead of NFS but that did not work for some reason.
|
|
|
|
|
|
The [new pages architecture](https://docs.gitlab.com/ee/architecture/blueprints/cloud_native_gitlab_pages/) also relies on the GitLab rails API
|
|
|
for configuration (it was a set of JSON files before), which makes it
|
|
|
dependent on the Rails API for availability, although [that part of
|
|
|
the design](https://gitlab.com/groups/gitlab-org/-/epics/4242) has [exponential back-off time](https://gitlab.com/groups/gitlab-org/-/epics/4242) for unavailability
|
|
|
of the rails API, so maybe it would survive a downtime of the rails
|
|
|
API.
|
|
|
|
|
|
Concerns about this approach:
|
|
|
|
|
|
* GitLab pages is a custom webserver which issues TLS certs for the
|
|
|
custom domains and serves the content, it's unclear how reliable or
|
|
|
performant that server is
|
|
|
* The design assumes the existence of a shared filesystem to deploy
|
|
|
content. GitLab.com uses NFS to decouple the pages host from the
|
|
|
main GitLab host, and have tried using CephFS in the past, but
|
|
|
failed. they are [rearchitecturing this with Object storage](https://docs.gitlab.com/ee/architecture/blueprints/cloud_native_gitlab_pages/#gitlab-pages-new-architecture)
|
|
|
(ie. S3 through minio by default, or external existing providers)
|
|
|
* this increases dependency on GitLab for deployments
|
|
|
* The pages design assumes the existence of a shared filesystem to
|
|
|
deploy content, currently NFS, but they are switching to S3 (as
|
|
|
explained above), which introduces significant complexity and moves
|
|
|
away from the classic "everything is a file" approach
|
|
|
* The new design also introduces a dependency on the main GitLab
|
|
|
rails API for availability, which could be a concern, especially
|
|
|
since that is [usually a "non-free" feature](https://about.gitlab.com/pricing/self-managed/feature-comparison/) (e.g. [PostgreSQL
|
|
|
replication and failover](https://docs.gitlab.com/ee/administration/postgresql/replication_and_failover.html), [Database load-balancing](https://docs.gitlab.com/ee/administration/database_load_balancing.html),
|
|
|
[traffic load balancer](https://docs.gitlab.com/ee/administration/reference_architectures/#traffic-load-balancer), [Geo disaster recovery](https://docs.gitlab.com/ee/administration/geo/disaster_recovery/index.html) and,
|
|
|
generally, [all of Geo](https://about.gitlab.com/solutions/geo/) and most [availability components](https://docs.gitlab.com/ee/administration/reference_architectures/#availability-components)
|
|
|
are non-free).
|
|
|
* In general, this increases dependency on GitLab for deployments
|
|
|
|
|
|
Next steps:
|
|
|
|
|
|
1. check if the GitLab Pages subsystem provides atomic updates
|
|
|
2. see how GitLab Pages can be distributed to multiple hosts and how
|
|
|
scalable it actually is or if we'll need to run the cache frontend
|
|
|
in front of it
|
|
|
1. [ ] check if the GitLab Pages subsystem provides atomic updates
|
|
|
2. [x] see how GitLab Pages can be distributed to multiple hosts and
|
|
|
how scalable it actually is or if we'll need to run the cache
|
|
|
frontend in front of it. **update**: it can, but with
|
|
|
significant caveats in terms of complexity, see above
|
|
|
3. [ ] setup GitLab pages to test with small, non-critical websites
|
|
|
(e.g. API documentation, etc)
|
|
|
4. [ ] test the [GitLab pages API-based configuration](https://docs.gitlab.com/ee/administration/pages/#gitlab-api-based-configuration) and see how
|
|
|
it handles outages of the main rails API
|
|
|
5. [ ] test the [object storage system](https://docs.gitlab.com/ee/administration/pages/#using-object-storage) and see if it is usable,
|
|
|
debuggable, highly available and performant enough for our
|
|
|
needs
|
|
|
6. [ ] keep track of upstream development of the GitLab pages
|
|
|
architecture, [see this comment from anarcat](https://gitlab.com/groups/gitlab-org/-/epics/1316#note_496404589) outlining
|
|
|
some of those concerns
|
|
|
|
|
|
### Replacing Jenkins with GitLab CI as a builder
|
|
|
|
... | ... | |