[web-devel] Deploying a yesod app to production, without compiling in production servers.
nubis at woobiz.com.ar
Thu May 12 20:39:49 CEST 2011
On Thu, May 12, 2011 at 12:52 PM, Rick Richardson <rick.richardson at gmail.com
> 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
>> * 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.
>> ----nubis :)
Thank all of you guys, following rick's recomendation of not having
compilers on any server, which makes a lot of sense I'm going to be building
an ubuntu .deb package. I just realized how easy building a .deb is, just to
stress the obviousness of obvious: The binary package system of a binary
distribution is likely the best tool to package and install binary software
packages in said distribution.
It's really dead simple, and I'm going to be using ldd to always get an
updated list of the libraries I need when building the .deb.
For now I won't be using much debian package dependencies and my package may
not end up playing well with other packages if I were to install them, but
I'll improve it over time to use debian package dependencies instead of
bundling all the so's in mine.
Here's a link for those of you who like me never got into building debian
packages, skim through it you'll see how simple it is:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the web-devel