[HN Gopher] Show HN: Caddy v2.5.0
___________________________________________________________________
Show HN: Caddy v2.5.0
Author : francislavoie
Score : 181 points
Date : 2022-04-26 17:20 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| amanzi wrote:
| The Dynamic Upstreams feature looks good, but it doesn't seem to
| be as nicely integrated with Consul as Traefik is.
| francislavoie wrote:
| Could you elaborate on what you mean? For now we only ship with
| support for SRV and A/AAAA, but anyone can write a Consul
| implementation if they like.
|
| I'm not sure how that would differ from SRV though, since
| Consul supports SRV anyways. I'm not a Consul user though.
| torquemodwanted wrote:
| How long does it usually take for first-party packages to be
| updated, e.g.,
| https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/ ?
| francislavoie wrote:
| We've notified the package maintainers, so it's in their hands
| now. It's not automated, it needs a human to do it.
| barkerja wrote:
| Where does Caddy live in a Kubernetes world -- or does it? (I'm
| not the most knowledgeable with either, so genuinely curious how
| these pieces all fit together).
| numbsafari wrote:
| In addition to what others have said, I think it's a handy
| option for a lightweight http backend or proxy when you need it
| to glue something together. For example, quickly fronting an s3
| bucket, or serving static content generated by another
| container in the same pod, etc.
| mholt wrote:
| I think just like any other server, but with fewer things to
| set up (HTTPS, certificates, etc). We also have an ingress
| controller in the works: https://github.com/caddyserver/ingress
|
| (Not a Kubernetes user, so my answer is probably not the best.)
| ShakataGaNai wrote:
| Caddy at its simplest form is an HTTP server. So you could use
| it to front end your application that otherwise isn't well
| suited for taking direct HTTP requests. Caddy would bring you
| other features like TLS support.
|
| However I think in K8s world Caddy would make the most sense as
| an Ingress Controller. There is even a project as such:
| https://github.com/caddyserver/ingress
|
| All traffic would terminate first at Caddy. Handling TLS,
| HTTP1/2/3, etc. Then passing it back to your application
| service/pod.
| getcrunk wrote:
| Does anyone use caddy in production? At what loads?
| mholt wrote:
| Yes. High loads, and high stakes (hundreds of thousands of
| dollars worth of transactions per hour, is one metric I do
| know).
| tnolet wrote:
| Not super duper high load but we use Caddy to https encrypted
| dashboards to 25k users.
| evv wrote:
| Caddy is such a delight! I can't reccomend it fast enough when
| somebody mentions they are on nginx.
|
| Small random feedback: I like the idea of JSON configuration but
| most of the common docs/recipes are documented only with the
| Caddyfile format. I couldn't figure out the full JSON schema that
| was expected so I wound up generating a Caddyfile string instead
| for my programatic control. Maybe there is some translation
| tooling that could help?
| codazoda wrote:
| It seems that this command will translate the Caddyfile to
| json.
|
| ./caddy adapt
| sgt wrote:
| I'm a heavy nginx user - there's not much that I haven't
| already done with it and I know the documentation quite well.
| Why would someone like me change to Caddy? I can see there are
| some NGINX Plus features that are free in Caddy.
| tdhz77 wrote:
| Single binary is nice, live config changes, let's encrypt is
| built in.
| mholt wrote:
| And memory safety! No C at the edge.
| mholt wrote:
| Thanks for recommending it!
|
| I hear ya. The JSON config is definitely not trivial. I wrote
| our JSON docs and strove to made them easy to follow. You can
| traverse into the module structure piece-by-piece here:
| https://caddyserver.com/docs/json/
|
| There is also a Caddy plugin by @abiosoft that can generate a
| JSON schema for your custom Caddy builds, which can then be
| used by IDEs to give you autocomplete and validation:
| https://github.com/abiosoft/caddy-json-schema
|
| I also sometimes recommend writing your config by hand in the
| Caddyfile, then using `caddy adapt` to get the JSON equivalent.
| (It might not always be the prettiest JSON, since the adapter
| is only so smart.) But then you can fine-tune the JSON a little
| easier, possibly. Hope that helps!
| skrause wrote:
| A few complete, fully working example JSON configuration
| files for common use cases would be really useful as well.
| mholt wrote:
| Agreed. (Although, for now, you can run caddy adapt on your
| Caddyfile to get the JSON you're looking for.)
| evv wrote:
| Thanks! Somehow you knew that I was struggling with JSON
| config of a custom Caddy build (for the Cloudflare extension)
|
| caddy-json-schema looks great, I'll try this next time!
|
| not sure if I totally missed `caddy adapt` or if I had
| troubles with it.
| lxgr wrote:
| Caddy is absolutely amazing.
|
| I'm running it on an RPi that's hosting various home automation
| and hobby projects, all serving HTTP to the loopback interface
| only, with Caddy acting as a reverse proxy, and I've never even
| had to think about HTTPS. Adding a new service is adding a single
| line to my config file, and the rest happens automatically.
|
| Finally, no more "trust this self-signed certificate" even for
| toy projects, no more port forwarding, copy-paste-ing dubious PEM
| and CRT files across services and Docker containers etc.
| simonw wrote:
| Would you mind sharing a (redacted if you like) copy of your
| config file in a Gist? Purely out of curiosity - your setup
| sounds really neat.
| lxgr wrote:
| Sure, here's a redacted example:
|
| https://gist.github.com/lxgr/303b1a3cd87005edb43b91545c5306b.
| ..
|
| I unfortunately can't remember if there is some header/footer
| I'm omitting here - this file is managed by Ansible for my
| setup, but I believe it should effectively be the full
| Caddyfile.
| m-p-3 wrote:
| I'm definitely going to put Caddy on my next NAS build, sounds
| like a delightful proxy to setup.
| okasaki wrote:
| Setting that up with nginx and acme.sh is pretty easy as well.
|
| One benefit I found with using nginx is that services are more
| likely to have nginx proxy example configs, and sometimes these
| are non-trivial, eg.:
|
| https://docs.mattermost.com/install/config-proxy-nginx.html
|
| I guess with caddy you're on your own, which doesn't look like
| fun.
| mindwok wrote:
| Check out the config adapters:
|
| https://caddyserver.com/docs/config-adapters
|
| Now you can use your nginx config with Caddy!
| francislavoie wrote:
| Caddy's defaults usually mean your config ends up being 1/4
| or less of the size of Nginx ultimately. Often the
| 'reverse_proxy' directive's defaults are good enough, if the
| app you're proxying to is reasonably modern.
|
| But if you need help, we're very active on
| https://caddy.community/ to answer questions :)
| qbasic_forever wrote:
| Wow the new features sound great. Does tailscale run a local DNS
| server or provide AAAA or SRV records that the new dynamic
| upstream could connect to directly? The combo of dynamic upstream
| and dynamic HTTPS certs automatically from tailscale would be
| really nice. I'd love to just run tailscale and caddy locally on
| all machines and instantly have 100% proper browser HTTPS and DNS
| name access to all my tailscale services.
|
| If tailscale doesn't provide it, anyone know of a DNS server
| that's caddy-like in simplicity and dead simple ease of running
| on localhost with minimal config, secure by default, etc?
| francislavoie wrote:
| You can learn about the Tailscale feature here:
| https://tailscale.com/blog/caddy/
|
| Basically this is more about grabbing the TLS cert from
| Tailscale's daemon. How you handle the request is up to you.
| It's not related to the dynamic upstreams feature.
| therein wrote:
| I was expecting this to be posted by mholt. :)
|
| I use Caddy in my production systems with one exception,
| websockets. Yes it works, yes it is easier to configure compared
| to nginx. But there is this one bug that I can't really put my
| finger on that is hard to debug and create an issue for.
|
| Under high load, it seems there are messages that are dropped and
| then the connection gets lost. It even affects the origin host
| because it keeps the connections alive and they keep piling up.
| Killing Caddy brings the upstream service back to life.
|
| With nginx I am not having these issues and the websockets are
| more stable. It is just harder to set up and needs multiple
| moving pieces for autossl instead of it being taken care of by
| Caddy.
| mholt wrote:
| Can you open an issue with more details? I don't think this has
| been reported before. So that's why it hasn't been fixed yet.
| But we'd like to look into it.
| qudat wrote:
| I just used Caddy for the first time for https://lists.sh and was
| super impressed by the automatic TLS. The config was also 2 lines
| of code. Great work!
| pwdisswordfish9 wrote:
| s/deciminate/disseminate/
| qudat wrote:
| Thank you! I've made the change and deploying shortly
| tbran wrote:
| Just wanted to say this is a cool little project. I hope you
| get some interesting lists on there!
| qudat wrote:
| Hey thanks so much! I'm having a blast publishing lists and
| discovering what others are posting.
| karanbhangui wrote:
| very cool interface! login thru public key + ssh and lists
| contributed via scp
| qudat wrote:
| Thank you! I've been having a blast with the workflow. I
| think I'm going to make a sibling service that does the same
| thing but a more traditional blog platform with markdown
| support.
| always_left wrote:
| I remember being a newgrad at my startup it was a huge pain to
| get HTTPS up and running, until I ran into Caddy. Loved it!
| mholt wrote:
| Glad you enjoy it!
| mholt wrote:
| Francis definitely gets to claim the "Show HN" on this one, as he
| authored more commits to Caddy during this timeframe than I did:
| https://github.com/caddyserver/caddy/graphs/contributors?fro...
|
| He and several other maintainers, community helpers, distribution
| team members, and sponsors go a long way to making this project
| tick. Thanks for all you do!
| config_yml wrote:
| Thank you all. Caddy is an absolute blessing!
| gorgoiler wrote:
| I utterly adore your project. Thank you so much.
|
| Are there plans for SMTP or IMAP proxying?
|
| Do you do SNI proxying too?
|
| I would love for Caddy to be my one stop shop for all TLS
| termination.
| eliaspro wrote:
| "Caddy L4" aka "Project Conncept" might be what you're looking
| for:
|
| https://github.com/mholt/caddy-l4
|
| "Project Conncept is an experimental layer 4 app for Caddy. It
| facilitates composable handling of raw TCP/UDP connections
| based on properties of the connection or the beginning of the
| stream."
| mholt wrote:
| Yep, that module is exactly how to do it!
|
| But Caddy's http server can also do basic logic around SNI if
| I recall correctly.
| goodpoint wrote:
| I'd rather use something that can be packaged and maintained
| properly by distributions:
| https://repology.org/project/caddy/versions
|
| I use distributions because I care about security and I'll be
| downvoted to oblivion for saying this.
| glasshug wrote:
| Yeah, if you're looking for a package, you'll want to stick to
| the Cloudsmith .deb since it's bound to Caddy's GitHub release
| workflow so guaranteed to stay up-to-date:
| https://cloudsmith.io/~caddy/repos/stable/packages/
|
| P.S., from the guidelines:
|
| > Please don't comment about the voting on comments. It never
| does any good, and it makes boring reading.
|
| edit: and an official response
| https://news.ycombinator.com/item?id=31170881
| francislavoie wrote:
| That's correct. See https://caddyserver.com/docs/install for
| our recommended installation methods. Only the .deb via
| Cloudsmith is fully automated, every other method requires
| some humans to publish the release, for a variety of reasons.
| todotask wrote:
| How useful is dynamic upstream which is new to me?
| mysterydip wrote:
| Sounds like it would allow automatic handling of either failed
| backend nodes or adding new capacity over time without
| restarting the proxy, but I could be reading it wrong.
| mholt wrote:
| Basically this, yeah. You can add or take down backends
| without having to keep web server config in sync and reload
| it. (Though config reloads are pretty light anyways.)
| paulgb wrote:
| Does it have implications for long-lived connections like
| SSE and websockets? It seems like restarts would have been
| disruptive to those but now might not be?
| mholt wrote:
| Possibly; the long-lived connections eventually have to
| end when reloads (note: restarts and reloads are
| different) happen, to free up resources -- otherwise they
| leak. (The grace period is configurable and can even be
| disabled.)
| eliaspro wrote:
| This bit us in a recent project where we have very long
| ongoing downloads, where even a very high grace period
| wouldn't really help.
|
| I wonder whether it's technically generally feasible
| (possibly depends on net/http2's capabilities) to
| handover the connection from the old to the new server
| instance, comparable to what systemd does in terms of FD
| passing for socket-activated services.
| francislavoie wrote:
| The problem is that existing connections are inside of
| async functions (goroutines) that have references to the
| old config. AFAIK, there's no way in Go's stdlib to kill
| those goroutines while keeping the connection and handing
| it to another fresh goroutine.
|
| To be clear, the new config is running at the same time
| as the old is still tearing down; all new connections get
| handled by the new config. Listeners are shared and
| transferred between servers.
|
| We're all ears, though, if someone with deep knowledge of
| Go's internals can point us in the right direction.
| mholt wrote:
| If your backends are registered via SRV records (e.g. Consul),
| this will be very useful for you! It also works similarly for
| A/AAAA records.
|
| This feature is modular, so other methods of retrieving
| backends can be implemented as well.
| anotherevan wrote:
| I'm seriously considering moving from Nginx to Caddy. There seem
| to be so fewer footguns involved in configuring it.
| LAC-Tech wrote:
| Really glad caddy is finally getting some level. It's such a
| great example of having great defaults, while not drowning you in
| magic.
| VWWHFSfQ wrote:
| Is Caddy scriptable? I don't know much about it. But ever since I
| discovered nginx-lua-module and OpenResty it's been pretty much a
| game-changer for me. Curious if other popular webservers have
| done similar? Not really talking about things like mod_perl/php.
| Although I guess those are somewhat the same thing.
| francislavoie wrote:
| It's also very easy to write plugins for Caddy:
| https://caddyserver.com/docs/extending-caddy
| mholt wrote:
| True, that's one reason we haven't prioritized scripting too.
| Writing a plugin that is natively compiled in is just as easy
| and can perform even better.
| mholt wrote:
| Kind of (indirectly); we don't have an interpreter built-in,
| but the JSON config is managed natively through an API:
| https://caddyserver.com/docs/api
|
| So yeah, you can write scripts that control Caddy while it's
| online.
|
| The nice thing about the API is you can code in whatever
| environment or language you prefer: no need to learn Caddy's
| scripting language or anything like that. (The config is JSON,
| so nearly every language can output it.)
| mhitza wrote:
| Apache has built-in lua scripting support nowadays.
| andrewstuart wrote:
| After more than 10 year nginx, I switched to Caddy and never
| regretted a moment.
| mholt wrote:
| That's awesome!
| kdasme wrote:
| Hey, as a nginx user for many many years, I don't understand
| why would I want to switch. Can you please give a few examples
| why it made sense for you? Especially with kubernetes
| environment I have a hard time trying to justify this.
| devil1591 wrote:
| benbristow wrote:
| I've been using this Docker image in a Docker Compose
| configuration to run some apps on a VPS
|
| https://github.com/lucaslorentz/caddy-docker-proxy
|
| Pretty nice, handles routing to your containers and manages
| LetsEncrypt for you. Response times are super fast too (<= 100ms
| for an ASP Web API application which uses Postgres via Entity
| Framework).
| mholt wrote:
| Best kept secret of Caddy+Docker.
| benbristow wrote:
| Not a secret now haha!
|
| I used to use this https://github.com/nginx-proxy/nginx-proxy
| (used to be under jwilder's GitHub account) which was also a
| good tool, and then used behind CloudFlare for free SSL
| certificates, but the Caddy container with automatic
| LetsEncrypt is fantastic also.
| nomoreusernames wrote:
| love caddy, its all i ever wanted
___________________________________________________________________
(page generated 2022-04-26 23:01 UTC)