Uploaded image for project: 'Jenkins Website'
  1. Jenkins Website
  2. WEBSITE-38

Evaluate static versus dynamic hosting

    Details

    • Similar Issues:

      Description

      Regardless of the site generation criteria (see also WEBSITE-35) there's a currently unanswered question of whether we should statically host the site or not.

      Static hosting would be publishing to github pages, for example.

      Whereas dynamic hosting would be putting the static site behind nginx, allowing other applications to be hosted in the same URL space (e.g. /account/)

        Attachments

          Issue Links

            Activity

            Hide
            gusreiber gus reiber added a comment -

            I actually think this is a fairly major issue if the plugin site is going to progress.
            The good news is that it should be trivial to deliver.

            Minor in effort, but fairly major in need.

            Show
            gusreiber gus reiber added a comment - I actually think this is a fairly major issue if the plugin site is going to progress. The good news is that it should be trivial to deliver. Minor in effort, but fairly major in need.
            Hide
            orrc Christopher Orr added a comment -

            I really like using nginx, hosting static files, while also having the flexibility to easily add redirects and rewrite rules, reverse proxy to other apps (and fall back in various ways if that fails), have control over caching, redirect based on browser language, send different image formats based on browser capabilities, etc etc..

            Hosting statically would likely be easier for deployment (e.g. essentially zero-effort with GitHub Pages), but with the jenkins-ci.org domain pointing there, it would be less flexible and would require apps (like /account) moving to subdomains. For which we have to run a web server anyway.

            There are also loads of redirects and permalinks on jenkins-ci.org, which would be a bit more annoying to implement purely with a static site.
            With a static provider like GitHub Pages, you would (likely) also lose to access logs for the main site.

            Show
            orrc Christopher Orr added a comment - I really like using nginx, hosting static files, while also having the flexibility to easily add redirects and rewrite rules, reverse proxy to other apps (and fall back in various ways if that fails), have control over caching, redirect based on browser language, send different image formats based on browser capabilities, etc etc.. Hosting statically would likely be easier for deployment (e.g. essentially zero-effort with GitHub Pages), but with the jenkins-ci.org domain pointing there, it would be less flexible and would require apps (like /account) moving to subdomains. For which we have to run a web server anyway. There are also loads of redirects and permalinks on jenkins-ci.org, which would be a bit more annoying to implement purely with a static site. With a static provider like GitHub Pages, you would (likely) also lose to access logs for the main site.
            Hide
            rtyler R. Tyler Croy added a comment -

            Christopher Orr the downside to hosting dynamically is a loss of redundancy and we've had a bad track record in the past of putting bespoke .htaccess files and other static files on the www hosts.

            That's of course not an inherent problem with hosting it "ourselves", just from our current setup it's clear to me that the easy road "edit files on host" can and may be abused (not naming names <_<)

            THAT SAID, I don't think that there's any reasonable alternative, the benefits of dynamic hosting are far too great. But I'll take it as a requirement to make sure that we're hosted from two app hosts instead of just one, and that will hopefully force all infrastructure type changes to go into puppet and be prioperly disciplined

            Show
            rtyler R. Tyler Croy added a comment - Christopher Orr the downside to hosting dynamically is a loss of redundancy and we've had a bad track record in the past of putting bespoke .htaccess files and other static files on the www hosts. That's of course not an inherent problem with hosting it "ourselves", just from our current setup it's clear to me that the easy road "edit files on host" can and may be abused (not naming names <_<) THAT SAID, I don't think that there's any reasonable alternative, the benefits of dynamic hosting are far too great. But I'll take it as a requirement to make sure that we're hosted from two app hosts instead of just one, and that will hopefully force all infrastructure type changes to go into puppet and be prioperly disciplined
            Hide
            orrc Christopher Orr added a comment -

            Fewer .htaccess files, no more hand-editing, and properly using the infra setup sounds good to me.

            I seem to recall that the Fastly offer also applied to the website? Or at least they do something very similar already (acting as CDN for artifact downloads, plus the main website) for some Python project. So perhaps that could make things a bit easier than setting up two servers?

            Show
            orrc Christopher Orr added a comment - Fewer .htaccess files, no more hand-editing, and properly using the infra setup sounds good to me. I seem to recall that the Fastly offer also applied to the website? Or at least they do something very similar already (acting as CDN for artifact downloads, plus the main website) for some Python project. So perhaps that could make things a bit easier than setting up two servers?
            Hide
            rtyler R. Tyler Croy added a comment -

            I seem to recall that the Fastly offer also applied to the website? Or at least they do something very similar already (acting as CDN for artifact downloads, plus the main website) for some Python project. So perhaps that could make things a bit easier than setting up two servers?

            Christopher Orr, the problem with using Fastly to serve up the site is that goes more in the "static hosting" direction, which limits our flexibility as far as what we can host under the primary "jenkins.io/*" URL space.

            I'm fairly convinced right now that a "dynamic hosting" solution right now is going to be a little bit extra work and coordination, but the correct choice long-term as it enables us the most amount of flexibility. Most of my earlier concerns were due to shitty implementation, mostly on my part, than an inherent disconnect.

            Show
            rtyler R. Tyler Croy added a comment - I seem to recall that the Fastly offer also applied to the website? Or at least they do something very similar already (acting as CDN for artifact downloads, plus the main website) for some Python project. So perhaps that could make things a bit easier than setting up two servers? Christopher Orr , the problem with using Fastly to serve up the site is that goes more in the "static hosting" direction, which limits our flexibility as far as what we can host under the primary "jenkins.io/*" URL space. I'm fairly convinced right now that a "dynamic hosting" solution right now is going to be a little bit extra work and coordination, but the correct choice long-term as it enables us the most amount of flexibility. Most of my earlier concerns were due to shitty implementation, mostly on my part, than an inherent disconnect.
            Hide
            orrc Christopher Orr added a comment -

            I don't know for sure, but I'd be surprised if Fastly didn't have an option to let them only serve certain URLs or subdirectories. i.e. I wasn't suggesting going the static route, but rather trying to alleviate the "loss of redundancy" worry you mentioned.

            I'm definitely think the dynamic hosting solution is the best — but if we can additionally get the benefits of a CDN for the vast majority of the site, then that's also great (not that we have to do so, or have to do so now).

            Show
            orrc Christopher Orr added a comment - I don't know for sure, but I'd be surprised if Fastly didn't have an option to let them only serve certain URLs or subdirectories. i.e. I wasn't suggesting going the static route, but rather trying to alleviate the "loss of redundancy" worry you mentioned. I'm definitely think the dynamic hosting solution is the best — but if we can additionally get the benefits of a CDN for the vast majority of the site, then that's also great (not that we have to do so, or have to do so now ).

              People

              • Assignee:
                rtyler R. Tyler Croy
                Reporter:
                rtyler R. Tyler Croy
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: