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?
3
  • 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. Jul 11, 2012 at 8:22
  • Except each standalone passenger is it's own resource pool, and doesn't share worker counts with any other.
    – womble
    Jul 13, 2012 at 6: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, 2012 at 12:22

1 Answer 1

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.
8
  • 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. Jul 9, 2012 at 20:49
  • It's still more trouble than it's worth.
    – womble
    Jul 10, 2012 at 3: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, 2012 at 11:32
  • That hasn't been my experience.
    – womble
    Jul 11, 2012 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. Jul 12, 2012 at 15:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .