I have a love-hate relationship with nginx. I love that it's fast and rock solid. But recently I keep on getting tripped up when the directive I'm trying to configure is only available in the paid plan, the pricing of which puts it out of (my) reach.
Also, there really should be separate docs for the open source vs paid plan.
That said, I do plan on kicking the tires on the HTTP/2 support.
> the directive I'm trying to configure is only available in the paid plan
Sadly, this is how the developers of nginx can earn and continue to make good software. Some of the new features in this release has been directly supported by the commercial edition, and some has been open sourced after being made for the commercial edition because clients demanded them.
Also, the nginx team is open to a feature being sponsored by a third-party, non-client in order to add it to the open source edition. Some of the significant features in nginx have been built this way (http/2, spdy, websocket support etc.)
If nothing, even patching or writing modules for nginx is not that hard (assuming you know how to develop, and in C). It is one of the more well-designed codebases. (Some others are: Redis, Postgres, Git).
> there really should be separate docs for the open source vs paid plan
I thought nginx.org contained only open-source info, save for an occasional ad about the paid offering. Is there any documentation on nginx.org that doesn't apply to the open source edition?
Note that accepting HTTP/2 connections over TLS requires the “Application-Layer Protocol Negotiation” (ALPN) TLS extension support, which is available only since OpenSSL version 1.0.2. Using the “Next Protocol Negotiation” (NPN) TLS extension for this purpose (available since OpenSSL version 1.0.1) is not guaranteed.
I've manually compiled and tested HTTP2 support on 14.04 LTS (OpenSSL 1.0.1f) for the past few months and it's worked fine. I wish they had elaborated on "is not guaranteed".
Nginx is annoyingly complicated in a microservices environment.
IP addresses of upstream servers change, and sometimes DNS doesn't resolve until another service is brought up. Nginx does not work well in such an environment unless you (1) have ugly configuration hacks, (2) add OpenResty/LUA to your configuration, (3) add a watchdog process, or (4) buy their nginx Plus version and keep track of how many instances of nginx you have.
I want simple. If you need a webserver that can use DNS, Nginx is a lot of extra work.
I use it just fine in my Kubernetes deployment. Nginx resolves via DNS to the microservices I run, without having to do complicated configuration hacks.
Doesn't look like anything that would be useful in a web server and load balancing of UDP is different than TCP. Layer 3 load balancing (e.g. LVS) would probably be more suitable.
Dynamic modules will be the best thing since sliced bread. I have wanted to use a StatsD plugin for metrics but having to manually compile has kept me from doing so for 2 years. I don't want that technical debt sticking around.
Feels like feature creep. What would you use UDP load balancing for? Layer 3 load balancing is probably the best approach for load balancing UDP traffic.
Edit: If you have to downvote, go ahead, but at least state why you don't agree, so I can know why I'm wrong and can revise my opinion.
[+] [-] emgee3|10 years ago|reply
Also, there really should be separate docs for the open source vs paid plan.
That said, I do plan on kicking the tires on the HTTP/2 support.
[+] [-] pritambaral|10 years ago|reply
Sadly, this is how the developers of nginx can earn and continue to make good software. Some of the new features in this release has been directly supported by the commercial edition, and some has been open sourced after being made for the commercial edition because clients demanded them.
Also, the nginx team is open to a feature being sponsored by a third-party, non-client in order to add it to the open source edition. Some of the significant features in nginx have been built this way (http/2, spdy, websocket support etc.)
If nothing, even patching or writing modules for nginx is not that hard (assuming you know how to develop, and in C). It is one of the more well-designed codebases. (Some others are: Redis, Postgres, Git).
> there really should be separate docs for the open source vs paid plan
I thought nginx.org contained only open-source info, save for an occasional ad about the paid offering. Is there any documentation on nginx.org that doesn't apply to the open source edition?
[+] [-] dchest|10 years ago|reply
http://nginx.org/en/docs/http/ngx_http_v2_module.html
Hmm, so Ubuntu 14.04 LTS won't support it (ships OpenSSL 1.0.1f), need to upgrade to 16.04.
[+] [-] jzelinskie|10 years ago|reply
[+] [-] pritambaral|10 years ago|reply
[+] [-] DanielDent|10 years ago|reply
IP addresses of upstream servers change, and sometimes DNS doesn't resolve until another service is brought up. Nginx does not work well in such an environment unless you (1) have ugly configuration hacks, (2) add OpenResty/LUA to your configuration, (3) add a watchdog process, or (4) buy their nginx Plus version and keep track of how many instances of nginx you have.
I want simple. If you need a webserver that can use DNS, Nginx is a lot of extra work.
[+] [-] HorizonXP|10 years ago|reply
Would something like that work for you?
[+] [-] pritambaral|10 years ago|reply
1. Fix of the repeated-tries of non-idempotent requests bug.
2. Dynamic modules.
3. HTTP/2!!
4. reuseport in listen.
5. SSLv3 disabled by default.
6. UDP Load Balancing.
[+] [-] takeda|10 years ago|reply
Isn't that just a feature creep?
Doesn't look like anything that would be useful in a web server and load balancing of UDP is different than TCP. Layer 3 load balancing (e.g. LVS) would probably be more suitable.
[+] [-] tomschlick|10 years ago|reply
[+] [-] toomanythings2|10 years ago|reply
[+] [-] Thaxll|10 years ago|reply
[+] [-] takeda|10 years ago|reply
Edit: If you have to downvote, go ahead, but at least state why you don't agree, so I can know why I'm wrong and can revise my opinion.