Rails Deployment 101 - ruby-on-rails

I am about to deploy my 1st Rails app. I am stuck as I don't know what exactly I need to do. I know about Heroku, AWS, Capistrano and the like, but don't know exactly what they do, and what their benefits are.
I kinda know some things, but all are blurry and ambiguous since I have no formal training and learn as I go. So basically I need someone to explain the general anatomy of Rails deployment.
Something like: 'To make any app working on the web you need the following components... Ways to make this component work with Rails are following. Alternatives are these. These are pros and cons.' Not into too much detail, but general and comprehensive 101 guide.

The reason you may be confused is that there are a number of ways to do it. :D
Heroku provides one of the easiest solutions for basic deployments. You don't need capistrano, just git. (they provide a toolset to assist). Just git push heroku master. Also nice is that a simple deployment on heroku is free; you can pay for more power when you actually need it.
But if you need a little extra functionality that heroku can't provide, you have to host elsewhere, such as a private virtual host.
Capistrano is a set of recipes that help build a deployment environment, sort of like rake tasks. It does so in a very organized manner and allows for easy rollbacks. You define the hosts, their roles, and then the recipes use ssh and scp to set up the evironment. (the server also has to be ready to accept rails applications, through something like passenger)

The Rails and Ruby World(s) are pretty noisy, so I understand your confusion.
At the end of the day, you need your rails app on a server.
Now, even the term server can be a little confusing, because it is generally associated with
A remote machine
A program handling HTTP requests.
(for example webrick or thin which you start when you are developing on your computer and type rails s)
In your case you actually want a remote computer (hooked up to the net) which is running a program called a server to process HTTP requests and forward these to your app which in turn produces a request...
Heroku will help you out with that. (However Heroku adds several layers of abstraction to the mix. So it is not like you have one computer sitting somewhere in the heroku office, serving your application.) Heroku is dead simple to setup with git and rails.
And in the end all that is need to get your app to the "remote server" is a simple git push.
Read the beginner articles on https://devcenter.heroku.com/
I would also suggest for now: Forget about Capistrano.
Oh and you can think of AWS (or probably S3) as some sort of external hard drive, which your app can use to store larger pieces of data (like images, videos etc.)

I have a deployment guide with a good shell script which support Nginx + RVM + Unicorn: deploy_rails

Related

Heroku to AWS Migration Advice

From what i've gathered, there are many solutions to my problem but i'd appreciate some suggestions on where to start. here's the stack we're running on heroku currently:
Rails on puma
mongoDB
elasticsearch
redis
mini_magick
What goes into the decision of using Elastic Beanstalk vs OpsWorks vs CloudFormation vs just setting up everything manually myself? Also, I'd really prefer, for financial reasons, not to use some third party service like Docker if possible. The plethora of options leaves me a little confused as to where to begin or how to even choose. Background: right now I really like Heroku b/c i don't have to think too much about sysadmin (on my team i'm the only developer), but we were recently given a lot of annual AWS credits so it seems to make financial sense for us to shift over to AWS.
I want to expand on Mark’s great answer.
Available alternatives
Since you’re the sole developer, Cloud Formation and OpsWorks aren’t good options for you.
With OpsWorks you’ll need to write, or at least be aware of, the Chef automation code that configures your instances. On the other hand, Cloud Formation by itself isn’t enough. It will help you with AWS cloud resources creations, but you will still need to figure out how to orchestrate your applications deployment, just for starters.
Neither of these options can give you everything you need to run and deploy your code like Heroku does right out of the box. You’ll need to implement parts of it by yourself.
Since rolling your own automation on top of EC2 takes even more effort than the options above, I think you have two alternatives within AWS that will fit your needs:
1) Elastic Beanstalk
It’s the closest you can get to Heroku within AWS. You might have to spend some time getting to know the platform at first since it’s not as intuitive as Heroku, but eventually Elastic Beanstalk will provide you with all the tools you need to continue running your applications without spending time on sysadmin tasks.
2) ECS + Empire
Although you mentioned that using Docker is out of question for you, I still would like to highlight the option of using ECS, Amazon’s Docker orchestration service, as an alternative to Heroku.
By itself, ECS doesn’t provide enough automation to do everything you would expect from a PaaS. The service was intended to be used as a building block which you should extend to fit your needs.
Luckily, the guys from Remind have already done this for you. They have released an open source project called Empire, which according to its own description is “a control layer on top of ECS that provides a Heroku-like workflow”.
Empire is compatible with Heroku’s API, and its command line implements the most important features of Heroku.
Empire is an open source project, so if you choose to use it, you should be prepared to dig into its code from time to time. The documentation isn’t perfect, and although there is some traction around the project, the community isn’t very big.
Overall, it’s a good alternative to Heroku if you’re willing to run your applications using Docker -- and why shouldn’t you?
Addons
The main benefit I see to switching from Redis Labs to Amazon’s Redis service (ElastiCache), other than the fact that you have free AWS credit, is that it’s going to be easier (and cheaper) to secure access to your Redis instances when you also run your applications on AWS.
Overall, it’s relatively easy to replicate the addons you’re using with Heroku when you migrate to AWS. For the third-party addons like Elasticsearch you just continue pointing your application to the relevant endpoint. It’s a bit more complicated to replicate Heroku’s native addons like deploy hooks since you can’t continue to use them when you migrate to AWS. In these cases it’s usually possible to find alternative ways of replicating their functionality within AWS.
If you want to learn about how to migrate the most common addons, I’ve written an article that details how to do that, you can find it here: how to replicate Heroku’s addons on AWS.
Hope this helps.
For your Rails app, Elastic Beanstalk is going to be very similar to Heroku. I would suggest using Elastic Beanstalk if you are already familiar with a PaaS like Heroku. It's probably going to be a bit more difficult to configure at first (there are just a lot more options you can configure), but then it will be a very similar deployment process to what you are used to.
Of course Heroku and most (probably all) of those other services you are using run on top of AWS already, so you would really just be switching from one set of services built on AWS to Amazon's own version of those services. You could possibly continue using some of the same services you are using on Heroku. For example I believe MongoLab is the recommended service for MongoDB on Heroku, and it is my preferred MongoDB-as-a-Service on AWS as well. If you want to use those AWS credits for MongoDB you will have to setup the EC2 servers and install and manage MongoDB yourself.
For Redis you could use Amazon's ElastiCache service or RedisLabs. I've found the features and price to be better with RedisLabs than ElastiCache, but you can use your AWS credits with ElastiCache.
For Elasticsearch you would probably want to use Amazon's new managed Elasticsearch service.

How to deploy my Rails app to a shared host

I have been chipping away at this for the last couple of days but it has become quite frustrating. My web host is "JustHost" and I have a shared hosting service. I have found this translates directly to "strips you of all privileges," when it comes to trying to set up the deployment on the server.
I thought I had found some really good tutorials that might help me to get my environment set up (I tried to Follow Rob McLarty's blogs on How to setup a Production Server and How to Deploy a Rails App as best as I could). The problem that I found is that I couldn't/didn't need to install any of the things recommended, and when it came time to try to set things up I didn't have permission over the files that were recommended to modify or I didn't have permission to use the commands that were needed.
Naturally I can see why this would be important on a shared host. It would be silly if each individual on the host could restart an apache server willy nilly.
Regardless, I have found this to be the problem with most of the research into getting this deployment up and running. Simply put, most of the things that are recommended I don't have permission to access.
Does anyone know how to setup a deployment on an environment that is so restrictive? Even some resources, or a simple "you are thinking about this way too hard" to point me in the right direction would be really really helpful.
I highly recommend OpenShift as a platform for deploying your rails app on a shared environment. It gives you the option to start for free with a small amount of resources in the server and gives you the ability of starting up everything you need at first like relational or NoSQL databases, loadbalancers, cache, etc.
Heroku is a simple setup formula, For a shared host ROR Deployment Found a good reference : REFERENCE LINK this will help to deploy ROR App on a shared host.(some modules may not be allowed on a shared server environment. You may have to go for a VPS to meet all the requirements).

Deploying rails: What to choose?

I have just finished a Rails-application that I now want to upload to the web. It is a re-write of an existing application and I expect some 4 000 visitors a day with peaks to 10 000 a day at times.
I know Windows fairly well (have not used Windows server though).
I hardly know anything about Ubuntu or Linux
I want things nice and easy and don't want to spend too much of my time "hacking the server". I want to spend my time developing, not maintaining.
My budget is ~50$ a month at most for this project.
The database for the project is quite static (hardly any user generated data)
I am currently using WAMP & Mysql with Rails 3.0.3 on my local installation and it works fine most of the time but crashes quite often as well.
I am considering three ways of doing that:
Using Heroku
Seems quite easy (even though I haven't gotten it to work yet)
Also seems expensive, if I need more nodes. How many nodes should I expect to need?
Using a VPS Windows server
I know Windows and it would be fairly easy to install and get it set up
My friend (who is more of a Rails expert) says that Windows and Rails is not a good match.
My crashes on my local environment makes me nervous about this option
Using a VPS Ubuntu server
Seems to be the cheapest option (in terms of paying up-front)
Seems to be the most stable option
I don't know Ubuntu and I am not too eager to learn a whole new OS to get this set up.
Could you help me with directions? Is Windows server really bad for Rails?
Quite honestly, I think Windows would be the worst choice for you. The problem with Windows and Rails is that most of the gems are never designed to work with Windows, or the versions that do work with Windows are far outdated.
Using an Ubuntu VPS is a very viable option, would be your cheapest and most stable option. We use Amazon S3 services to run most of our web servers in the cloud. Like you said, it does require you to know and understand a *nix operating system to maintain.
Maybe for you, Heroku may be the best option. Heroku is super simple to setup your project on and then deploy. There are also pages of documentation to help you along the way. In a few basic commands from the terminal, your application is running. I often use Heroku as a 'staging' server to test application updates among beta users before pushing to production on S3. You also are not required to learn a new operating system to use it.
If you are running into problems with deploying to Heroku, please post the issues and we will gladly help you.
I would advise against a windows server. From my experience, the major ruby implementations are not optimized for windows - and run slowly. For the sake of your end-users, a rails stack on Linux may provide significant performance gains (or equally decrease your server budget).
With bundler and rails 3, the amount of maintenance work on the server should be minimal. Log in, deploy, log out. (look into tools like capistrano to make this even more straightforward).
By far the easiest production I've found so far is an Ubuntu server.
On Windows Rails tends to be slower and it's far simpler to setup something like passenger on *nix. If help is needed, there are more tutorials available.
My fastest setups have been Ubuntu Server and nginx.
PS. Rails 3.0 has gone beyond 3.0.3 so think about testing the latest version 8)
Heroku is delightfully easy to deploy to. If your database load is light, you can just use their shared 20GB PostgreSQL database ($15/mo). 2 dynos will cost you ($35/mo) so there's your $50 there. 2 should be fine to handle that traffic, and you can always scale during your high traffic times. Definitely would recommend adding the memcached add-on and utilize that as well. Install the New Relic add-on and you can analyze your traffic/load and scale accordingly.
I'd heavily advise against using Windows for a rails app deployment. Some gems compile slower on Windows, and some don't work at all.
I've worked with Heroku, but there are some complications with writing files to the Heroku instance as Heroku does not allow for local file writing. When working with Heroku, people usually offload write operations like file-upload to an Amazon S3 instance or Fog. In general, Heroku is really easy to deploy to, but when configuration comes along...it may be a bit more complicated than a VPS.
The best solution for me would be to go via VPS using Ubuntu. There's been a lot of documentation done on this, and you have more options with your configurations. In actuality, it's not so much different from setting up Ruby on Rails on a local Ubuntu development machine. If you need tips on how to deploy on Ubuntu, I've just recently written a guide on how to do so.
http://www.francisbautista.com/deploying-ruby-on-rails-apps-on-a-vps-nginx-passenger-capistrano/

Should I deploy my Ruby on Rails application on Heroku [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
A little about myself. I am 24 years old, I graduated from NC State with a Master's in Analytics last year. Statistics, mathematics, that kind of thing. I don't have a strong programming background, which is pretty important for my question. If I say anything that doesn't make any sense, that is why. Ever since graduation, I have been working full time on a Rails app with a few other people. My programming experience is mainly Ruby on Rails (1.2 years.) I know R, SAS (statistical languages, not helpful for this question.)
Obviously, that means it has been over a year in development, and we aren't done yet. The main developer is an excellent programmer, just that he has a full time job already, and does this app in his spare time. Due to him not having enough time recently, I have been given practically full responsibility for the app.
We have it deployed on Slicehost right now. The app is at a point where we don't need to program anything else (unless we think of more features.) The reason I am asking if we should migrate to Heroku is that it seems to me that Heroku is a simple platform to which to deploy. Slicehost seems too complicated for me. The other developer dealt with it, and not me. I looked at how to deploy the app on Heroku, and it looks like I would be able to do it. We need our app to scale if it needs to, which Heroku offers. As far as money, I would start it at the minimum (free) and see how it goes. I can pay for additional features if I need to.
We are using Redmine for project management and repository (not git, which I think we need to use on Heroku.) Is git similar to Redmine? Is it easy to use?
Right now, on Slicehost, we have 4 daemons (constantly running processes.) We have 8 delayed_job workers. I know the command line to start the daemons and delayed_job workers. Would these work on Heroku?
I am wondering if I can still use RAILS_ENV=production script/console with Heroku.
The user interface is a javascript file. In development mode, if I do script/server in a terminal, and go to http://localhost:3000 in a browser, I can see it. Would Heroku load this page the way I want?
We have a working website for the app, with our own domain name. I don't really know what DNS is, so I probably wouldn't be able to link the Heroku app to it, unless there is an easy way. I think Heroku links it to appname.heroku.com as a default.
Based on my programming experience, would Heroku be easy enough for me to use, should I find another job, or should I commit seppuku?
Yes, you should definitely deploy your application in heroku. To do this, this is what you will need to do:
Make sure you have git installed in your computer
Create a heroku account here
Install the heroku gem and do the rest as mentioned in this page
Track your application with git, and create your heroku application as shown here
After you do this, heroku will provide you with a URL for your application, such as http://blah-bleep-123.heroku.com. Now, the next step would be to associate your domain to this heroku URL.
Configure your domain DNS Server as shown in this page. Mind you, after you change your DNS, it might take upto 48 hours for it to work. You can change your domain DNS by logging into the site where you bought your domain, for e.g. godaddy.com, hostingdude.com, etc.
Add this code to your ApplicationController. You can follow this from this page as well
class ApplicationController
before_filter :ensure_domain
APP_DOMAIN = 'www.mydomain.com'
def ensure_domain
if request.env['HTTP_HOST'] != APP_DOMAIN
# HTTP 301 is a "permanent" redirect
redirect_to "http://#{APP_DOMAIN}", :status => 301
end
end
end
Make sure you migrate all your database in heroku, by doing heroku rake db:migrate
After you have completed all these steps, you should be good. Check out your domain URL, everything should work pretty :).
If you see any errors in your page, you can view the log by heroku logs
You can access console as heroku console
With features as these, heroku is very convenient to work with.
Please let me know if you need more help.
It seems to me like you should seriously consider Heroku. I have used it for weekend projects and we use it at work as well, quite successfully. Deployment is a breeze, you don't have to worry about setup (for the most part) and system administration. It's super easy to add modules and "pay as you grow".
As for your needs, you could (I believe) run your redmine on Heroku itself, being a rails app. The only thing is that you mention you use Redmine as "repository" and I'm not sure I understand what you mean, since Redmine is not a version control system. Redmine has integration points for various VCS (SVN, git, Mercurial, CVS, and others). Yes, Heroku uses git and that is what you would need to use in order to push code to the server. If you're familiar with Mercurial, it's pretty similar.
For delayed jobs, Heroku offers free cron jobs that run once a day and hourly ones for a fee (see cron add-on). There is also a delayed job plugin (see this) but I don't have any experience with it.
You should be able to access the Rails console (see heroku docs). Just run 'heroku console' and voila, you're there.
If your app works by running script/server, it should work out of the box in heroku too.
As for the DNS, getting it to work with your custom domain is not hard. Out of the box, you can access your app with appname.heroku.com, to set up your custom domain check heroku docs here, but basically you have to add the custom domain add-on (free unless you want subdomains), configure heroku to respond to your domain's requests (couple of simple commands) and set your DNS provider to point to Heroku (there's even a short video in the docs on how to do this with GoDaddy).
The only drawback I've seen with Heroku, and it's not a huge one, is that if your app does not receive any traffic for an extended period of time, the instances kind of "go to sleep", making the next request to arrive somewhat slow (sometimes even timing out), but once the instance is awake, everything is good to go.
All in all, I think Heroku is a great way to take a ton of the burden off of you as a dev and making a lot of things really easy to implement without having to go into the nitty gritty of setting up a server. The downside: once you start growing, it can become somewhat expensive, but hey, if you're growing it probably means you have the cash now to hire someone that can take care of the nitty-gritty.
You might also want to take a look at this blog post which compares Slicehost and Heroku
Best of lucks
YES, go for it.
If you've managed thus far on the strength of your 'programming experience' then you'll be fine. Have some confidence and ship something! To quote Paul Graham:
The reason to launch fast is not so much that it's critical to get your product to market early, but that you haven't really started working on it till you've launched. Launching teaches you what you should have been building. Till you know that you're wasting your time. So the main value of whatever you launch with is as a pretext for engaging users.
The functionality you outline is easily replicated and well documented and it's free to start with. What else could you ask for?
If you have the free time, you might as well sign up for a free account and give it a shot.
HOWEVER, this is going to come with some pretty severe headaches.
Version control will be one, since heroku uses git, but another one that no one's mentioned yet is that your 12 processes ("dynos" in heroku speak) would cost you $35 * 11 = $385 per month! You can set up an hourly cron for $3/month that will flush your delayed_job queue (instead of having workers running at all times), but is that going to be adequate? (If you're running 8 workers, I'm guessing not). This may or may not require some code changes.
Once you get it set up, deployment and admin is really easy (nonexistent), but it'll cost you if you start needing new features.
YES, go for it.
Its good deployment environment any its fast and easy scale out and scale in feature.
even you can use for your testing or demo usage its provide you free account usage of 1 dynos per app.
List of add-on tools available you can add as per your requirement.

Is there a Ruby on Rails host that supports FTP?

I'd like to create a development integration server that's on the open internet, running a Ruby on Rails app. But I need FTP or SFTP access to this server, so I can upload files to the codebase via FTP.
Is there a good Rails host that allows FTP connections? The cloud providers like Heroku and Dotcloud just support pushing from source code or build files, it appears.
Thanks!
If you have experience setting up a Linux box I'd suggest using a VPS service, like Linode (www.linode.com) for instance, that way you can pretty much have any service running that you want. And if you don't have experience, that's a great way to learn ;)
If it's just for development, Dreamhost's shared hosting works well enough and is affordable. $8.95/month for unlimited domains and storage and bandwidth and it supports Rails via passenger/modruby. You get ssh and sftp access and you can schedule cron jobs too. Especially great for development since you can easily create and destroy apps and subdomains. Main downside is that you'll face a tough time if you need any custom gems or if you need a different version of ruby from what your host's passenger is using. Customer service is good though, and they can install custom gems or move you around between shared hosts if need be. I probably wouldn't dare to deploy a live Rails site on their (or anybody else's) shared plan though.
All that said, lately I've moved to Heroku for dev/staging instances. Not worrying about custom gems is a big plus, and since we deploy live on Heroku it's nice to have almost the exact same environment in staging as well as live. Heroku is free for single-dyno apps as long as you don't spend too much time in the heroku console. Pushing code from different branches to different instances becomes a piece of cake when you use heroku-san.

Resources