I'm new to Dokku, and got a mature Heroku project running for 3 years, I got this annoying issue that Dokku thinks my rails app is a node app probably because I got the package.json file that I use for client side tests. What should I do (currently I renamed this file to trick Dokku but this is kind of hacky) to tell Dokku I have a rails app? What is the proper buildpack I should specify and how.
You can specify a custom buildpack as noted here.
For your application, you'll probably want to use the ruby buildpack.
Related
I have the following directory structure:
Which files must I drag into remote site of Filezilla for this ROR project?
When deploying a ROR project you should must use a VPN server. Have you used git for your project? Try to deploy in heroku first. To test your site and have a good practice when deploying rails.
https://devcenter.heroku.com/articles/getting-started-with-rails4
The answer to the question would be: everything
But most likely, copying everything is not gonna make it run, here is why: Rails applications live in separate processes that have to be specifically maintained. On your dev machine, you do this with bundle exec rails server. This is a key difference to how the apache php module works for php apps: There the php interpreter is embedded within the apache process and therefore shares its life cycle automatically.
If you have control over the server you are deploying to, I recommend to start with the Phusion passenger apache module. It takes care of starting your rails processes as needed. In case you are using ubuntu 14:04, I can't recommend to just apt-get install libapche2-mod-passenger because I had many problems with it.
If the server is maintained by somebody else, I'd ask this someone for a solution.
I hope this helps.
I have made an app with the use of Git and Heroku.
I'm curious if i can deploy Ruby on Rails locally without using Git.
If you aren't going to deploy to Heroku, you don't technically need Git at all. Just delete the .git folder. Given that Git is a great tool however, doing this is a bad idea.
You can deploy a Rails app locally, and the typical way to do this is with Apache and Passenger ( I'm assuming you are using a flavor of linux, OSX may have a host running already ).
It has been a while since I had done this, but this page seems to have the right idea:
https://nathanhoad.net/how-to-ruby-on-rails-ubuntu-apache-with-passenger
Rails s or rails server (in terminal) and you have localhost:3000. This is your local rails program and is incredibly convienent for development. Of course you need to be in the directory of your program to deploy it on localhost
Does anyone here know how to deploy a Ruby app on Bluehost? I am having quite a problem with this. Everytime I put my files inside the folder where my domain is pointing at, it always giving me a 403 error when I try to visit the website.
It's so painful. The instructions are incomplete. There are a bunch of things to get caught on like broken versions of sass, assets not pre-compiling, database configuring, how to restart the server, the root directory for passenger, etc.
I had problems with all of those things. I had to come here (Stack Overflow) to find most of the answers.
My site still runs in dev but not in production. The BH support is not much help. THey should call it BlueWordPressHost because that is who they are supporting.
Look in the <rails_root>/log directory for clues.
I'm not willing to switch over to Heroku and use postgres, I tried it but in reality your just dealing with another set of problems setting it up.
Give it a look -> Ruby on Rails Setup with Bluehost.
You cant just drop your Files in a folder.
Although Bluehost does a great job, i recommend you using Heroku for deploying Ruby on Rails Apps.
Deploying with Heroku is quite Easy -> Deploying with Git
I followed the instructions in the Ruby on Rails Setup as The Mini John referenced and it worked. They use Phusion Passenger to allow you to deploy any rack based application. However, I did have to manually install my gem dependencies. This is probably not a scalable solution for a production application with many users. However, if you already have bluehost as a hosting provider and are willing to maintain your own server and deal with possible latency issues and downtime, it may be worth it for you. Here is my Ruby on Rails 4.0 "Hello World" application deployed to bluehost: http://hello.getplanit.com.
I am in the process of learning Ruby on Rails and things have been going smoothly - up until I tried to deploy one of my test applications to my shared hosting account.
I use Host Gator and was able to successfully create a new Ruby on Rails app via cPanel and run it. The only problem is that when you create a new app this way, it populates its directory with a blank application - as would rails new app_name locally. When I delete the files and folders in this directory and replace them with my own, then attempt to run the app, cPanel says that it is running on the confirmation page but it never actually starts. I am not receiving any error messages either.
The host seemed rather stumped, stating that it should be a matter of deleting the initial files and folders and replacing them, then running. The app works fine locally so I do not think that it is a code issue. In my research I came across Passenger, although it is way over my head and it would appear that you really need to have total control over Apache to make it all work, including ssh.
If it makes any difference, the apps I made locally were put together using an installation of Rails Installer and are scaffolded. For testing I am using a bare minimum app with about three fields in the table.
What am I missing? Any help would be appreciated.
Maximum supported versions on 26/10/2013 are:
Ruby 1.8.7
RubyGems 1.8.25
Rails 2.3.18
Anything newer than that is a near guaranteed breakage and cPanel & WHM will be incapable of utilizing it in any way, shape, or form.
We can assist you with removing your existing Ruby on Rails installations and reverting them back to cPanel supported and sanctioned versions (Ruby 1.8, RubyGems 1.8, and Rails 2). That is the only thing we can do for you at this time.
If you want to use any versions newer than this, then you will be unable to use the cPanel & WHM interfaces or management tools for it -- they simply will not work. You will then have to manually manage your RoR install by yourself through command line exclusively. None of it would fall under the scope of cPanel support.
You can use http://ndeploy.in which is a third party plugin to integrate Rails Hosting via Phsuion Passenger in cPanel .
Just to let others who is using Cpanel with rails know.
I was able to use Cpanel to create a rails app, start it, and do the redirection all within Cpanel.
Nothing to modify or change. Quite straightforward for me.
So I guess it would be easier to do the development work straight on the server itself.
Have not tried to deploy a locally developed rails to shared server, or any per se. But I'm guessing we could create rails with Cpanel and replace the files in the directory generated.
I admit that I don't follow much of anything "right" on deploying test versus production code. I have been using ASP.NET, and I typically run it locally in Visual Studio, it works, I upload it, I test it again on the production server.
I have read several people say that deploying Rails apps is harder and there are special programs/ways on the ruby site about deploying RoR. I've only toyed with RoR. What is special about deployment? You don't just copy and paste the code and run it (from development machine to the production)? Is it because one is in Apache and the other running on the built in server?
This will be on a Mac Server if it matters.
Deploying RoR is not difficult anymore, especially with Phusion Passenger.
What is somewhat difficult, is getting a automated production environment setup with capistrano, vlad, etc. If you don't mind simply copying your code to the server, you can do that just fine. Most people choose not to do it that way because you lose out on a lot of the benefits that the automated deployment tools give you.
I guess people consider a Rails app harder to deploy than say some PHP apps or such where you just plop the code somewhere and point Apache or whatever at it. But, as mentioned above, you could do that now with Phusion Passenger.
We use Nginx+Passenger, but not for simplicity of deployment. Capistrano is our deploy tool of choice, and really, unless you have a very simple app, you're going to want something like Capistrano anyway. For example, with our deploy, we do a slew of things:
run any database migrations
generate release notes automatically, based on all the commits to Git between the last deploy and this one
notify various people via email (with differing lists depending on whether the deploy is to our staging environment or production) - we do this via cap_gun which integrates with Capistrano.
Notify New Relic RPM of the deploy so it can mark it in our RPM analysis
Notify Hoptoad of the deploy, so it too can have that data when reporting any exceptions
produce our sitemap.xml file, and ping Google to tell them there's a new one
update crontab files (I store our crontab files for each server in our git repo, and then on deploy it sees if there is a new version and updates accordingly, etc.).
flush/restart memcached
There are other ways aside from Capistrano, but it's a proven tool, with a lot of flexibility, yet pretty simple to setup a vanilla configuration.
So, my take is that once you get into any app that is beyond just the very simplest of apps, you're going to need/want to be doing things other than just simply updating the code. In the beginning though, if you just need the code updates, and maybe Rails migrations, then you can do simpler things like Passenger and code sync, or look at tools like Heroku or Engine Yard's stuff where they do a deploy by doing a Git clone (and then offer some additional abilities).
Another super easy way to deploy is with http://heroku.com/
Some of the issues you face with deploying rails to production:
Database connection.
You need to be sure that the database connector is set up for the production environment.
Database migrations.
You have to run database migrations against the production database even though you may have already run them in production/testing/staging
Ruby version. The version or sub-version or Ruby can trip you up, e.g. An error occurred while installing debugger-linecache (1.1.1), and Bundler cannot continue
Gem dependency.
Your production environment may have different packages and gems from development. Bundler will figure this out for the most part and install the dependencies but occasionally there are still issues that you have to resolve manually.
Dependencies.
Some gems on some machine have particular dependencies. I have seen frequent problems with using gems on my unix box that work on OSX and vice-versa.
Note the last 3 shouldn't affect you if on the same machine but I included them based on the title and to be comprehensive.
It's not especially hard. If you stick to conventions then with a little bit of configuration it boils down to this:
cap deploy
...however there is sometimes a bit of effort needed up front to get the workflow in place.
The good news is that lots of people have packaged up solutions and stacks for RoR that you can just plug and play. For example, google ec2onrails - this is a packaged Ubuntu image and set of capistrano tasks for running rails apps in Amazon's EC2 cloud, with lots of common stuff set up already out of the box.
Choose a good hosting provider and you should be able to find something similar for that also.
An easy way to deploy Rails apps is to use Phusion Passenger. Deployment doesn't get much easier than that for any programming language or framework. You can do that on a Mac server.
Another really easy way to deploy rails is with jruby and the glassfish gem.