... | ... | @@ -557,22 +557,22 @@ progressively, however. A few ideas: |
|
|
webserver, but it might be possible to bypass that and directly
|
|
|
access the on-disk files provided by the CI.
|
|
|
|
|
|
One concern with using GitLab pages is that it uses a custom webserver
|
|
|
(to get and issue TLS certs for the custom domains).
|
|
|
|
|
|
It also assumes the existence of a shared filesystem to deploy
|
|
|
content. GitLab.com uses NFS to decouple the pages host from the main
|
|
|
GitLab host, maybe we could use CephFS instead? In any case it's a
|
|
|
little clunky and doesn't immediately fulfill the high availability
|
|
|
requirement.
|
|
|
|
|
|
The other downside of this approach is increased dependency on GitLab
|
|
|
for deployments.
|
|
|
The architecture would look something like this:
|
|
|
|
|
|
![Static system redesign architecture diagram](static-component/architecture-gitlab-pages.png
|
|
|
)
|
|
|
|
|
|
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
|
|
|
|
|
|
Next steps:
|
|
|
|
... | ... | |