I'm deploying a Rails app to production. It seems that Puma is fast and handles many of the things I want in a web server.
I'm wondering if I even need to bother with Nginx, and what I'd be missing out on if just used Puma?
Nginx is a web server and puma is an application server.
Both have their advantages, and you need both.
Some examples:
Static redirects- you could setup your nginx to redirect all http traffic to the same url with https. This way such trivial requests will never hit your app server.
Multipart upload- Nginx is better suited to handle multipart uploads. Nginx will combine all the requests and send it as a single file to puma.
Serving static assets- It is recommended to serve static assets (those in /public/ endpoint in rails) via a webserver without loading your app server.
There are some basic DDoS protections built-in in nginx.
There's a significant difference between a web server and an application server.
Nginx (Web Server) and Puma (App Server) will handle requests in your application simultaneously.
Whenever there's a request coming from a client, it will be received by the nginx and then it will be forwarded to the application server which is Puma over here.
Having nginx as a web server will help you in handling multiple requests much more efficiently. Being a multi threaded server it will distribute requests into multiple threads making your application more faster.
As mentioned by vendant you can serve static pages using a web server as it will be a better approach.
If you're going to include a certification to your web application then you can provide redirects from http to https over here which will hit the app server only after redirecting to https.
If you're going to use Puma then you've to make sure that server is using resources efficiently but if you'll use nginx then it's going to take care of it by itself.
you can get more info here.
Related
I can't seem to figure out if this is common practice or not, but I want to create a website (Running on a container) and then have traffic forwarded to the website from a wildcard on my domain, I want to secure it and use Nginx Proxy Manager and Let's Encrypt to manage the certificate.
Do I keep the website running on my internal server as just HTTP:80 and redirect traffic to to via Nginx? My current site is just a serverside Blazor webapp.
I've seen other people do this, but it makes me wonder if that is indeed secure, at some point between Nginx and the internal server it is not encrypted. Is my understanding correct?
I imagine it looks something like this:
Client connects securely to Nginx Proxy Manager (HTTPS)
Nginx Proxy Manager then decrypts and forwards to the Internal Website (HTTP)
Is my understanding correct?
Is this common practice, or is there a better way to achieve what I want?
A web application that generates dynamic content requires two components:
Web Servers - primarily communicate with clients, by handling HTTP requests and responses while serving content.
Application Servers - on the other hand, generally sit behind a web server. If the web server can not generate the requested content via static files, it then reaches the application server to generate the dynamic content.
Software Examples
Examples of web servers include Nginx and Apache
Examples of app servers include Puma and Unicorn
Web servers and application servers work together as components in typical web applications.
Running Rails in Production
When running a Rails app in production using passenger, some options include:
Running Passenger as a stand alone solution
Running Passenger as an app server and Apache/Nginx as the web server
Running Rails in Development
When running a Rails app in development, it is configured to use Puma by default - see Ruby Docs. Puma is an application server. How is it that by default, in Rails, Puma can run the entire web application on its own? There's no mention of a web server like Nginx or Apache in the application stack.
I don't understand how this is possible. Can someone please explain this? Puma has always been an application server, not a web server...
Thanks in advance.
The distinction between a "web server" and an "application server" is rather muddy and has a lot of implicit (and mostly historical) baggage.
Generally, a web server is understood as a software which communicates via HTTP (or HTTPS) to clients and send static files as a response to requests.
An application server on the other hand often does not communicate directly with clients (but instead with intermediate server systems in front of it, such as loadbalancers, proxy servers or well, web servers) and its main function is to respond to requests with dynamically generated content. Application servers sometimes communicate with those intermediate servers using protocols other than HTTP, such as FCGI or AJP.
Often, we will see classic webservers (such as nginx, Apache, lighttpd) used together with an application server such as Puma, Unicorn, Thin, or Passenger. The reason for that is that those webservers are more efficient in serving static files than the application servers which are more geared towards helping the application generate dynamic responses. Also, web servers might be better suited than application servers for buffering requests and responses from clients without using a lot of resources.
With that being said, in the last couple of decades, it became increasingly common to just use HTTP everywhere rather than to use e.g. FCGI internally. Thus, application servers are generally able to speak to HTTP clients on their own without strictly requiring an additional web server. Often, these application servers can also serve static files directly and thus take on most features of a webserver too.
However, as written above, most webservers are magnitudes faster and more scalable when serving static files. Also, some application servers such as Unicorn are not intended to be exposed to clients directly since Unicorn does not buffer requests and responses efficiently. Instead, they rely on a frontend server such as nginx for that.
Thus, as a conclusion: most Ruby application servers can be used without a webserver directly. With e.g. Puma this will work quite okay. To more efficiently serve static assets, or to loadbalance or protect your application, you can also introduce a webserver / proxy in front of your application server such as nginx or Apache.
We have an RoR application in AWS Beijing. AWS Beijing does not have Route 53 (We can't use Alias to apply ELB to Apex domain), so we must use a Front-end Server running Nginx in front of ELB.
Now our architecture likes below:
Front-end (Nginx) -- ELB --- App-(1~n) (Nginx--Unicorn)
We have noticed the words from Unicorn description below:
"Unicorn must never be exposed to slow clients, as it will never ever use new-fangled things like non-blocking socket I/O, threads, epoll or kqueue. Unicorn must be used with a fully-buffering reverse proxy such as nginx for slow clients."
So my question are:
1. Before Unicorn, do we need nginx on the App Server?
2. If we remove nginx on App Server, can nginx on Front-end Server play such the effect like unicorn describing?
I would recommend replacing the ELB with HAProxy in this scenario where you don't have the alias feature from Route53 to point to your apex domain. Putting a Nginx instance in front of the ELB doesn't seem to be a good idea because you are adding a new layer just because you can't reference the ELB on Route53. You also lose the benefit of high availably by putting a Nginx instance in front of it the ELB.
My suggestion is that you keep one instance of Nginx on each of your app servers in front of Unicorn and use HAProxy as load balancer: HAProxy > [Nginx > Unicorn]. In a simple setup of HAProxy you also don't have the same availability of the ELB but you can setup a high available configuration if needed.
1) Nginx must be always in front Unicorn because Unicorn can't deal with slow clients efficiently, it just locked by those clients
2) Never talk to Unicorn via network, it means each app server need to have its own Nginx. Nginx as Load Balancer is a way better than ELB black box.
I have a rails app running on heroku at, e.g myapp.herokuapp.com.
Now I want to reverse proxy from myapp.heroku.com/proxy/ to somewhereelse.com/ (i.e: myapp.heroku.com/proxy/stuff is reverse proxifed to somewhereelse.com/stuff)
Is that possible on Heroku? How to achieve this?
For anyone coming to this question through a search, this can be done.
Check out https://github.com/ryandotsmith/nginx-buildpack to vendor nginx into your heroku instance. This will place nginx in front of your rails app, and allow you to reverse proxy requests on this domain, having your heroku app configured as apex and allowing somewhereelse.com/stuff go elsewhere.
You dont have access to frontend routing infrastructure so its not possible to do add something like nginx location based reverse proxying or apache's modproxy. From my understanding too you can only bind to one port (the $PORT) within the dyno so its not possible to shadow your Rails app with your own vendored version of nginx (unless it is possible to communicate over a non TCP/IP socket between nginx and your rack/rails app, if this is the case then perhaps you can get rack to listen to /tmp/mysocket.git and nginx to reverse proxy on this, this could be a no starter though, Im just throwing out ideas).
Which means the only probable option if you have to handle this yourself in your rails app, I have only a tiny tiny bit of rails/ruby experience, but if no proxy functionality exists in rails then you perhaps you can explicitly accept the route and then use a http client to invoke the other parts.
I need a recommendation for a rails web server to use for development on windows. I was happy with the default rails server until I had to handle two concurrent requests which it does not support (a page calls an internal rest service). I want to keep the "rails s" experience, so which is the simplest server that support my needs?
To my knowledge, there is no Windows-compatible Rails web server that is multi-threaded or concurrent out of the box.
You will need to spawn multiple back-end servers (we use mongrel, you could use thin instead) and then use/configure a proxy server (we use nginx) in front of them to handle multiple requests concurrently on Windows.
This blog post describes setting up Thin and nginx on Windows, once running you can edit the nginx.conf to proxy to multiple thin instances/ports.