HAppS Deployment + mod_proxy_balancer

[Ian Sefferman]

Hi all,
As we get ready to deploy our new Haskell/HAppS based web service,
we're looking for ways of doing this well.

We have a few servers which currently house apache2 and run other
applications off of port 80. Hence, we couldn't open port 80 with the
HAppS server if we wanted to.

What I was thinking about doing, and was hoping others had some
experience/thoughts on, is setting up apache2 to do NameVirtualHosts
for our new service, and using mod_proxy_balancer to forward these
requests to a pool of HAppS servers running on an open port.

Has anybody done this? Also, is there any way to start up the service
automatically without having to use screen? Is there a way to disable
the requirement of STDIN for the 'e' key somehow (we don't have a
dependency on the state checkpointing, so really there's no reason for
clean exiting, I think)?

Thanks,
Ian

--
Ian Sefferman | 248.819.7586
http://www.openomy.com | http://www.iseff.com

[Darrin Thompson]

On Nov 6, 2007 4:36 PM, Ian Sefferman <is...@iseff.com> wrote:
> What I was thinking about doing, and was hoping others had some
> experience/thoughts on, is setting up apache2 to do NameVirtualHosts
> for our new service, and using mod_proxy_balancer to forward these
> requests to a pool of HAppS servers running on an open port.
>
> Has anybody done this?

You might want to turn on, I think it's called PreserveHost. It's not
on by default. Other than that yes, I think the rails community has
demonstrated that reverse proxy can work in production.

--
Darrin

[Alex Jacobson]

Ian, the multimaster+spread mail is the full answer to your question.
What is your deployment timeline? I think if everyone pitches in, we
could get the nice multimaster-spread over EC2 implementation done
fairly quickly.

-Alex-

[Ian Sefferman]

Well, ideally, we wanted to get this going this weekend! :)

But, I'm not convinced that this is what we want. Perhaps I'm just
misunderstanding what exactly it is? Maybe a more thorough explanation
of what we're launching will help.

The HAppS service we're building is a REST-based API service to
Openomy, our project. So, the API service which we are going to deploy
is basically a filter. It transforms external requests (from any
application and developer), ensures access control/validity/etc and
then makes the appropriate call to our internal service. It's just a
bridge since it doesn't need state on its own.

So, we don't really want to use EC2 because we'd like to be close to
our internal services. And as just a bridge, we don't really need any
of the state that HAppS provides, nor the multimaster replication of
such state.

We just need to be able to run this from our boxes as easily as
possible. :) Our current plan was to use capistrano (since we use it
for other deployments) to build and deploy the code and startup the
HAppS server (if possible, getting rid of the need for STDIN and
daemonizing it somehow, but if not, through the use of screen), and
then start up an apache2 with mod_proxy_balancer to forward requests
to these servers...

Does that make more sense? Is there a more preferred way of doing this?

Thanks for all your help, folks!

Ian

[Alex Jacobson]

There is daemonize code in HAppS-Util. If you wrap your main in
daemonize I think it will do what you want.

-Alex-

[Michael Ilyin]

Did anybody tried to compile HAppS with latest ghc release 6.8.1?
I've replaced Data.Bytestring.Base imports to Data.Bytestring.Internal
and Data.Bytestring.Unsafe to make it compile. But then I've got
following error:
.haskell_cache/http_searchpath.org-default.map.cache/Data/Generics/SYB/WithClass/Basics.hs:27:17:
parse error on input `*'
on line "data Proxy (a :: * -> *)"
Anybody know how to fix that?

Best regards,
Michael

[Antoine]

On Nov 11, 5:24 am, Michael Ilyin <mil...@gmail.com> wrote:
> Did anybody tried to compile HAppS with latest ghc release 6.8.1?
> I've replaced Data.Bytestring.Base imports to Data.Bytestring.Internal
> and Data.Bytestring.Unsafe to make it compile. But then I've got
> following error:

> .haskell_cache/http_searchpath.org-default.map.cache/Data/Generics/SYB/With-Class/Basics.hs:27:17:

> parse error on input `*'
> on line "data Proxy (a :: * -> *)"
> Anybody know how to fix that?
>

There's probably a more specific LANGUAGE pragma that should be used,
but adding:

{-# OPTIONS_GHC -fglasgow-exts #-}

to the top of Basics.hs worked for me as a quick-fix.

[Alex Jacobson]

We are pretty closd to a new release of HAppS. We are being held up
right now by a bug in 6.8.1 that we hope will be fixed in 6.8.2.

The bug is that you can't derive Data for phantom types. If 6.8.2
contains the bug fix then we will be happy. If not, we will probably do
a release with a workaround which will cause HAppS code to be mildly
uglier until the bug is fixed in 6.8.3.

-Alex-

[tphyahoo]

Does that mean that HAppS head is buildable and usable on ghc 6.6.1?

If so, is there the possibility of releasing for 6.6.1, in case 6.8.1
takes longer than anticipated?

If HAppS head isn't buildable/usable with 6.6.1, I'm curious what the
features of 6.8.1 are required for the latest stuff.

thomas.

[tphyahoo]

never mind, I see on #happs logs that it is indeed so that you need
6.8.1. Everything is logged at

http://tuukka.iki.fi/tmp/logindex.html

t.