I have an application, that is becoming big, but until now, its not giving me a good revenue. That means, short money to re-invest on that. In this scenario, i found a way to make a "cheap distributed rails" deployment.
I've got 4 VPS. All of them are in the same physical server. I added a load balance server running HAproxy in one dedicated VPS. There i pointed my virtual ip address where my domain name is associated. Behind this HAproxy i have more two VPS running my rails APP, passenger and memcache. Both apps servers are looking to the same database server, my 4th VPS. So with $44/month, i mounted a distributed environment. It won't be my final choice, but now, that the budget is short, is that a good way to deploy a rails application? Any pros or cons? It worth my $44/month?
It may be more efficient to increase the resources on a single VPS and tune passenger to handle more memory and concurrent Rails instances.
Related
I'm new to web development, and have a question about deploy ruby on rails application.
For what i'm understanding, there are two ways to deploy. One is using cloud server like Heroku (I'm currently using). You just need to upload your project to their cloud server and ready to go.
Another way is build your own server using, for example, apache+passenger. By doing this way, I need to have a physical computer with Ubuntu + Apache + Passenger running continually right?
So my question is which way is better, faster?
Heroku has a form of automated deployment built-in. There are other cloud-based providers which offer a similar sort of service.
The alternative is self-hosted. You don't need a "physical computer", you can use a virtualized server in the cloud just the same. Popular choices are Linode, Digital Ocean and Amazon EC2 which is what Heroku is based on.
"Better" is highly subjective. Do you know how to maintain a server? If the answer to this question is "No", then Heroku is probably the best bet.
If you do know how to maintain a server, you can usually get better performance from your own rig since you have full control over how your application is launched, how long it stays running, and can increase resources at marginal additional cost. The downside is you're responsible for everything should it malfunction.
I want to reduce my server cost by virtually hosting many RoR development applications servers on a single machine, with the databases hosted elsewhere. Each application uses a lot of memory when it's fully loaded, so my concern is that this won't scale well.
So my question -- for any passenger phusion experts out there -- is will passenger keep one fully loaded instance of itself in memory for each application, regardless of how long it's been since that application has been used? If so, is there any way to tell phusion to swap out the least recently used host when necessary to conserve memory?
Usage pattern: I don't expect more than one or two of these applications to be in active use at once, and I don't mind if it takes a long time to load the page initially, as long as it's snappy on subsequent page loads (since these are dev instances).
Here's a spec of my current setup:
-Ruby Enterprise Edition 1.8.7, with copy-on-write enabled
-Rails 2.3.18 (I know it's old school...)
-Passenger 3.0.11
-AWS EC2 for application hosting
-AWS RDS for DB hosting
Any advice on how I can do this in a memory efficient fashion would be highly appreciated.
Phusion Pasenger already shuts down processes to conserve memory by default. See these configuration options:
http://modrails.com/documentation/Users%20guide%20Nginx.html#PassengerMaxPoolSize
http://modrails.com/documentation/Users%20guide%20Nginx.html#PassengerMinInstances
http://modrails.com/documentation/Users%20guide%20Nginx.html#PassengerPoolIdleTime
I'm a web developer just now getting interested in sysadmin stuff. I've set up a server before on Linode.com (Ubuntu 10.04 LTS, nginx, Ruby on Rails, PostgreSQL), but there were some issues. Everything was on one machine, so whenever something went wrong with Linode or I got a lot of traffic, my site would go down.
Now I'm interested in setting up a personal blog, and deploying it across Amazon AWS. This is a good opportunity for me to learn to how to use multiple servers with load balancing, auto-scaling, failover, etc. The only problem is I'm not quite sure where to start.
I've read a litany of documentation from Amazon and blog posts elsewhere, but as a sysadmin newbie I have a few questions:
I get that EC2 instances are too volatile to store data on. So where should I store it? Amazon Elastic Block Store? Will the entire filesystem go there, as well as the database?
Do I need serious knowledge of load balancing and scaling? Or will the Amazon Elastic Load Balancer handle make things simple for me? How does their load balancer interact with nginx?
How much of this do you recommend doing through the AWS interface as opposed to through the command line?
Any non-obvious snags that might catch me?
Are there any tutorials for deploying a blog or simple Rails app on EC2? I don't need a production-quality setup here; my main goal is to learn.
Thanks for any answers you can provide!
I've set up my fair share of AWS deployments; here's basics:
Data store
If you have frequently accessed data, as you likely know, it is best to use a database. This is one of the hairier parts of AWS hosting. Your options are, roughly in increasing order of complexity/cost:
SimpleDB - Amazon's own database offering. They give you an HTTP api, which you use to read and write your data. There are some rails libraries for it, but on the whole, it isn't a graceful drop-in for rails.
Amazon RDS - Amazon will preconfigure a mysql-like database server for you. This requires you to boot up an DB server instance, so the pricing server isn't favorable for tiny sites. On the plus side, it allows you to scale your DB server more easily.
Roll your own - Plan around Amazon EC2 instances vanishing at any point; therefore, the local storage you get with EC2 instances can best be considered a big temp directory. Elastic Block Store is Amazon's solution to this; it effectively is a disk image your instances mount. EBS images live independently of EC2 instances, so if your server goes down, you can mount the EBS image on a new EC2 instance. You can essentially roll your own database cluster by booting a bunch of instances and configuring them to replicate off eachother. This works, but is not graceful, and should really only be attempted if you cannot solve your problem with less exotic methods.
Amazon pretty much enumerates these options, plus a few more which are not applicable to you at http://aws.amazon.com/running_databases/
Infrequently changed data should be stored in S3; there's plenty of ruby gems for accessing this easily. If your website is entirely static on the server side, you can even run your entire site off S3
Load Balancing
Amazon "Elastic Load Balancing" is quite effective at the typical web load balancing requirements. It is usually a no-brainer choice, unless you have exotic requirements. It will not scale your cluster for you, however. For auto-booting and shutting down of instances, you should look to Amazon's own auto-scaling solution
Caveats
Be sure to note which "Availability Zone" (aka datacenter) you're in. In some cases, you cannot share AWS resources across availability zones.
Tutorials
There are plenty of tutorials, but in my brief search, none that I found to be really great or up to date. However, check out https://github.com/wr0ngway/rubber , which is a ruby tool for deploying apps to EC2. It will get you most of the way there.
How can I go about deploying a Rails app on a cluster of Amazon EC2 servers? Any recommended guides?
I maintain a RoR app (currently hosted on Heroku) that uses a DB and DelayedJobs). The app has a large footprint, and needs to be distributed on a cluster most likely. Any tips would be appreciated. Are there Amazon AMIs that replicate some of Heroku's features (especially DJ)?
P.S. I'm quite a Ruby newbie.
Any reason it can't stay on Heroku? You can scale Heroku dynos and workers as you see fit, and can upgrade to a dedicated database instance if it really needs it.
I would use a clean (ebs-based) AMI from Alestic or Amazon and configure it myself. It's very difficult to find an appropriate AMI (or several for web-server, app-server, DB-server and make them work together) and a high risk to trust it.
Very soon I plan on deploying my first Ruby on Rails application to a production environment and I've even picked a webhost with all the managed server and Capistrano goodness you'd expect from a RoR provider.
The provider allows for Mongrel, Thin, Passenger & FastCGI web servers, which seems very flexible, but I honestly don't know the differences between them. I have looked into them some, but it all gets a bit much when they start talking about features and maximum simultaneous requests - and that this data seems to vary depending on who's publishing it.
I have looked at Passenger (on the surface) - which does seem very appealing to me - but I was under the impression that Passenger wasn't the actual webserver, and instead was more like a layer on top of Apache or nginx and managed spawned instances of the application (like a Mongrel cluster).
Can anyone please set me straight with the differences in layman's terms so as I can choose wisely (because anyone who's seen Indiana Jones and the Last Crusade knows what happens if you choose poorly).
Short answer
Go with Apache/Nginx + Passenger. Passenger is fast, reliable, easy to configure and deploy. Passenger has been adopted by a large number of big Rails applications, including Shopify.
(source: modrails.com)
The long answer
Forget about CGI and FastCGI. In the beginning there were no other alternatives so the only way to run Rails was using CGI or the faster browser FastCGI. Nowadays almost nobody runs Rails under CGI. The latest Rails versions no longer provides .cgi and .fcgi runners.
Mongrel has been a largely adopted solution, the best replacement for CGI and FCGI. Many sites still use Mongrel and Mongrel cluster, however Mongrel project is almost dead and many projects already moved to other solutions (mostly Passenger).
Also, a Mongrel based architecture is quite hard to configure because it needs a frontend proxy (thin, ngnix) and a backend architecture composed of multiple Mongrel instances.
Passenger has been gaining widespread attention since it was released. Many projects switched from Mongrel to Passenger for many reasons, including (but not limited to) easy deployment, maintainability and performance. Additionally, Passenger is now available for both Apache and Ngnix.
The simplest way to use Passenger is the Apache + Passenger configuration. One Apache installation and multiple Passenger processes.
If you need better performance and scalability, you can use Ngnix as a frontend proxy and forward all Rails requests to multiple backend servers, each one composed of Apache + Passenger.
I'm not going into the technical details here, this solution is intended to be used by Rails projects with an high level of traffic.
Even more complex solutions include a combination of different levels including http proxies and servers. You can have an idea of what I'm talking about reading some internal details from GitHub and Heroku.
Right now, Passenger is the best answer for most Rails projects.
Mongrel and Thin are single ruby process servers that you would run multiple of as a cluster behind some type of proxy (like Apache or Nginx). The proxy would manage which instance of Mongrel or Thin services the requests.
Passenger creates an interface between Apache or Nginx that creates an application spawning process and then forks out processes to server up incoming requests as they come in. There are a lot of configuration options for how long those processes live, how many there can be, and how many requests they will serve before they die. This is by far the most common way to scale up and handle a high traffic application, but it is not without drawbacks. This can only be done on a *nix operating system (linux, mac os x, etc). Also, these processes spin up on demand, so if no one accesses your site for a while, they processes die and the next request has the delay of it starting back up again. With Mongrel and Thin, the process is always running. Sometimes though, your processes being new and fresh can be a good thing for memory usage etc.
If it is going to be a relatively low traffic site, Mongrel or Thin provides a simple, easy to manage way to deploy the application. For higher traffic sites where you need the smart queuing and process management of something like Passenger, it is a very good solution.
As for fastcgi, you probably want to use that as a last option.
I use Passenger + nginx. It works really, really well.
To get some instant performance boast with passenger, I recommend using ruby enterprise edition.