0

I'm looking to group together the information on the current best practices for deploying a Rails application on a server I run (rather than, say, Heroku). The application is developed by multiple people, and they all have permission to deploy it. The application will run on a server that may have more than one application.

  • Use Apache or Nginx with Passenger
  • I use Ubuntu, but that shouldn't make too much difference.
  • Capistrano seems to be the best way to go to push to the server.

Now, some doubts I have:

  • Use RVM or not? Passenger can only use one version of Ruby, so it's sort of useless, no?
  • How would you structure user permissions and ssh keys? My thinking is that you definitely don't want to have the user be 'yourself' (dnw, say, on the server), but a role account. Is Ubuntu's www-data sensible for this, or would it be better to create a different user? One for each application? What sort of configuration (shell in /etc/passwd, for instance, groups, etc...) should these users have to make the system as safe as possible if someone finds a vulnerability in the web application? What sort of capistrano recipes would you utilize to achieve this?
  • Now, we add git into the mix: git needs to be able to pull without a password from the git server, so there's going to be some key exchange going on. How should the remote git setup look like in order to make things nice and safe?
  • Anything else that I'm not covering?
David N. Welton
  • 103
  • 4
  • http://www.modrails.com/documentation/Users%20guide%20Standalone.html - looks like this may be a worthwhile option, since it has the advantages of Passenger, and lets you deploy with its own Ruby. – David N. Welton Jul 11 '12 at 08:22
  • Except each standalone passenger is it's own resource pool, and doesn't share worker counts with any other. – womble Jul 13 '12 at 06:45
  • 1
    You can use agent-forwarding to allow git on the deployment-server to authenticate to the git-server as you, which may (or may not) be useful. – nickgrim Sep 10 '12 at 12:22

1 Answers1

1
  • Nginx/unicorn (Passenger is more trouble than it's worth, especially when you're dealing with multiple Ruby versions). Unicorns managed by daemontools / allah, because god rustles my jimmies.
  • rbenv rather than RVM (rbenv is designed to do one thing and do it well, rather than RVM's "do a painful half-job of everything" approach)
  • User per application, with SSH keys for each dev who has authority to manage each individual app.
    • You can run the application itself as a separate user and use ACLs to allow access to only those parts of the filesystem the app needs; this app user should not permit logins. I personally consider that to be overkill, but it's a possibility if you want to have a bit of incremental separation.
  • Capistrano is another "painful half-job of everything" tool; I recommend giddyup, although that might be because I wrote it.
womble
  • 96,255
  • 29
  • 175
  • 230
  • 1
    +1 for suggesting some useful things, but I see unicorn as much more suited to a one site system, rather than a system with multiple applications: Passenger is good at allocating instances when needed, and removing them when they are idle. – David N. Welton Jul 09 '12 at 20:49
  • It's still more trouble than it's worth. – womble Jul 10 '12 at 03:36
  • 1
    It's the best option you have for a memory starved VPS with lots of little non-Heroku-able applications. Sometimes Unicorn and Thin are more trouble. – Rob Howard Jul 11 '12 at 11:32
  • That hasn't been my experience. – womble Jul 11 '12 at 23:04
  • I think having a system that is unable to dynamically de/allocate resources as needs be is a bad solution for certain types of situations (like mine), as Rob mentions. I have lots of little apps, some of which should minimize resource usage when they're idle or not used much, and if they get traffic, should start asking for and getting more resources, up to some sort of limit. – David N. Welton Jul 12 '12 at 15:02
  • Unicorn can change the number of workers without needing to restart. The only thing Passenger gives you is a way to not have all apps in memory at once, but at the cost of horrendous time-to-first-response, and the inability to have different versions of Ruby for different apps. I'm just not seeing the win. – womble Jul 13 '12 at 08:51
  • womble: what Unicorn does not do, from my understanding, is dynamically allocate and deallocate workers. In other words: I have a small site that normally doesn't get much traffic. Once in a while, the guy who owns it sends out a newsletter, and gets lots of traffic for a day or two. The system should be smart enough to allocate extra resources in that period, and then remove them when they are not needed. That kind of thing is not rocket science... – David N. Welton Jul 13 '12 at 12:47
  • No, it isn't rocket science. What's your point? – womble Jul 13 '12 at 19:54