当前位置: 动力学知识库 > 问答 > 编程问答 >

ruby on rails - What is the best practice for Nginx/ELB/Unicorn architecture on AWS?

问题描述:

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.

分享给朋友:
您可能感兴趣的文章:
随机阅读: