Simple deployment of Lift apps on Jetty/Nginx

[David Pollak]

Folks,

I've been deploying a fair number of apps using Jetty and Nginx and been very pleased with the results.  I've put together a package to make it wicked simple for you to do the same.

To run one or more Nginx front-end/Jetty backend, do the following:

• download the Jetty container from http://tunaforcats.com/deploy_jetty.tgz
• tar -xzvf deploy_jetty
• cd deploy_jetty
• echo 9920 > base_port # this defines the base port that Jetty will run at.  Production = base, preview = base + 1, dev = base + 2
• copy your Lift app WAR file to webapps/root.war
• Edit your nginx.conf file and add:
      server {
          listen       80;
          server_name  www.myapp.com myapp.com;
  
          access_log  logs/myapp.access.log main;
  
  
          location / {
              proxy_pass http://127.0.0.1:9920;
           proxy_set_header  X-Real-IP  $remote_addr;
           proxy_read_timeout 700;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          }
      }
  
      server {
          listen       80;
          server_name preview.myapp.com;
  
          access_log  logs/preview_myapp.access.log main;
  
  
          location / {
              proxy_pass http://127.0.0.1:9921;
           proxy_set_header  X-Real-IP  $remote_addr;
           proxy_read_timeout 700;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          }
      }
  
      server {
          listen       80;
          server_name dev.myapp.com;
  
          access_log  logs/dev_myapp.access.log main;
  
  
          location / {
              proxy_pass http://127.0.0.1:9922;
           proxy_set_header  X-Real-IP  $remote_addr;
           proxy_read_timeout 700;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          }
      }
• Reload/restart Nginx
• Start your production Jetty instance: start_prod.sh

You should see very, very good performance with Lift's long polling, even at a high load.

Questions?

Thanks,

David


--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

[Viktor Klang]

Thanks for the how-to Dave!
Looks splendid :)

--
Viktor Klang
Senior Systems Analyst

[Tim Perrett]

Good to see that your using nginx dave... It's a rocking front end.

One thing, what made you use proxy_pass rather than upstream ?

Cheers, Tim

Sent from my iPhone

[David Pollak]

On Tue, Nov 11, 2008 at 1:52 PM, Tim Perrett <he...@timperrett.com> wrote:

Good to see that your using nginx dave... It's a rocking front end.

One thing, what made you use proxy_pass rather than upstream ?

What's upstream?
 

[Tim Perrett]

Upstream let's you specify a bunch of backend servers, say you had 3 nodes running your app in a cluster, upstream can manage and load balence the sending of requests to those backends.

I'm on my iPhone right now, so can't copy and paste a link - check out the code mongers wiki... I'll paste an example when I'm properly online tomorow.

Cheers

Tim

Sent from my iPhone

[David Pollak]

On Tue, Nov 11, 2008 at 1:52 PM, Tim Perrett <he...@timperrett.com> wrote:

Good to see that your using nginx dave... It's a rocking front end.

One thing, what made you use proxy_pass rather than upstream ?

I'm not trying to load-balance.  Upstream seems to be oriented to load balancing, which is not the goal.  Did I miss something?
 

[Tim Perrett]

> I'm not trying to load-balance.  Upstream seems to be oriented to load
> balancing, which is not the goal.  Did I miss something?

Sorry for the late reply - indeed it is for load balancing etc; I was
working on the presumption you might have more than one back-end jetty
- if not then sure, what you have is ideal.

Cheers

Tim

[David Pollak]

On Mon, Jan 4, 2010 at 7:25 PM, Alex Black <al...@alexblack.ca> wrote:

I'm intrigued by the Nginx, could you tell us more about what the
advantages of using Nginx as well as Jetty instead of Jetty?

You can have more than one domain per IP address served by different applications with Nginx up front.  You can swap from one instance of an application to another (semi-seamless upgrades) with Nginx up front.  You can front many different Lift instances (some running on other machines) with Nginx up front (there are some high volume Lift sites that do this).
 

thx

- Alex

On Nov 11 2008, 3:49 pm, "David Pollak"

<feeder.of.the.be...@gmail.com> wrote:
> Folks,
>
> I've been deploying a fair number of apps using Jetty and

> Nginx<http://sysoev.ru/en/>and been very pleased with the results.

> I've put together a package to make
> it wicked simple for you to do the same.
>
> To run one or more Nginx front-end/Jetty backend, do the following:
>

>    - download the Jetty container from
>    http://tunaforcats.com/deploy_jetty.tgz
>    - tar -xzvf deploy_jetty
>    - cd deploy_jetty
>    - echo 9920 > base_port # this defines the base port that Jetty will run

>    at.  Production = base, preview = base + 1, dev = base + 2

>    - copy your Lift app WAR file to webapps/root.war
>    - Edit your nginx.conf file and add:
>        server {
>            listen       80;

>            server_name  www.myapp.commyapp.com;

>
>            access_log  logs/myapp.access.log main;
>
>            location / {

>                proxy_passhttp://127.0.0.1:9920;

>             proxy_set_header  X-Real-IP  $remote_addr;
>             proxy_read_timeout 700;
>             proxy_set_header Host $http_host;
>             proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>            }
>        }
>
>        server {
>            listen       80;
>            server_name preview.myapp.com;
>
>            access_log  logs/preview_myapp.access.log main;
>
>            location / {

>                proxy_passhttp://127.0.0.1:9921;

>             proxy_set_header  X-Real-IP  $remote_addr;
>             proxy_read_timeout 700;
>             proxy_set_header Host $http_host;
>             proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>            }
>        }
>
>        server {
>            listen       80;
>            server_name dev.myapp.com;
>
>            access_log  logs/dev_myapp.access.log main;
>
>            location / {

>                proxy_passhttp://127.0.0.1:9922;

>             proxy_set_header  X-Real-IP  $remote_addr;
>             proxy_read_timeout 700;
>             proxy_set_header Host $http_host;
>             proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>            }
>        }

>    - Reload/restart Nginx
>    - Start your production Jetty instance: start_prod.sh

>
> You should see very, very good performance with Lift's long polling, even at
> a high load.
>
> Questions?
>
> Thanks,
>
> David
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

> Collaborative Task Managementhttp://much4.us

> Follow me:http://twitter.com/dpp
> Git some:http://github.com/dpp

--
Lift, the simply functional web framework http://liftweb.net

Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

[Alex Black]

> You can have more than one domain per IP address served by different
> applications with Nginx up front.  You can swap from one instance of an
> application to another (semi-seamless upgrades) with Nginx up front.  You
> can front many different Lift instances (some running on other machines)
> with Nginx up front (there are some high volume Lift sites that do this).

Thats good to know, thanks!

[Philippe Monnaie]

This may be kind of late to reply, but do you happen to still have
that Jetty container?

The http://tunaforcats.com/deploy_jetty.tgz is currently returning a
404. I'll live without it, but it seems pretty useful and I'm
interested to look at it to see how you got it to work as you
describe.

Thanks!

Philippe

> --
>
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>

[David Pollak]

On Wed, Jul 14, 2010 at 12:51 PM, Philippe Monnaie <Philippe...@gmail.com> wrote:

This may be kind of late to reply, but do you happen to still have
that Jetty container?

The http://tunaforcats.com/deploy_jetty.tgz is currently returning a
404. I'll live without it, but it seems pretty useful and I'm
interested to look at it to see how you got it to work as you
describe.

I think http://github.com/dpp/lift-samples/blob/master/jetty_instance.tgz should work.
 

Blog: http://goodstuff.im
Surf the harmonics

[Anton Andriyevskyy]

1. Is this deployment example ok for multiple Lift applications, each running on its own port?

So I can have /home/myLiftApp/deploy_jetty for each myLiftApp?

2. How to autostart my application on server restart?

Thanks.

[Naftoli Gugenheim]

On Mon, Feb 27, 2012 at 5:19 AM, Anton Andriyevskyy <x.me...@gmail.com> wrote:

2. How to autostart my application on server restart?

I think the easiest way is with Upstart (on Ubuntu anyway).

 

Thanks.

--
Lift, the simply functional web framework: http://liftweb.net

Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

[Anton Andriyevskyy]

Thanks, I'll read about upstart.

[Anton Andriyevskyy]

David, the only difference between standalone binary jetty download and your jetty deployment zip is that you have start/shutdown_*.sh files?

Or there are more benefits and/or customization?

Thanks.

[Naftoli Gugenheim]

As an example, I have the following, using JRockit:

naftoligug@disp:~$ cat /etc/init/lrbcol.conf 

exec start-stop-daemon -c jetty -x /home/naftoligug/jrockit-jdk1.6.0_29-R28.1.5-4.0.1/jre/bin/java -S -- -cp /usr/share/java/commons-daemon.jar:/usr/share/jetty/start.jar:/usr/share/jetty/start-daemon.jar:/home/naftoligug/jrockit-jdk1.6.0_29-R28.1.5-4.0.1/lib/tools.jar -Xmx256m -Djava.awt.headless=true -Drun.mode=production -Djava.io.tmpdir=/var/cache/jetty/data -Djava.library.path=/usr/lib -DSTART=/etc/jetty/start.config -Djetty.home=/usr/share/jetty -Djetty.logs=/var/log/jetty -Djetty.host= -Djetty.port=8080 org.mortbay.start.Main /etc/jetty/jetty-logging.xml /etc/jetty/jetty.xml

start on runlevel [2345]

With DPP's jetty, you could probably just write something like

exec /path/to/start_prod.sh

start on runlevel [2345]

(but I don't know for sure).

To start and stop it manually, you run

sudo start lrbcol # that's the name of the file in /etc/init without the .conf

sudo stop lrbcol

sudo restart lrbcol

On Monday, February 27, 2012, Anton Andriyevskyy wrote:

Thanks, I'll read about upstart.

--

[Franz Bettag]

I use David's shellscripts and i simply put them in my /etc/rc.local to be started.

Either use "exec /path/to/start_prod.sh" (as nafg wrote) or do it like me "/path/to/start_prod.sh &"

rc.local is prolly the cleanest way, that's where stuff like this belongs (presuming you're on Unix/Linux)