6 ms·

I love nginx and while I use Caddy on my laptop all my servers are nginx. Now the dynamic configuration API is going open this will give Envoy a good run for i

• harpratap 4y ago
  > Now the dynamic configuration API is going open this will give Envoy a good run for its money Wasn't dynamic configuration always available through OpenResty? It's based on Nginx too with extra Lua modules to fill the feature gaps
• mholt 4y ago
  What's keeping you from using Caddy in production? We designed it for that too :D PS. Have you seen Caddy's on-line config API? https://caddyserver.com/docs/api https://caddyserver.com/docs/api
  • derefr 4y ago
    Global rate-limiting bucketed by Basic-Auth-presented API key? Easy enough in Nginx; no idea how to do it with Caddy. When people say "production", they mean things like "QoS for a shared-multitenant system, in the presence of customers with really badly tuned and spiky request workloads, whose traffic you must nevertheless mostly accept."
    • mholt 4y ago
      If you can't already do it with the rate limit module I wrote, open an issue with your detailed requirements: https://github.com/mholt/caddy-ratelimit https://github.com/mholt/caddy-ratelimit -- should be pretty straightforward for the most part. > QoS for a shared-multitenant system, in the presence of customers with really badly tuned and spiky request workloads, whose traffic you must nevertheless mostly accept. Yah, we see that sometimes. Caddy usually handles it fine, sometimes with a bit of massaging the config.
      • POPOSYS 4y ago
        We can not use Caddy as long as a reliable and battle-tested rate limit module does not exist. "Work in progress" is not something I would like to put on a production system. It would be great if you would like to finish the work on this project and make it part of the Caddy default distribution. Honestly I do not understand how people run high-traffic sites without rate limiting. [D]DOS attacks and other misuse (e.g. spambots etc.) are daily issues on the internet, do you just ignore that?
        • heurisko 4y ago
          Pasting a link from when we previously talked about this, for interest. https://news.ycombinator.com/item?id=31439457 https://news.ycombinator.com/item?id=31439457 Appreciative of all the work regarding caddy, but the rate limiting seems to be chicken and egg, as few people seem to be willing to test it out in order for it to be accepted into core, and people are unwilling to test it out, because it's not in core. It's also a blocker for me, so nginx wins by force of inertia.
          • jakearmitage 4y ago
            Same for me. If it's not on core, means devs don't want to support it, which means it is buggy, therefore not ready for production.
            • mholt 4y ago
              No; if it's not in the core, that means we don't want to bloat the code base. Caddy is extensible for very good reasons!
        • mholt 4y ago
          Happy to finish it if a company would like to sponsor that work. It works well enough for what it was originally commissioned for. It actually will probably work pretty well for you as-is. Try it!
    • Alacart 4y ago
      As a counter point, I've been running 100k+ domains through caddy clusters with about 1tb of traffic per month (so not a ton, but not nothing). I built and manage that solo with very little maintenance or support, which I think is a testament to how reliable and performant caddy is.
      • mholt 4y ago
        Holy cow, 100k? Who are you? (Seriously) That might be the largest deployments I know about in terms of domain names. I keep telling people "tens of thousands" when I probably should be saying "hundreds of thousands"...
        • Alacart 4y ago
          You already know me, just not under this username! I try not to put my name directly out on forums like this, but I run https://approximated.app https://approximated.app and those 100k+ domains aren't all in one cluster, though some clusters are growing quickly and might be there in a few months. Customers paying for the clusters are generally SAAS or hosting related so they can bring a lot of user domains when they come on board and tend to grow steadily.
          • mholt 4y ago
            Ah, that's you! Thanks so much for sponsoring. Hit me up if you ever need something or would like something more/special from your sponsorship.
      • POPOSYS 4y ago
        But how do you know that it is really reliable and performant? How do you know how many requests are silently lost? I would like to read more about how reliability is actually measured on high-traffic sites.
  • cplli 4y ago
    I also only have Caddy running locally to proxy different dev environments and serve certain files, and it is an exceptional tool, but I would never deploy it in production: 1) Nginx configs are (from my experience) easier to template (in our Nomad & Consul cluster architecture) 2) From what I could gather, Nginx is more stable and performant 3) I don’t trust Caddy’s codebase security. It simply has too many dependencies, and Go makes it very easy to get into dependency hell Honestly if 3) wouldn’t be an issue, and stability from 2) would be proven, I would probably give Caddy a try in production.
    • mutt2016 4y ago
      I think it would surprise you. A lot of people seem to holdover that opinion from pre-v2, but a lot is well done. Templates are totally doable, heck you can reference exported shell vars in the config directly.
      • mholt 4y ago
        Yes! So many people apply their conceptions of Caddy v1 to Caddy 2. Thanks for the comment!
        • BrandoElFollito 4y ago
          TBH, v1 was already kilometers ahead compared to Apache or nginx for normal, casual users. I host some stuff at home and moving from nginx to Caddy v1 was a huge breath of fresh air. V2 made the product extremely good. I tried a bit to use the API to automate my deployments (which are, again, home deployments) but it stopped to make sense when i discovered that Caddy has the ability to read config files via wildcards.
    • mholt 4y ago
      Hm, the templating thing surprises me. I'd be interested to know more about that, since Caddyfile is heavily inspired by nginx config. But for automating and scripting, I typically recommend using the JSON config. Pro tip: Did you know you can use any config format you want to configure Caddy [1]? So if templating the Caddyfile is hard for you, use something else! You can use YAML, TOML, or even NGINX configs. On 2, that's been pretty well debunked at this point. Caddy is written in Go, and is only a very thin wrapper over the Go standard library, which heartily powers much of Cloudflare's, Netflix's, and Google's infrastructure. Plus you gain memory safety and are exempt from a whole class of vulnerabilities with Caddy. We've seen numerous instances where Caddy has kept sites up while nginx let other sites go down, due to Caddy's resilience in the face of certificate problems, for example. On 3, sure, I can understand that -- but this is true of any open source project. And it IS open source, so you can "own" your own code base. You're in control. And actually, Go's module proxy protects Go projects more than most C projects. Caddy's extensible architecture means that you can add all the features you need without bloating the code base. [1]: https://caddyserver.com/docs/config-adapters https://caddyserver.com/docs/config-adapters
  • js2 4y ago
    Is there a Caddy equivalent to OpenResty? I use openresty as a proxy for a Python app and it's been super handy to have the lua extensibility.
    • francislavoie 4y ago
      Caddy is designed around pluggability, everything is a module. It's written in Go, so you write your middleware logic in Go. See https://caddyserver.com/docs/extending-caddy https://caddyserver.com/docs/extending-caddy
      • Starlevel001 4y ago
        Interesting way of saying "no"
        • francislavoie 4y ago
          Maybe you can better explain what they're asking for. Because otherwise, I find it unclear. Isn't the point of OpenResty to provide a system for building your app right inside the webserver? Because you can absolutely do that with Caddy, by writing plugins.
          • js2 4y ago
            Here's an example of how I'm using it. Basically to log part of the response body to API requests. log_format main '$remote_addr - - [$time_local] "$request" ' '$status $body_bytes_sent "$host" ' '"$http_user_agent" $http_content_length $request_time ' '"$resp_body" *$connection $connection_requests'; server { set $resp_body ""; location ~ "^/api/v1/...$" { # Append response to resp_body until it reaches max_len. # - ngx.arg[1] is input chunk. # - ngx.arg[2] is eof flag (response is done). # - ngx.ctx.resp_body holds partial result between calls # - ngx.var.resp_body holds final result. # From: # - https://gist.github.com/morhekil/1ff0e902ed4de2adcb7a # - https://github.com/openresty/lua-nginx-module/ body_filter_by_lua_block { local max_len = 256 local resp_body = (ngx.ctx.resp_body or "") if string.len(resp_body) <= max_len then resp_body = resp_body .. string.sub(ngx.arg[1], 1, max_len) ngx.ctx.resp_body = string.sub(resp_body, 1, max_len) end if ngx.arg[2] then ngx.var.resp_body = ngx.ctx.resp_body end } } But there are many scenarios where being able to extend the HTTP server via Lua is more convenient than writing a plugin I would think? I've also used Lua in the past with haproxy and with Redis. It's a powerful, performant, light-weight, and flexible escape hatch/extension mechanism.
  • nicbou 4y ago
    No caching. https://caddy.community/t/state-of-http-caching-in-caddy-2/11564 https://caddy.community/t/state-of-http-caching-in-caddy-2/1...
    • francislavoie 4y ago
      That's outdated information. The cache handler plugin is ready to use: https://github.com/caddyserver/cache-handler https://github.com/caddyserver/cache-handler
      • nicbou 4y ago
        Neat! I'll look into it, thanks
  • jarym 4y ago
    The docs unfortunately. It always takes longer (maybe it’s just me) to figure out how to do something non-trivial with Caddy and here both Envoy and Nginx shine.
    • francislavoie 4y ago
      Could you be more specific? What couldn't you find? If you don't let us know, we can't improve the docs.
      • jarym 4y ago
        A lot of the docs don’t explain what a module does - for example: > dns.providers.azure wraps the provider implementation as a Caddy module. Well great what does the provider implementation do? It’s the same for all DNS and not so useful if I’m coming from Apache or Nginx. At least explain what I’ll be able to do with this module. From http.handlers.push: > http.handlers.push is a middleware for manipulating the request body. That’s a bit generic - any examples? There’s a lot of ways to modify the request body so what can I do with this? There are 2 http.authentication.providers.jwt - both unofficial and both with 0 documentation. There has to be some standards here, why link to blank docs from your site? All-in-all it just feels meh. I like to read docs that’ll give me the technical ins and outs of every function with some examples ideally. Microsoft does a decent job of this as does Postgres (and others but these two come to mind immediately). Envoy is pretty nice here too and Nginx close.
        • francislavoie 4y ago
          Re "dns.providers.azure", that's a third-party module, we don't maintain that. The documentation you see in the JSON docs is auto-generated from code comments (godoc) so it's the maintainer's responsibility to write good comments that can act as documentation. Re "http.handlers.push", fair point, that one's lacking/misleading. But this is a feature that was just added to satisfy a specific need, then fell by the wayside. Mostly because now Chrome is removing support for Server Push, so we'll need to deprecate this feature, in favor of HTTP 103 Early Hints which is the effective replacement for it. Also, in general, we tend to spend more effort on maintaining the Caddyfile docs than the JSON docs, because the large majority of users use the Caddyfile. See https://caddyserver.com/docs/caddyfile/directives/push https://caddyserver.com/docs/caddyfile/directives/push for the push handler, complete with examples. Re "http.authentication.providers.jwt", well again, I think that's an issue with the module's maintainer not sufficiently using godoc comments. The maintainer registered the module under two different module paths (renamed repo) so it caused a duplicate. We'll need to manually remove the duplicate from the database, I think. It might be because there's conflicting ones that no docs are shown (cause the backend which serves the API docs is confused, I dunno, it's a bug clearly, will need to dig deeper).
  • aestetix 4y ago
    The primary reason I never looked seriously at Caddy is because it had an installation via a bash one liner, and refused to post a repo or a way to download specific versions. This makes maintaining many identical servers via ansible a real challenge. To be fair, that was several years ago. But can you explain the logic behind that decision?
    • skeetmtp 4y ago
      Not the case anymore, there is a deb repo https://caddyserver.com/docs/install https://caddyserver.com/docs/install I use it with ansible for 18 months with no issue
• deleted 4y ago
  [deleted]