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

[Rick Richardson]

For security reasons, I would strongly recommend against compiling (or even
having anything remotely resembling a compiler) on your production server.
 For that reason, you should probably also leave it off of your staging
server (apt-get remove build-essential)  :)

That said, the easiest long-term way to manage binaries in a production
environment is to statically link.    If your enterprise is successful,
chances are you'll move on to other products/projects and the older products
will still be running on those machines, but you will have likely upgraded
your development environment (especially when using Haskell) .   It is
easiest to minimize your dependencies on .so's.  Just my $.02



On Thu, May 12, 2011 at 10:28 AM, 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.
>
> * 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.
>
> * 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.
>
> 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/ff1fcf4e/attachment.htm>