Hi I've been learning rails for the past half year and have a few apps up on Heroku. So for me I thought deploying apps onto the world wide web was just as simple as heroku push. However, I just got my first internship doing Rails and one of my seniors is talking about Apache and Nginx and I'm not sure how they fit in the picture, since I thought apps consisted of only Rails + cloud app platform. I have looked it up but I still don't get how and where it affects my app life cycle. Can someone explain what/where/when of using web servers?
So you've got your Rails app, and as you know you've got controllers and actions and view and what not.
When a user in their browser goes to your app on Heroku, they type in the URL which points to the Heroku servers.
The Heroku servers are web servers that listen to your users that type in the URL and connect them to your Rails application. The rails application does its thing (gets a list of blog posts or whatever) and the server sends this information back to your user's browser.
You've been using a web server the whole time, just it was abstracted away from you and made super simple thanks to Heroku.
So the life cycle is somewhat like this:
Whilst you've been building your applications on your development machine you've probably come across the command rails server. This starts a program called WEBrick which is a web server, and listens on port 3000. You go to your app via http://localhost:3000.
WEBrick listens on port 3000 and responds to requests from users, such as the "hey give me a list of posts" command.
When you push your code into production (in your experience via heroku push) you're sending your code a provider who takes care of the production equivalent of rails server for you.
A production setup (which your senior developers are talking about) is a bit more complex than your local rails server setup on your development machine.
In production you have your Rails server (often things like Unicorn, Passenger) which takes the place of WEBrick.
In a lot of production setups, another server, such as Apache or nginx is also used, and is the server that the user connects to when they go to your application.
This server exists often as a bit of a router to work out how different types of requests should be handled. For instance, requests to static files (css, images, javascript etc) that are storted on the server might just be processed directly by Apache or nginx, since it does a fantastic (and fast) job of sending static assets back to the client.
Other requests, such as "get me a list of all blog posts" get passed onto the Rails server (Unicorn, Passenger etc) who in turn do the required work and send the response to Apache/nginx, who send it back to the client.
Heroku does all this for you in a nice easy to use package, but it sounds like the place your working at manages this themselves, rather than using Heroku. They've setup their own bunch of web servers, and will have their own way doing an equivalent of heroku push which will send the code to the servers, and make sure they're up and running ready to respond to user requests.
Hope that helps!
Web Pages need a Web Server to make them available on the Internet.
So a site that is all static content (all just .html pages) just needs a web server and that's where Apace, nginx, etc come in. They are web servers.
When you use frameworks like rails, an additional component is added, an application server. This pre-processes the pages using the rails framework and then (still) uses the above mentioned web server to make the final pages (which are .html of course) available to the end users through their browser.
Passenger Phusion is an application server that, with rails will help manage and automate the deployment of code.
Heroku is a cloud service, meaning they take care of hardware and software allowing you to seamlessly publish you application without worrying about what is going on behind the scene. So the only thing you have to do is push your code to their Git and voila.
On the other hand, Rails can also be deployed on a system built by you completely from scratch, and you will be the responsible not only for the app development but also for the server maintenance and choice of the hardware and/or software. You could then choose between several application servers capable of running rails such as ngix.
Hope that helps.
Related
I want to add a new project beside of my current rails app without starting a new server for that.
I think it is impossible to have two rails app on one port but my boss want it.
Is it possible at all?
Yes it's possible if you configure a web server (nginx, etc) as a reverse proxy to listen on the port you want, and have it forward traffic to the correct app based on subdomain.
Yes and no. You can't run two web servers, e.g. Puma, on the same port. That won't work. But you can run one web server to serve two Rails apps. Incoming requests are routed based on either their subdomain (app1.example.com) or their path (example.com/app1).
A common setup is to use Apache/nginx as the web server in combination with Passenger as the application server. This question ask a similar question and points to Passenger's documentation on how to serve apps from subdomains: How to deploy multiple rails app on a single IP (Apache + Passenger)?
The configuration depends heavily on your setup, so I can't give you a more detailed answer. But searching for "multiple apps" and the combination of your web and application server should yield enough results and tutorials for you to solve your problem.
Best practice for Scalable project on ruby on rails. Problem: I don't understand the difference between web and app server in ror projects.
I understood that the differences between application and web servers are webserver handles requests and application has business logic. However I don't quite understand how I can implement it in my ruby on rails application.
So, I have, for example, two instances and ruby on rails application.
On the first server I want to set up a web server, and on the second one I want to install application server.
But, for example, I use passengers as my webserver that makes easier to deploy my ror application. So, will I have any benefits implementing such logic? Can I use passenger as an cache server or something like this? Is it possible to put passenger on another server and send request to ror application? Or I totally wrong and don't understand the conception?
Note: I just found amazon web application hosting architecture and now I'm trying to figure out how I can it implement and how it could work.
Use heroku with puma. That's the easiest to setup.
http://www.justinweiss.com/articles/a-web-server-vs-an-app-server/
https://www.nateberkopec.com/2015/07/29/scaling-ruby-apps-to-1000-rpm.html
https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server
I am going to be deploying about a dozen rails apps on an IIS server. These apps are behind out firewall for internal use only. They will all be low usage but critical apps.
The current setup is
IIS running on server 2012
Rails 4 is running on iis installed via the webplatforminstaller.
We will be using MS sql server
Apps uploaded from the laptop to the server do run.
There will be about 15 apps running. We can add another server if necessary.
Nothing else will be running on that server
E.g. an app might be located in c:\inetpub\wwwroot\apps\sales and another in \hr. etc.
What I've read about deploying multiple rails apps seems to be geared toward public facing sites. I don't see much about private sites using a server ip/folder setup
Question:
- Can multiple apps be run without adding a tool such as passenger?
It is possible using the IIS HttpPlatformHandler extension. Scott Hanselman did a good write up on it that explains how to use it.
Although, in that blog post it's suggested to use JRuby and Tomcat. I don't think that is necessary, however I would suggest using puma as your webserver.
I'm developing a web application with an AngularJS frontend and a Rails backend.
My goal is to keep the two entirely separate, since the Rails app will ultimately be relegated to a simple REST server, and the AngularJS frontend will be just one of a few different clients that use the backend. For that reason, I don't want to integrate the frontend into the Rails asset pipeline, or similar.
The Rails app is running locally on port 3000. The frontend uses Gulp to compile static assets, and BrowserSync, which contains a development server that I'm running on port 3001.
For development purposes, how can I get the AngularJS app to talk to the Rails server, avoiding this browser error (which I'd expected) when making HTTP request via Angular's $http service?
No 'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'http://localhost:3001' is therefore not allowed access.
Do I just need to set up CORS in the Rails app? Is there another way - maybe some sort of local hosts file trick (I'm on a Mac, FWIW) or similar? I ask because my coworker is responsible for the Rails app (I have limited experience with Rails) but is out of town for a while; my knowledge is mostly limited to the AngularJS stack that I've set up.
I've searched and read up for about an hour, but haven't yet been able to find anything that I can grok that is applicable to my situation. I might not be aware of the best search terms.
Thanks for any help!
Ah, wonderful. Here are a few solutions:
set up CORS, which shouldn't be too hard. All you have to do is add the headers to pages serving your static content (not the rails REST endpoints), The problem with this is you shouldn't really be doing it unless you have a good reason (so see 3). How are you serving the static content? There should be plugins to do the headers for you if it's a popular tool
serve the angularJS pages from the rails backend for now (using some kind of static route)
if you're thinking about production and want to sort this out for good, use nginx to proxy the two services into one single domain, http://nginx.org/en/docs/beginners_guide.html
This is a newbie question around nginx and thin in the rails environment. In reading/learning on rails I frequently hear about nginx and thin being a great combination for a rails site. In reading the descriptions of each, they both describe themselves as web servers, so I'm a little confused at what the combination brings to the table. If anyone could briefly describe what they are and how they complement each other I would be greatly appreciative.
Thanks!
A typical small application deployment will have Nginx(or Apache) and a handful of Thin(or Mongrel, Unicorn, etc) servers running all on one machine.
Nginx receives every request. It then serves and static files directly (css, js, images, cached stuff). If the request requires processing it then hands the request off to a rails process (Thin).
This way your (relatively) slow application servers are freed up from serving static files, and your web server is providing a sort of load balancing.
The benefit of Nginx/Thin over something like Apache/Mongrel is that Nginx/Thin can communicate directly via a unix socket, removing the overhead of communicating via the tcp/ip stack.
Thin is an application server while Nginx is a web server.
From http://www.javaworld.com/javaqa/2002-08/01-qa-0823-appvswebserver.html
The application server exposes business logic to client applications through various protocols, possibly including HTTP. While a Web server mainly deals with sending HTML for display in a Web browser, an application server provides access to business logic for use by client application programs. The application program can use this logic just as it would call a method on an object (or a function in the procedural world).
Speaking out of ignorance (I've never used Thin), it is quite normal to mix nginx and an application server together, using nginx to serve up static content and act as a reverse proxy for the application server.
This makes it easy to blend ludicrously fast static content serving with the application server of choice (which varies between programming languages), all coming from the same address:port.