FutureFoswikiDeploymentScenarios

The FutureFoswiki (FuFo) Deployment Scenarios

What will be the recommended and supported Foswiki deployment scenario in the FutureFoswiki?

Even the main point of the PSGI spec is allowing easy and platform-independent deployment, here are many different methods, backends, integration places, etc. - e.g. many different things should/could be done in different scenarios.

Think about as the current Foswiki:

• currently it is possible to deploy Foswiki using nginx or lighttpd (or any other webserver even PSGI based Starman)
• but our recommended and the supported method is the Apache based deployment

We probably hasn't capacity support all the possible PSGI-deployment scenarios, so the above question is important - how to choose one (or few) "recommended" deployment scenarios.

My point of view:

• Foswiki should use perl based web & psgi server (refer the Development.QuoVadisPsgiFoswiki to remind the difference between the web server and the psgi server)
• preferably CPAN:Starman (we will not support event-loop based servers - needs different way of "thinking")
• because of the organization could use many other web-applications, different environments - (php, java etc..),
  • using the CPAN:Starman isn't the best as an primary web server (which is listening on the "main" ports 80/443).
  • Therefore, i recommending to use the "reverse-proxy" deployment scenario - scheme:

In this scenario:

• the reverse-proxy is typically Apache or nginx
• it
  • listening on the port 80 and 443
  • serves static files (do not need bother perl with simple file-serving)
  • does the CPU intensive ssl-offloading
  • easy to configure - mostly enough few lines to apache or nginx config
  • the reverse-proxy web server runs as root (because of low ports), but it is needed to configure only once
• the backend server (e.g. CPAN:Starman) will
  • runs on high port e.g. 8080 (accessible only from localhost), or could run even on different machine
  • runs under UID of an ordinary user
  • must use the $Foswiki::cfg{ForceDefaultUrlHost}
  • easy develpment
  • easy backend restarts (do not need root rights)

The overhead of the request forwarding from the main server e.g. nginx to the backend server is only few microseconds.

Finally, if the default deployment scenario in the FuFo will be reverse-proxy based, we should start to use it in the current Foswiki too.

We could catch possible problems in advance and could simplify the current configuration problems. (as the most asked support question in the IRC). Thats mean:

• use on the main (port: 80/443) apache or nginx as in reverse proxy role only - simpler config
• use lighttpd as the backend server (for the current Foswiki - later in the PSGI this will be replaced with the CPAN:Starman)
• we could simplify (or probably fully eliminate) the "ApacheConfigGenerator"

For the nginx the config is simple as:

        #foswiki
        location /bin/ {
                proxy_set_header        X-Real-IP       $remote_addr;
                proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_pass http://localhost:8080/bin/;
        }

or simplified config for the Apache:

<VirtualHost *:80>
        ServerName foswiki.examlpe.com
        ProxyPass /bin/ http://localhost:8080/bin/ keepalive=On
        ProxyPassReverse /bin/ http://localhost:8080/bin/
</VirtualHost>

The lighttpd is really fast! It will not create any bottleneck, nor will not lower the RPS (requests per seconds).

Changing the current foswiki deployment to reverse-proxy based one, we:

• will start catchup the possible problems
• create an common base for the deployment for the current foswiki and for the future PSGI based Foswiki (both will be reverse proxy based)
• increased security (the foswiki's server isn't directly accessible from the network)
• increased variability and intergration possibilities (the Foswiki could run even on any other machine)
• simplified maintenance - running the lighttpd based Foswiki is much simpler. (it is always configured to run like as http://localhost:8080 )

Questions:

• What do you think?
• How do you looking to the FuFo deployment scenarios?
• Other ideas?

-- Main.JozefMojzis - 15 Mar 2016 - 16:51

Above scenario is almost identical to the one when using fastcgi today. Only difference is that the frontend web server is talking fastcgi-ish to the backend, not http as is the case with a proxy_pass. This is the the deployment I'd recommend today: nginx + fastcgi. Apache is okay too but needs more resources, not as fast as nginx, not as easy to maintain, imho. Apache + mod_perl, that is: bake Foswiki right into the web server process, is not an option for a couple of reasons, i.e. doesn't scale. The main reason to decouple a frontend web-server from the backend application server (fastcgi, psgi, ...) is horizontal scalability and robustness. Other factors to keep in mind are:

• kerberos (or other single sign on mechanisms)
• webdav
• caching (move foswiki's page cache towards the web-server front while still controlling it)
• delivery of large files (streaming, non-streaming)

Kerberos and webdav fit well into above deployment scenarios and don't require apache anymore.

Viewfile does not work out for large file delivery. Xsendfile is better by establishing an authentication protocol between web-server and app server (needs manual module compilation in apache, nginx and lighttpd have it built-in).

Varnish (or similar?) is an interesting option given Foswiki's dependency tracker would be able to talk to it.

-- MichaelDaum - 15 Mar 2016

Commenting is disabled while not logged in