[web-devel] Deploying a yesod app to production, without compiling in production servers.

[Michael Snoyman]

On Thu, May 12, 2011 at 5:28 PM, Nubis <nubis at woobiz.com.ar> wrote:

> Hi guys,
> After lots of effort, the yesod app I'm working on is finally ready to be
> deployed in a production environment, but I'm having a hard time deciding
> what's the best strategy to do so.
> I have proper development, staging and production environments. We'll be
> doing our coding on development, then tag a revision and push it to staging,
> and then if
> everything works fine we'll push that same tag to production. We're going
> to be using ubuntu 11.04 and all machines will be the same architecture too.
> My main concern is that compiling in production may be inefficient and
> badly stress the server, so these are my deployment options so far, I would
> like to hear your opinions on them,
> and maybe you can also answer some of the questions that arise from them:
>
> * Compile and statically link the app, then push it to staging, and if it
> works, to production:
>     Would be great, but I'm getting some warnings relating glibc and errors
> linking libgss which I could fix, but hint's that It's going to be painful
> to keep a statically linked version and suggest it's going to be brittle.
>
> I've had some bad experience recently with static binaries on Linux, but
that was switching between two very different systems. My guess is that
you'll be fine given that each system is identical.


> * Compile and move the binary and all the libraries it uses to the server:
>    In theory it should work, but I'm not sure which libraries or library
> directories I should move/rsync. I'm also worried this way of doing it could
> be brittle since I could add dependencies that install stuff
> in different places and forget to add them which would mess up my
> deployment process a bit and require further manual intervention.
>
> ldd should let you know which libraries are necessary here. If I'm correct
in my assumptions, you're going to be deploying using EC2, in which case you
might consider setting up completely automated script to take a vanilla AMI
and apt-get'ting all the relevant libraries, then testing the executable.


> * Compile on the server: It's really convenient since I could copy the
> source to the server and do a cabal-install there, but I'm afraid it will
> stress the server too much while compiling (granted, won't be often on
> production), but also keeping ghc and cabal on the server requires the extra
> work of keeping them up to date in an unobtrusive fashion. I tend to break
> my ghc install rather frequently, I wouldn't like to find myself logging in
> to production to fix a broken ghc/cabal/haskell platform install.
>
> I'll admit that I do this in practice currently, and it's very convenient.
I haven't noticed much in the way of negative effects from this approach.
Also, a broken GHC != a broken executable, so even if you screw up your
~/.ghc folder and can't install, your current site won't be taken down.
Though I'll admit, I ultimately plan on getting away from this approach.


> Thanks for your advice, also let me know if you think I'm too much of a
> slacker, unlucky, or worrying too much about nothing.
>
> cheers
> ----nubis :)
>
>
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20110512/7fa30565/attachment.htm>