... | @@ -599,20 +599,8 @@ The architecture would look something like this: |
... | @@ -599,20 +599,8 @@ The architecture would look something like this: |
|
![Static system redesign architecture diagram](static-component/architecture-gitlab-pages.png
|
|
![Static system redesign architecture diagram](static-component/architecture-gitlab-pages.png
|
|
)
|
|
)
|
|
|
|
|
|
GitLab pages is designed to scale horizontally: multiple pages servers
|
|
Details of the GitLab pages design and installation is available [in
|
|
can be deployed and fetch their content and configuration through NFS.
|
|
our GitLab documentation](howto/gitlab#gitlab-pages).
|
|
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:
|
|
Concerns about this approach:
|
|
|
|
|
... | | ... | |