dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

On Mon, Mar 25, 2013 at 3:16 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:

> Hi Lars (and any other nginx gurus out there)
>
> I have generally favoured apache2 in the past but I am working on a
> standardized install deb so it makes sense to do this with nginx.  So
> you can welcome me into the nginx fold :-)
>
> Our user manual currently describes the case of a single dhis instance
> proxied behind an nginx frontend.  I am looking for an opinion on the
> best way to go about this for the very common scenario of multiple
> dhis instances being proxied behind a single nginx server.   Setting
> up proxy caching is not a problem, though users should be made aware
> that the normal application security is being bypassed for these
> cached resources (reports, charts etc).  What I am a bit puzzled about
> is the best way to set about serving static content.
>
> Take the following, where there are 2 locations being proxied:
>
>  location /dhims {
>       proxy_pass        http://localhost:8080;
>       proxy_redirect    off;
>       proxy_set_header  Host               $host;
>       proxy_set_header  X-Real-IP          $remote_addr;
>       proxy_set_header  X-Forwarded-For    $proxy_add_x_forwarded_for;
>       proxy_set_header  X-Forwarded-Proto  https;
>       proxy_cache dhis;  }
>
> location /training {
>       proxy_pass        http://localhost:8081;
>       proxy_redirect    off;
>       proxy_set_header  Host               $host;
>       proxy_set_header  X-Real-IP          $remote_addr;
>       proxy_set_header  X-Forwarded-For    $proxy_add_x_forwarded_for;
>       proxy_set_header  X-Forwarded-Proto  https;
>       proxy_cache dhis;  }
>
> I can't in this case just set up a simple document root for the static
> requests because I have two webapps.
>
> I guess serving static documents directly is out of the question
> anyway in some cases, eg Rwanda, where the tomcat backends are not all
> necessarily on the same filesystem as the reverse proxy.
>
> In most cases I can think of where there are multiple tomcat
> instances, there is usually one main production instance and others
> are used for training, demo, staging etc.  Approaches I am
> considering:
> 1.  One approach would be to just optimize for the production server.
> 2.  Another would be to setup a document root and symlink the
> different webapps as virtual directories below that (potentially
> complicated).
> 3.  Create multiple location blocks, one for the static content of
> each backend (at least the ones on the same filesystem)
> 4.  Try and treat serving static files as just a special case of caching.
>
> The last option seems the most attractive to me (zero config) if we
> are going to enable caching anyway.  But how can it be made work?  On
> apache2 with the mod_cache module I think this would happen out of the
> box ie. apache will default to cache all cacheable content which would
> include the js, css etc.
>
> I wonder is anything required to be done at all with nginx.  Will test
> and see.  I puzzle I foresee is how to get the "Cache-Control: public"
> headers onto these static responses so the browsers can cache them
> over ssl.  Is this something we should be addressing at the level of
> struts interceptors rather than getting the reverse proxy to add
> headers?
>

Hi Bob,

thanks for bringing this up.

Personally I have been using your alternative 3) when having multiple
instances. It works well and is easy to set up. I see your point about
different proxy/container servers, and I agree it might be a bit more
elegant to let the nginx cache handle static files. I think it should be a
matter of setting up a location block matching static content with
directives something like

add_header  Cache-Control  public;
expires 7d;
proxy_cache dhis;
proxy_pass localhost:8080;

We could add these headers in DHIS as well - potentially with a system
setting ("cache strategy for static content") to cater for special
requirements.

I guess one just have to test it..

regards,

Lars