Most setups use a combination of rack servers and traditional web servers such as unicorn and nginx to get the best of both capabilities. Unicorn is capable of balancing inbound requests to Ruby for processing and nginx is incredibly fast at redirecting requests by serving up static content and using proxy balancing.
You can take a Ruby course here at Udemy entitled “Ruby Programming for Beginners.” No matter how you look at it, having both systems together lets you accomplish so much more when you have both set-ups running together. As a matter of fact, this article on creating local web servers might be something you might want to check out.
Nginx is a high performance reverse proxy web server that is easy to work with and is extremely lightweight. It is capable of handling virtually unlimited requests, which could be hard to tackle when you are using older alternatives. Nginx is designed to act as a front-facing, multi-purpose web server from the ground up.
It has the capability of serving text files, image files and other static files very well, deals with certain exploit attempts and balances connections. For every request, it acts as the first entry point and then for the process of web application and to get a response, it passes them to Unicorn.
Unicorn is a Ruby Unix HTTP web application server, which you can learn more about by taking this course on Ruby. It is fully featured and mature by design. It does not attempt to do everything and makes great use of Unix. The objective of Unicorn is to do what is necessary using the web server application and delegating everything else.
Just like nginx, Unicorn is able to deploy and run applications without dropping live clients and connections. Some of its more advanced features include the ability to listen to different interfaces, the ability to be used with copy-on-write friendly management of memory for saving space, the hooks after_fork and before_fork for dealing with a forked process and serving one request at a time as every worker runs within an isolated given address space.
According to the requirements, the master process of Unicorn spawns workers to accomplish the requests. In order to process related staggering issues and monitor the workers, the process also monitors workers. For system administrators, this means that it may interrupt a process, due to memory issues or too much time completing tasks.
One area where tasks are delegated by Unicorn is when using load balancing operating systems. This prevents requests from piling up against the spawned busy workers.
Deployment Server Preparation
To prepare the deployment server, you will need to get the operating system updated, get the needed basic tools for deployment, install libraries, Rails and Ruby and Install both the nginx HTTP server and the unicorn application.
The OS kernel does load balancing between worker processes. Every worker shares a common listener socket and does non-block accept on these. The kernel decides which worker processes to give sockets to and the ones that have nothing to accept will sleep. Normally, a load balancer reverses proxies to the workers that are most receptive based on the last requests sent to these workers. There are a few issues with this method as software sometimes fails and it takes longer to complete some requests.
A shared Unix socket is used by Unicorn. When workers are not serving requests currently, it fights the other workers to accept connections and it listens on the Unix socket. ‘Push balancing’ is the term for this.
Setting Up Nginx In Front of Unicorn
When setting up nginx with Unicorn, you can begin by getting nginx installed through your preferred package managers. You will need to get this configured for Unicorn afterwards. The nginx file configuration is found at:
/etc / nginx/ nginx. conf
Tweak this to your liking after you put it there. You might also stumble upon the lines ‘usernobody nogroup in the nginx.conf.
It is better to run a separate user even if this works, just for increased control and security reasons. Find out more about writing secure code by taking this course on PHP security. You can create a web group and nginx users:
Go to nginx.conf. to / var/ www, and configure your static path and tweak the directory owner to the website group:
To be able to modify the /var/www contents, start adding yourself to the website group:
$ sudousermod-a-G webUSERNAME
Now that you are running nginx, you can get the Unicorn gem installed:
For non-rails rack applications, you should now have ‘unicorn’ and ‘unicorn-rails’ installed for the Rails version application should now both be in your path.
There you go, lets fetch the config file of Unicorn in your Unicorn Rails test app. Begin in the configuration examples that ship with the source of Unicorn:
To set the right paths, you might want to change a some code:
Now you can start nginx before starting unicorn:
Getting an Error Message
When you get an error message, this means that the package you are using is not updated. What you need to do is download the package list by running $ apt-get updates from the source and update these to get the latest package and the newest information.
There are a number of ways you can configure Unicorn. To do this, open a blank document unicorn.rb which will be saved inside the directory config/
Next, place this block of code and make modifications where needed:
Exit after saving by clicking ctrl + x and then clicking Y.
Telling Nginx How to Talk to Unicorn
The next step is to tall nginx how to communicate. To do this, type:
Replace the contents of the file with the ones here, amending the needed bits according to your needs:
There you have it, nginx and Unicorn operating together in one system. You can learn more about this type of programming by taking this Ruby course.