Switching from Nginx to Caddy

[dom0]

> It would be no exaggeration to say that Caddy, an up-and-coming HTTP/2 server written in Go that's been gaining a lot of traction, is outright witchcraft. Out of the box, it just works. With HTTPS. With very little configuration.

It's funny that he goes on to compare the two configuration files, where one is a bit verbose, but very clear and easy to understand, while the "Caddyfile" (seriously? xy.conf not good enough anymore?) is four lines that mean basically nothing without a manual.

Less configuration is not intrinsically better.

[vog]

> It's funny that he goes on to compare the two configuration files, where one is a bit verbose, but very clear and easy to understand, while the "Caddyfile" [...] is four lines that mean basically nothing without a manual.

I strongly disagree with this one. In general, I observe that too many super-configurable tools are essentially putting manual work onto the administrator that should really be solved in the software itself, where it is solved once and for all, and can be improved for all at once.

For example, the following line in Caddy:

    transparent

It replaces the following lines in nginx:

       proxy_set_header   X-Real-IP $remote_addr;
       proxy_set_header   Host      $http_host;
       proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header   X-Forwarded-Proto https;

The nginx config is more transparent, for sure. However, for many scenarios this isn't the full list of additional headers on your reverse proxy. Every admin will stumble sooner or later on strange wrongly generated "internal" links by some applications, and will learn the hard way to add more headers, and will never be sure if they really chaught everything. Sure there is community support, but this still means every admin has to do the same kind of research.

It may be good for your ego, some "secret" knowledge that distiguishes you from beginners. But as soon as you get over it, you realize this is just a waste of time.

If this is the task of the software, however, the whole developer community can collect the list of headers and their exact values. Everyone who updates their webserver will benefit immediately. Everyone who installs their webserver for the first time don't even have to bother with that exact header list.

[mrunkel]

For a developer getting a dev environment up and running? Sure, it's way better 'cause they don't have to know anything.

For an admin that needs to understand what is going wrong in production and how to adjust knobs to make it better, you are exactly right.

[rakoo]

That's only because you are already familiar with nginx configuration. The difference in size may not be a good measure of how easy it is to configure a webserver, that is true; however this shows how caddy is correctly configured by default in contrast to nginx. That's what the author wants to show.

[izietto]

What's wrong with this?

  server {  
      listen 80;
      server_name blog.kixpanganiban.com;
      return 301 https://$server_name$request_uri;
  }

  server {  
      listen      443 ssl;
      server_name blog.kixpanganiban.com;
      ssl_certificate /etc/letsencrypt/live/blog.kixpanganiban.com/fullchain.pem;
      ssl_certificate_key /etc/letsencrypt/live/blog.kixpanganiban.com/privkey.pem;

      charset     utf-8;

      # max upload size
      client_max_body_size 75M;

      location / {
         proxy_set_header   X-Real-IP $remote_addr;
         proxy_set_header   Host      $http_host;
         proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header        X-Forwarded-Proto https;
         proxy_pass   http://localhost:2368/;
      }
  }

Every line is self-explanatory, blocks define clearly where some directive is applied and where not, you just have to read some well-written docs in order to spot the right directive. And this came after Apache configuration mess, when almost nothing did better. Maybe lighttpd, but lighttpd was missing of some essential web server options.

[icebraining]

I think the point is that the default configuration is too verbose; after all, you don't have to touch most Nginx options for a typical configuration, so why do you still have to configure so much stuff?

I think the point has some merit, though I personally don't really care.

[dano]

Exactly. There is no magic. Simple, powerful, precise.

[mholt]

I didn't write Caddy because something was wrong with nginx, it just wasn't a good fit for my workflow that makes me most productive.

[oskarth]

It would be no exaggeration to say that Caddy, an up-and-coming HTTP/2 server written in Go that's been gaining a lot of traction, is outright witchcraft. Out of the box, it just works. With HTTPS. With very little configuration.

And the server is down. Irony.

[tyingq]

Appears to be using the ghost cms (node.js) behind caddy:

    <meta name="generator" content="Ghost 0.11" />

So no built-in options for caching in either the CMS or the web server in this case.

[gshulegaard]

"ERR_TOO_MANY_REDIRECTS"

Ummm...welp

[safeharbourio]

he spoke way too quick

[kixpanganiban]

Bleh, this is embarassing. Node in my bottom-tier Lightsail instance is unable to handle the traffic (big surprise) and now I'm starting a bigger instance from a snapshot.

In response to some of the comments:

1. I absolutely agree that knowing exactly what something does line by line is much better than "magic". But that's the thing, if you know Caddy as much as you know Nginx, you'd be able to explain every single one of those 4 lines:

> blog.kixpanganiban.com

Because I didn't bind it specifically to a port (didn't add :80 or :443), I know that Caddy will automatically serve it over HTTPS for me and bind it to both. I could have written `blog.kixpanganiban.com:80` instead if I wanted it to be HTTP-only, or even `http://blog.kixpanganiban.com/blog/` if I wanted to serve it on the `/blog` path.

> proxy / localhost:2386 {

Pretty self-explanatory, it proxies all requests to `/` to the `localhost:2386` (Ghost) backend. I could attach a list of backends to make it act as a load-balanced reverse proxy similar to nginx, like so: `proxy / localhost:2375 somesite.com:2312 {`.

> transparent

Caddy configs call this a "preset", basically a shorthand for:

header_upstream Host {host}

header_upstream X-Real-IP {remote}

header_upstream X-Forwarded-For {remote}

header_upstream X-Forwarded-Proto {scheme}

2. I'm not trying to sell snake-oil, I'm trying to introduce a perfectly good alternative which I've been meaning to try for a while. Also, Caddy docs: https://caddyserver.com/docs/

[tyingq]

Caddy has plenty of fans here, I like it as well. I think you just got bit by the irony of making the comparison with nginx. Particularly because with nginx, you could have added some caching with a few configuration directives.

With two relatively new options (caddy and ghost), and the traffic spike, you're stuck with the downside of new...no established built-in option to cache.

[ComputerGuru]

Site is (currently) down, for what it's worth. Someone blogging too early about their"success?"

[tyingq]

Next up..."How to configure a caching reverse proxy for Caddy"

[onion2k]

https://webcache.googleusercontent.com/search?q=cache:MK6zOl...

[onion2k]

Looking at the caddy configuration it's unclear what it's actually doing. From the article "After step 5, Caddy prompted me to enter my email for the LetsEncrypt cert. In the background, it took care of signing me up for LE, verifying my domain ownership, and downloading and attaching my cert files." That means I can't ssh on to a server, cat the http server config file(s), and know what's actually happening. That alone is enough for me to not use it.

[icebraining]

How so? It just has different defaults; as long as you know which those are, you know what's happening, just like with Nginx.

[shocks]

Link is down...

Cache: https://webcache.googleusercontent.com/search?q=cache:MK6zOl...

[sametmax]

Oh, the irony. They website is now down, with an nginx error message.

[soulchild37]

502 Bad Gateway From Nginx.... I am perplexed...

[kixpanganiban]

Chill out, I respawned the server and forgot the nginx is still on upstart, which is why it took over before I could start caddy :)

[macygray]

I've opened a link and got 502 Bad Gateway from ginx/1.10.0 (Ubuntu)

=) nice

[rycfan]

He's working on his "Switching from Caddy to nginx article" right now.

[celsoazevedo]

"502 Bad Gateway

nginx/1.10.0 (Ubuntu)"

[coldcode]

Maybe they should use Caddy?