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

On Thu, May 12, 2011 at 5:28 PM, Nubis wrote: 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@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

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 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@haskell.org http://www.haskell.org/mailman/listinfo/web-devel