DEPLOY

   1 = Deploying \Rainbows!
   2
   3 == nginx proxying to \Rainbows! or Unicorn
   4
   5 For high-traffic applications, routing slow actions to \Rainbows! with
   6 nginx is recommended as nginx can serve static files faster and nginx
   7 can forward fast actions to Unicorn.
   8
   9           static files
  10             |
  11       nginx |--> slow actions --> Rainbows!
  12             |
  13             `--> fast actions --> Unicorn
  14
  15 Be sure to set <tt>proxy_buffering off</tt> in nginx for "slow actions"
  16 if you have Comet applications (but not for Unicorn).
  17
  18 == \Rainbows! only
  19
  20 For the daring (or low-traffic sites), you should consider deploying
  21 \Rainbows! in a standalone configuration.  This will be more highly
  22 recommended as \Rainbows! stabilizes, especially if static file
  23 performance improves (or you don't need them).
  24
  25 You will need to do this to support things like BOSH or do real-time
  26 processing of the request body as it is being uploaded.
  27
  28 In this case, haproxy or any similar (non-request-body-buffering) load
  29 balancer should be used to balance requests between different machines.
  30
  31 == Denial-of-Service Concerns
  32
  33 Since \Rainbows! is designed to talk to slow clients with long-held
  34 connections, it may be subject to brute force denial-of-service attacks.
  35 In Unicorn and Mongrel, we've already enabled the "httpready" accept
  36 filter for FreeBSD and the TCP_DEFER_ACCEPT option in Linux; but it is
  37 still possible to build clients that work around and fool these
  38 mechanisms.
  39
  40 \Rainbows! itself does not feature any explicit protection against brute
  41 force denial-of-service attacks.  We believe this is best handled by
  42 dedicated firewalls provided by the operating system.