How to deploy my Rails app to a shared host - ruby-on-rails

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).

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.

Rails Deployment 101

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

What is Plan B for when heroku goes down on your production app?

This question is inspired by this recent outage:
https://status.heroku.com/incident/212
There doesn't seem to be much I can do here. I can't push at all, and pushing seemed to be what broke it in the first place. AFAIK, I can't switch over to a new server deployed on aws or elsewhere without fiddling with the DNS records. What should I do?
When you use an "all-in-one" service like Heroku you accept and understand than, in case of this kind of issue, you're in their hands and there's nothing you can do.
You can keep a backup system configured elsewhere but, from my point of view, this is a waste of time and resources because:
it requires you to configure and clone all Heroku settings and features
it's a double work
in case of issues, the only way to redirect the traffic to your app is to change DNS settings. The change requires DNS changes to propagate
if you can clone Heroku features, you might not want to use Heroku at all
It's a good idea to have an off-site backup of your application, database and features. But on the other side, these issues are the trade off of using this kind of services.
The only real thing you could do would be to not rely on a single service provider for your application. This means that you would need to break out the DNS from the hosting platform so that you can re-point to a different platform (such as AWS).
Depending on your hosting platform, there are different options, but in a nutshell, the key is to reduce single points of failure and have plans in place to switch over when things to fail.

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/

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