I have a simple Ruby on Rails application that works through a localhost test (both using sqlite, or ruby mysql2 gem).
I have a web server ready to upload my app online.
I understand that I need to create a new mysql database, which is no problem, and obviously add the connect info in the database.yml, but how do I propertly upload the whole thing (app root) to a public dir of my site?
Rails itself contains a few links to get you started with deployment. I was in your boat a while ago, and I got started with Passenger and Apache within half an hour (although I did have some light Apache experience going in).
Get started just to prove to yourself you can do it
Not that it's a good idea, but the balls to the wall easiest way to "deploy" is the following (assuming you've already pulled your application into your deployment environment, created your database, and run rake db:migrate and any application-specific steps like bundle install on Rails 3):
rails server -p 80 on Rails 3 (./script/server -p 80 on Rails 2).
There is no step 2.
This has to be run on a machine for which you have administrative rights and for which port 80 is not already being listened to by another application. This is suboptimal in many ways, most apparent of which is that it won't allow for virtual hosting (i.e., it won't cooperate with other "websites" being run from that server), but it's a good baby step to dip your feet into.
Go to the machine's FQDN or in fact any hostname that resolves to the machine's IP address (via a hosts file or an A record), and you'll see your application.
Now do it properly
You're going to want to do the following to bring your application "up to speed":
Deploy it behind a virtual host behind a webserver application like Apache
Use a production-oriented deployment setup (WEBrick's single-threadedness, among other factors, make it unsuitable for production)
Actually use the "production" rails environment
I'll be recommending a very, very typical Apache/Passenger deployment environment. The reason is that (at least it seems to me) this particular stack is the most thoroughly supported across the Internet, so if you need to get help, you'll have the easiest time with this.
1. Set up Apache
I don't want to sound like a tool, but setting up Apache (if it's not already set up on your deployment environment) is left as an exercise for the reader. It also varies enough across platforms that I couldn't possible write a catchall guide. Coarsely, use your distribution's package manager (for Ubuntu, this is apt-get) to get it hooked up.
2. Set up Passenger
Passenger installation is even easier. You just run one command, and their guide runs you through all the steps. At this point, in your Rails application root, you'll be able to run passenger start instead of rails s to have Passenger fill the role that WEBrick once did.
3. Hook up Passenger with Apache
The Passenger guide fairly thoroughly documents, step by step, how to set it all up. The ServerName attribute in Apache's VirtualHost entry should be set to your hostname. Passenger will "find" the Rails application from the public directory you give Apache, and when you restart Apache, the first time the server gets a request for a page, Passenger will hook up your Rails application and start serving up files.
I'm not performing these steps as I'm writing this guide, so I'm not sure to what extent this is done automatically, but make sure that the site is enabled via a2ensite (in the case that you're putting this VirtualHost node in the sites-available directory) and that Passenger is enabled via a2enmod.
Make sure your production environment is ready
This is likely to be the first time you're using the production environment. Most rake tasks don't automatically act on the production environment, but you can conveniently force them to by including RAILS_ENV=production inline with any rake tasks. The one you'll very likely be running is rake db:migrate RAILS_ENV=production. The bundler in Rails 3 works independently of environment.
5. Go
Restart Apache. The specifics on how to do this will vary by distribution, so you'll have to look it up. For Ubuntu, apache2ctl restart does it for me.
Visit your hostname as you defined in ServerName, and you should be seeing your application up and running.
I've heard gems like capistrano can assist with this.
https://github.com/capistrano/capistrano
Heroku is an excellent (free) option: http://docs.heroku.com/quickstart
Also, deploying to Heroku is as easy as it gets!
Related
Apologies for these stupid questions (please explain why if you're going to downvote).
I have a site running on a LAMP stack on a Linode Ubuntu VPS and want to learn rails on the remote server without causing disruption to the site currently at mydomain.com.
1) Can I install rails the normal way (as I would on my own PC), and have it not effect the site that is currently up?
2) If a generate an app skeleton after installation, after starting the rails server, how can I navigate the default view?
1) Your test Rails app and the production PHP app can co-exist (hopefully you know your way around Linux) on the same server without interfering with each other. However, I would not recommend this. Bad idea to be trying experimental stuff on production VMs/VPSs. You are better off spooling a test VPS for Rails or better still use VirtualBox VMs on your local machine.
2) Rails apps start on port 3000 by default. So on the VPS, you can reach the Rails app root at http://xxx.xxx.xxx.xxx:3000 (replace the x's with your VPS's IP addr.)
I am using Ruby on Rails 3.0.9 and I would like to publish my web site. I already set my VPS running Ubuntu 10.04 LTS and the capistrano gem (this one I think as well as possible). Now, what I need to do is to upload all files to the www/project_name directory (I am on Mac OS)...
What I have to do to accomplish that?
You don't need your deployment machine to have Capistrano. Capistrano automates a bunch of tasks that I suggest you do at least one manually so you know what's going on. Sooner or later, you'll be debugging some Capistrano task, so you may as well figure out the guts sooner or later.
Coarsely, what you need to do is to basically duplicate your development environment on your production machine. If you have it on version control, you can git clone or svn whateveritis on your production machine. If not, you can scp it over with scp /local/rails/dir remoteuser#remotehost:www/projectname.
At this point, you should actually do the remainder of the work on the server. Since you've managed to install Capistrano, I assume you're familiar with the basics of making your way around SSH.
Once the code's over, you have to install the prerequisites. If you're using 3.0.9 you should be able to run bundle install --deployment, where the deployment flag basically tells bundler to use the identical gem set as on your development machine.
When that's done, actually getting the server online will vary based on your setup. If you're using non-standalone passenger, just follow any of the many guides at this point. If you're running standalone passenger or thin or unicorn or any other standalone rails server, go ahead and start that in daemon mode (so it won't quit on you when you end your SSH session) and make sure you se the production flag. You can either start it in sudo and have it listen on port 80 (e.g., sudo thin start -d -p 80) or have it listen on a higher-number port and use a reverse proxy on your WWW-facing server. The instructions for how to reverse proxy are all over the internet.
Let me know if you have any questions.
You have half of a deployment solution with Capistrano. Commonly Passenger is used as the other half, which sits on the server and loads your app. To accomplish this, usually, SSH keys are used. There are numerous tutorials on how to set this up. One of my favorites written by Dan Benjamin can be found on his blog Hivelogic.
Edited to provide more begginer info:
Capistrano begginer's guide from the Capistrano wiki.
Passenger Stand Alone Guide from the Passenger website.
Be sure to check out the other guides for the webserver of your choice when you're ready.
These guides will give you the background you need to get a local Passenger & Capistrano deployment going. These guides provide the knowledge you need to get achieve what you want.
Simple and short sample of deployment via SSH http://alexeypetrushin.github.com/vfs/ssh_deployment.html
I'm an experienced LAMP developer moving into Rails. I have a very stupid question to ask: what the hell does Phusion Passenger do?
I've read a lot of documentation, I've Googled, I've read Wikipedia, I've read Stack Overflow. I've even installed it and gotten it running on a development machine (with Apache). I still don't know what it's actually doing though.
Here's one guess: I think it's weird that the Apache document root points to /mywebapp/public/ instead of /mywebapp/, so I assume it has to do with making everything inside of /mywebapp/ accessible. (That's a wild guess though, based on the fact that I don't know how else that stuff is getting accessed.)
I've gathered that Passenger is revolutionary, groundbreaking, etc, etc, but what does it do!?
Sorry for the n00b question, everyone. Thanks!
Passenger is a system for preparing and launching instances of Ruby for use with Rack-based applications such as Ruby on Rails. Apache and nginx, the two supported web server platforms, cannot run Ruby like they can PHP, Perl, or Python because there's no built-in Ruby module that works as well as those do. This means Ruby tends to run as an independent group of processes that the web server will have to direct traffic through.
Rails tends to run as a persistent process because the start-up time for the whole stack is significant. Passenger launches new instances as they are required, and will kill off those that are no longer required. You can see this in the process list as they are clearly identified with "Passenger" and "Rails" prefixes.
One feature of Passenger is it will re-use a portion of the Rails stack so that creating additional processes is faster, cloning one instance instead of spinning up a new one from scratch. The loader is written in C++ and handles properly configuring and kicking off each Ruby process as efficiently as possible and also helps save memory by sharing it amongst different processes.
The reason you host things out of the public/ directory is to avoid exposing your application code-base. PHP needs to be configured properly to prevent people from simply browsing directories and downloading the source because there's no specific distinction between static content and executable scripts. A mis-configured server will gladly serve up raw .php files instead of running them, for instance.
Passenger isn't exactly revolutionary, but it does incorporate a number of essential features in a very convenient package. What makes it such a great thing is that it works very well and doesn't demand a lot of attention. Out of the box it's pretty much ready to go.
It serves ruby on rails applications (actually any rack application). I was used with version 2.x of passenger to integrate it directly in apache, but with the new version, which supports standalone execution, I prefer to run it in standalone mode (in conjunction with rvm)
It can be very useful both in development mode and in production mode and it speeds up execution of RoR application.
In order to deploy a RoR application I install it with its own gemset and then I install passenger in that gemset with gem install passenger (you can also safely skip gemsets, but they will isolate the application environment, so it's nice to have them). After that you can start the application with passenger start -a 127.0.0.1 -p 3081 -e production in the project root.
Then I configure an apache vhost to work in reverse proxy mode with a file like this one
<VirtualHost *:80>
ServerName your.server.org
ProxyPass / http://localhost:3081/
ProxyPassReverse / http://localhost:3081/
ProxyRequests Off
# Local reverse proxy authorization override
# Most unix distribution deny proxy by default (ie /etc/apache2/mods-enabled/proxy.conf in Ubuntu)
<Proxy http://localhost:3081/*>
Order deny,allow
Allow from all
</Proxy>
</VirtualHost>
and you're ok, you have your application deployed with its local config, it doesn't even need root privileges (for the passenger part).
We really like the idea of hosting with Amazon EC2 and the excellent EC2 on Rails, but our cashflow isn't enough to justify a move to EC2. So we've decided to host with linode. Now we're trying to put together the best Rails server build.
For those that don't know, EC2 on Rails is an opinionated Ubuntu Linux Server image for Amazon's EC2 hosting service. Out of the box, it runs a standard Ruby on Rails application with little to no customization.
So, is there something like EC2 on Rails for linode?
We'd need at least the following:
Ruby 1.8.7
Ruby on Rails 2.3.8
MySQL 5
memcached
Automatically runs hourly, daily, weekly and monthly scripts if they exist in Rails application’s script directory
Local Postfix SMTP mail server
SSL support
Passenger + Ngnix or Mongrel + Apache
32 bit image Ubuntu
With a railsy setup, meaning fast and simple. So, anyone run across anything like EC2 on Rails, but for linode?
I have been using linode for my personal use for a while and I think no matter what, you are probably going to have to get your hands dirty. I kind of like it for exactly that reason, but that is just my taste. They do have stack scripts with some predefined setups. The closest I can find to what you are looking for is a ruby/apache/mysql script that is fairly customizable.
From the script:
Installs a fully functioning, ready to
go stack that's optimized specifically
for your Linode's resources. By
default, it creates a VirtualHost
using the reverse DNS of your Linode's
primary IP.
This installs a stack based on Ruby,
Apache, and MySQL. This also gives you
the options to install gems so that
you can be up and running Ruby on
Rails in no time.
Optionally creates a MySQL database
and user, and assigns that user grants
to the database.
You may use this as an example for
creating more VirtualHosts. Set up
VirtualHosts, install your sites,
point your domains to your Linode, and
you're set!
This script downloads and compiles the
source from Ruby's ftp. Along with
Ruby, the latest version of ruby gems
is installed and you have a choice of
initial gems to install. Rails and
passenger can be used to have a ready
to go Rails server. Once this script
has finished be sure to run
'passenger-install-apache2-module' to
complete the passenger install.
Note that this script may take 1.5 - 2
hrs depending on the gems that are
specified.
All details of this stack script are
logged to /root/log.txt and the stack
script is finish when the line
"StackScript Finished!" is written to
the log file.
You might have good luck talking to their support though, they might have some more secret sauce that I haven't found yet.
Nothing in that setup sounds EC2-specific beyond the name. It appears it is just convenient to use with EC2, because they let you grab a disk image from another account.
You are welcome to create your own StackScript to do this and contribute it to the community. Once a StackScript is written, it can be marked public and used by others. EC2 on Rails has a public GitHub repository from which you can get started, and honestly, I'd love to see things like this ported to the StackScript system.
I have been creating a website with Ruby on Rails, and will be hosting it through a friend. He has the space and capacity to host the server, and I have a system to devote to being a dedicated server. And this is my first attempt at a Rails website, plus self-hosting with a friend.
I will be formatting and preparing the server today and tomorrow with the following software configuration:
Apache2
Phusion Passenger (aka, mod_rails)
Ruby Enterprise Edition
MySQL 5
I do have a number of questions, and I apologize for their complexity. I haven't found a guide for this configuration yet, and being new to Rails I haven't the experience to navigate my way through this yet.
What build of Linux is most recommended for this configuration?
I have been planning to deploy on CentOS. The caveat is that I have been a Windows user since my early days, and have only used Linux as a webhost and very few development commands (such as CVS). Thus my knowledge of Linux is rather small, and my experience smaller. If I run into any deployment snags, technicalities thanks to the distro of Linux, or anything of the sort ... I'm totally hung out to dry.
This includes things like building anything from source code.
How do I set up Capistrano on my server for remote deployment?
I know this is an oxymoron (Capistrano is client-side, not server-side) but I don't know what it needs on the server. Does it need FTP? SFTP? SSL? SSH? What?
What do I configure on my server, and how do I configure it, to enable Capistrano to run smoothly?
Also, how do I refer Capistrano to the fact that my SCM is on localhost and is by Mercurial? (I used TortoiseMg.) I could convert to SVN and probably set up a repository on the server, but I'm not entirely sure how to do that.
What is the biggest snag you watch for when deploying from a localhost development, to deployment on a totally different OS?
Miscellaneous
Why not deploy to Windows then? Because I'm footing the bill, and I don't want to pay for another copy of XP or possibly 2000; I refuse to use Vista. Plus, Linux is much more secure than Windows for a server environment.
Why not read the existing guides? I am; this is my first site with Ruby on Rails, my budget is in the less than double-digits area now, and I'm trying to expand my horizons by doing the server configuration and the remote deployment (for further development of the site) by myself. I've relied on hosts in the past for my PHP websites, but they're much more homogeneous in their configuration. Ruby servers are expensive, prohibitively so for me, and to learn its configuration wouldn't hurt to know.
What build of Linux is most recommended for this configuration?
Any of the distributions will work fine as long as they can run Apache2 (which is almost all of them) and you can install Passenger (along with ruby and rails).
I personally use CentOS and find its package manger to be ridiculously easy to use (yum).
yum install -y httpd ruby
gem install rails passenger
Then all you have to do is a little configuration in /etc/httpd/conf/httpd.conf to add Passenger (following the install file for Passenger passenger-install-apache2-module) and point it to your deployment folder .../app_name/current/public.
Since you are using Passenger you should override the restart task to work for it.
config/deploy.rb
namespace :deploy do
desc "Restart Application"
task :restart, :roles => :app do
run "touch #{current_path}/tmp/restart.txt"
end
end
How do I set up Capistrano on my server for remote deployment?
All Capistrano needs is SSH access with sufficient permissions to deploy, migrate, restart app server, etc. Just follow the getting started guide at the Capistrano website and you will be up and running in no time.
Capistrano needs access to your SCM, you will need to allow it to connect to your machine. All Capistrano does is checkout your code into a release folder and moves the symbolic link from the old version and restarts your app server.
What is the biggest snag you watch for when deploying from a localhost development, to deployment on a totally different OS?
The biggest snag is with migrations, test, test, test, and test them some more. A bug in your application is easy to fix and redeploy, but a bug in your migration could end up a huge pain in the ass with the possibility of data loss.
I've found the articles posted at Slicehost.com (a VPS hosting company) to be pretty helpful.
The full list of articles are at: http://articles.slicehost.com/sitemap . You'll find a number of articles there related to production deployment of a Ruby on Rails application.
I recommend using Ubuntu server and deprec, as it provides a ton of sysadmin recipes that make things even easier.