I hate this about deploying Rails applications. It's always a teeny tiny little thing, but it almost always ends up with a trip through random stackoverflow answers, comments, blog posts and the occasional doc filed under 'known issues'.
I have _only_ 1 production application hosted on a hand-built DigitalOcean stack - hell it was a such a process I wrote a guide on how to do it, mainly for my own benefit in the future.
Surprise surprise, I try to follow _my own guide_ on a new project I started and it doesn't work as expected. Either RVM changed since writing it, Ubuntu issue with locales preventing postgres from starting, or the odd issue with postgres not installing with a default user. It's a cluster.
Alright, enough fiddling about. I bought myself a book to learn from a professional [0]. Surprise surprise! Outdated not 1 month after it's been released. No longer working, again hunting down the comments area. :P
There's a reason why Heroku is so popular: it makes deployments mind-numbingly simple. (Plus you can scale, but let's worry about that after the app actually runs!)
I'm going to give this a shot using a brand new Ubuntu 13.10 x64 DigitalOcean VPS with a simple CRUD rails application I have. But I'd bet my left arm that something is going to go wrong and yet again I'll have to dive deep into the recesses of the web.
100% agree with you. FWIW, this is much more heavily tested on ubuntu 12.04. One of the reasons we submitted it was the hope that we'd get more people to test & contribute. Goal being that you don't necessarily have to pay for heroku & can still own your servers, but can set up a new server in just a few mins.
If you run into hiccups, feel free to hit me up directly - ben@federisgroup.com. The plus side of this is that once you do get it figured out once, setting up other servers really is extremely quick.
We typically only put one app on a server, especially since Digital Ocean is so cheap. If things are tiny apps, we just stick them on a $5/mo 512mb droplet.
I used to pursue this same goal. Then I decided to reclaim my sanity and stopped swimming upstream. I dropped RVM in production environments and started using ruby-build to drop a Ruby in /usr/local.
When you do this you drop a ton of configuration overhead involved with custom paths to your Ruby interpreter. That doesn't sound like much, but when you're fighting with environments in login vs non-login shells, cron jobs, remotely executed Capistrano tasks, etc, it's an overhead that I'm happy to have behind me.
If one of our Ruby apps require a different Ruby version, it goes on a different VM. Sounds like overkill, but you can get a VM down to $5/month from DigitalOcean. How much time is $5/month worth?
6 comments
[ 3.2 ms ] story [ 23.8 ms ] threadI have _only_ 1 production application hosted on a hand-built DigitalOcean stack - hell it was a such a process I wrote a guide on how to do it, mainly for my own benefit in the future.
http://tech.pro/tutorial/1335/devops-for-dummies-vps-configu...
Surprise surprise, I try to follow _my own guide_ on a new project I started and it doesn't work as expected. Either RVM changed since writing it, Ubuntu issue with locales preventing postgres from starting, or the odd issue with postgres not installing with a default user. It's a cluster.
Alright, enough fiddling about. I bought myself a book to learn from a professional [0]. Surprise surprise! Outdated not 1 month after it's been released. No longer working, again hunting down the comments area. :P
There's a reason why Heroku is so popular: it makes deployments mind-numbingly simple. (Plus you can scale, but let's worry about that after the app actually runs!)
I'm going to give this a shot using a brand new Ubuntu 13.10 x64 DigitalOcean VPS with a simple CRUD rails application I have. But I'd bet my left arm that something is going to go wrong and yet again I'll have to dive deep into the recesses of the web.
[0] - https://leanpub.com/deploying_rails_applications
If you run into hiccups, feel free to hit me up directly - ben@federisgroup.com. The plus side of this is that once you do get it figured out once, setting up other servers really is extremely quick.
When you do this you drop a ton of configuration overhead involved with custom paths to your Ruby interpreter. That doesn't sound like much, but when you're fighting with environments in login vs non-login shells, cron jobs, remotely executed Capistrano tasks, etc, it's an overhead that I'm happy to have behind me.
If one of our Ruby apps require a different Ruby version, it goes on a different VM. Sounds like overkill, but you can get a VM down to $5/month from DigitalOcean. How much time is $5/month worth?