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.
Related
I'm using Puma (version 3.11.0) as the web server for a Rails application (Rails version 5.1.4). I need the whole application to be SSL encrypted, but I need one particular route to also have the SSL "verify_mode" set to peer. In Apache, I would normally use a "Location" or "LocationMatch" block to configure the SSL options differently from the rest of the site.
How can I do the same thing with Puma?
I totally agree with #user3309314.
Exposing Puma to the internet directly (or exposing any application server, for that matter), isn't a great idea.
Web servers (unlike application servers) are designed to be in the front, protecting application servers from the cruel world...
...and along the way, they should be the ones to handle SSL/TLS (along with DoS attacks and other annoying concerns).
So use nginx or apache to forward requests to your Ruby application(s) and if you need a special TLS/SSL rule for a specific path, do that with nginx or apache.
Puma doesn't (and IMHO shouldn't) support the feature you're asking about.
EDIT (some of the information given in the comments + explanations)
It's best to think of application servers as a "bridge" between the host machine's routing layer (nginx/apache) and the applications.
It's the host routing layer (nginx/apache) that filters and routes certain host names and paths to certain applications (or the same application with different headers / variables / requirements).
The application server's job is to simply "bridge" between the host routing layer and the actual application, translating between the different data formats (HTTP data to Ruby objects and back).
In order to support the feature you're asking about, the application server should perform the same functions as the host routing layer (routing the correct host name / path to the correct application with the correct changes)
This would violate any "separation of concerns" as well as add redundancy to the system, inflicting a performance penalty (not to mention the larger code base that duplicates the same task in different modules).
This is the reason why, IMHO, these features should not get coded into Ruby application servers.
It's unlikely that Puma supports this.
But you can configure Nginx or Apache as a reverse proxy, so requests get forwarded to the Puma application server, and you can configure SSL options as you need.
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
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.
I have different websites/applications built with rails, which has different domain names. The thing is I want to serve them from a server with Nginx/passenger. I tried some techniques, but I cannot make them work, basically, I have very few information about this.
So, I can serve different websites/applications on different ports. But how can I make people to see application "AAA" if they are coming from aaa.com and see application "BBB" if they are coming from bbb.com?
Phusion Passenger's documentation has a passage on this here, section 3.2: http://www.modrails.com/documentation/Users%20guide%20Nginx.html
Basically, you can set up virtual hosts that point to different applications on the same web server/app server pair.
You can also do rewrites or forwarding purely through nginx configuration, if the above doesn't work.
I would like to have multiple RoR applications that can communicate with each other (databases, method calls, ...).
Example of what I would like:
a main application running on a URL http:// www.< application_name >.com
a sub-application 1 running on a URL http:// www.< application1_name >.< application_name >.com
a sub-application 2 running on a URL http:// www.< application2_name >.< application_name >.com
each with own databases.
How can I configure my applications? Where can I find a tutorial for my needs?
No Problem. In your case you will have 3 distinct Rails applications. You will setup your Webserver to send requests based on host accessed to one of the three applications. This is standard web server configuration. You'll need to read Apache or Nginx configuration on how to route request to the right rails application.
EDIT:
http://articles.slicehost.com/2009/3/11/ubuntu-intrepid-nginx-rails-and-mongrels
Not sure what you are going to use as your Web Server (Apache or Nginx or something else) or what you are going use as your application container (mongrel/passenger/thin etc) but this article above should help.
You might take a look at the eco_apps gem - https://github.com/idapted/eco_apps. I heard the developers give a talk about it at Rails Conf '10. Fascinating stuff, though I haven't had a chance to use it yet.