One note with the “Passing request to Consul services” section: when you use a DNS name in proxy_pass, that name is only ever resolved at startup. If the IP address the domain name points to could ever change you should define an upstream. Nginx only does normal DNS TTL / refresh in upstreams.
It does, but proxy_pass doesn’t use DNS TTL, it only ever resolves once, unless you use a variable or an upstream. The Nginx docs aren’t very clear, but the resolver setting says it’s used for upstreams.
For me, one of the biggest sells of OpenResty is ngx_lua/OpenResty. All those times when you’d notmally have to add an additional API layer or cloud functions because you want to do something like protect an API key or something, you could just do by adding a short circuit route in nginx. Or stuff like contact forms on static sites. I imagine you could do some of that with HAProxy’s Lua scripting, but the ecosystem around OpenResty is faily well built out for a lot of the stuff you’d need.
I remember when nginx was first starting to take developer mindshare from Apache. Part of the allure was config simplicity. All the nginx defaults were modern and up to date, whereas Apache needed tons of boilerplate to enable modern behavior and tune performance. Nowadays nginx has been around for a long time. It’s not as bad as Apache was, but you still need to comb through tons of settings to get an ideal config.
Caddy doesn’t have that problem. TLS through Let’s Encrypt by default. HTTP/2 by default. The Caddyfile config has options for functionality, no miscellaneous knobs or flags that need tuning. You can do the development basics without config files at all using the caddy file-server and caddy reverse-proxy subcommands.
When you need more, Caddy has optional modules you can build in, including a full blown auth portal implementing Form-Based, Basic, Local, LDAP, OpenID Connect, OAuth 2.0, and SAML Authentication.
One note with the “Passing request to Consul services” section: when you use a DNS name in
proxy_pass, that name is only ever resolved at startup. If the IP address the domain name points to could ever change you should define anupstream. Nginx only does normal DNS TTL / refresh in upstreams.This is rarely mentioned and you learn it the hard way. @alexdzyoba I think it’s a good thing to add to your great article :)
I have previously documented a workaround for this (although, really the open source version should just support this): https://tenzer.dk/nginx-with-dynamic-upstreams/.
Ah yes, I had seen the variable hack once before! Both the variable hack and upstreams need the resolver set, so both will do the trick.
Thanks, everyone! I’ve updated my post. Put the link to this thread and the post by Tenzer.
Thanks for pointing out! But what about “valid” option in resolver directive? It should control the TTL for DNS cache.
It does, but
proxy_passdoesn’t use DNS TTL, it only ever resolves once, unless you use a variable or an upstream. The Nginx docs aren’t very clear, but theresolversetting says it’s used for upstreams.For me, one of the biggest sells of OpenResty is ngx_lua/OpenResty. All those times when you’d notmally have to add an additional API layer or cloud functions because you want to do something like protect an API key or something, you could just do by adding a short circuit route in nginx. Or stuff like contact forms on static sites. I imagine you could do some of that with HAProxy’s Lua scripting, but the ecosystem around OpenResty is faily well built out for a lot of the stuff you’d need.
I just use Caddy, for development and production.
I remember when nginx was first starting to take developer mindshare from Apache. Part of the allure was config simplicity. All the nginx defaults were modern and up to date, whereas Apache needed tons of boilerplate to enable modern behavior and tune performance. Nowadays nginx has been around for a long time. It’s not as bad as Apache was, but you still need to comb through tons of settings to get an ideal config.
Caddy doesn’t have that problem. TLS through Let’s Encrypt by default. HTTP/2 by default. The Caddyfile config has options for functionality, no miscellaneous knobs or flags that need tuning. You can do the development basics without config files at all using the
caddy file-serverandcaddy reverse-proxysubcommands.When you need more, Caddy has optional modules you can build in, including a full blown auth portal implementing Form-Based, Basic, Local, LDAP, OpenID Connect, OAuth 2.0, and SAML Authentication.