Rethinking fedora websites deployment
Hi everyone!
The Websites & Apps team is currently working on rewriting all major Fedora websites
(such as getfedora, spins & alt) and I believe this is a good opportunity to revisit
the current deployment workflow and try to make it simpler.
Currently, websites are being built in Openshift, with a cronjob running every hour that
fetches code from git, builds it, then saves it to an NFS share.
That same NFS share is also mounted on sundries01, which exposes it through rsync for
proxies to sync it, then serve it to the world.
I have a few solutions in mind to replace that, and I would like your input on them.
A) Full Openshift
We can build, and deploy the websites directly in Openshift, and serve it from here.
Just like silverblue.fp-o.
While this is probably the most straightforward solution, it has one major downside:
if Openshift is unavailable for any reason, our major websites become also unavailable.
I believe this is why we are still using our proxies to host them, as such a scenario
is unlikely to happen on every single one of them at the same time.
B) Same as before, with a twist
We build on Openshift, but instead of going through NFS and sundries with rsync, we
store the websites on S3 storage provided by Openshift, then we sync the proxies using
`s3cmd sync`.
C) Same as B, but with an external builder
We already build the new websites on Gitlab CI, and since the S3 gateway is accessible
from the outside, we could just push the build artifacts to s3 directly from GitLab CI.
Then sync the proxies from it.
D) Keep using the Openshift->Sundries->proxies workflow
E) Your solution here.
We could also improve B and C by adding fedora-messaging to the mix to trigger a proxy
resync as soon as a new build is available instead of doing so every hour.
What do you all think?
-darknao