Is there a way to package my rails application as an appliance on a virtual machine that has a database already setup in postgres? When such appliance is run, it should simply run the rails application and be ready for use.
I don't see any obstacles for that, you just have to configure database connection URL to Postgres upfront through env var at VM, so Rails (ActiveRecord) will pick up it during launch.
But if you require packing consider to look at containers, particularly Docker.
Related
I have a rails application that is currently hosted on Heroku. It is used on our local network only, and my boss does not want a 3rd party hosting our data. I convinced IT to set me up a virtual windows server to deploy my app on. However, it has been very difficult to set up for production.
Is there anyway that I can use a hosting service for my application, but have the database reside on our local network?
Or is there an easier way to deploy a rails app on a windows server? I have been looking into using the Linux Subsystem for Windows.
If your app is used on your local network only, why not ditch Heroku and host your Rails app locally as well? What benefit is a scalable cloud hosting provider giving you? Especially since it seems your boss has security concerns about remote hosting of a database. Bringing the entire thing in house may be the best solution.
Simple answer is yes you can, but why would you. It's simpler to run your application locally than connecting your remote app to a local database.
Your best bet is to use a Linux virtual machine instead of Windows, usually there is to much hassle to get rails application to work on windows, especially compiling native gems.
I suggest that you get a CentOS VM, and install Nginx with passenger gem using rbenv or rvm.
Digital Ocean has a nice guide that explains this process in details:
How To Deploy Rails Apps Using Passenger With Nginx on CentOS 6.5
AWS has just announced general availability of its EFS (Elastic File System). It allows you to create a network drive that can be shared by multiple AWS instances.
I have a Rails application, using sunspot-solr gem. A solr folder is created to store the solr index file and other related data.
The MySQL data is on its own RDS instance. I want to deploy two servers, both running the same Rails application, but have them both point to the same solr folder on the shared EFS share.
Assuming that both servers running the Rails app, are using the same solr gem version, will my scenario work, or will each server need its own solr folder?
I'm pretty sure the version of Solr packed with the development version of Sunspot is a separate Solr server that Rails communicates with. So in production, you are responsible for providing a Solr server for these purposes, be it on one of your EC2 instances or on its own separate EC2 instance.
A little more info... Rails posts data for Solr to consume via Sunspot, but the Solr server handles those details, not your Ruby app. Therefore, sharing the Solr data files with Rails won't provide you with any advantage.
When I was getting started, I hooked my Heroku-hosted Rails app up to Websolr if you think that $20+ per month would be worth it. Otherwise, look up tips for installing Solr on EC2.
I am looking to create a shared hosting environment allowing for multiple RoR apps to be running well isolated from one another (and the underlying os), running different versions of RoR as required.
My question is can this be done without having to resort to OpenVZ/Virtualisation?
If so, would the following approach be suitable - what would be required to make apps well isolated from each other and the OS?
NGinx, single instance for load balancing
Unicorn, multiple instances started by NGinx to handle requests (capable of running different versions of RoR
(Rbenv or RVM) and Bundler allow to isolate gems of different Rails applications.
So there will be no troubles with that.
Each rails app will have its own instance of Unicorn(puma, thin, whatever).
Nginx will have separate domain name based virtual host for each rails app, and will forward requests to upstream(Unicorn/Puma).
Each rails app should have separate database at db server too.
So I don't see any problems with isolating multiple rails apps.
For additional isolation you can use Docker, so each app will be running in separate container.
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!
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.