4 ms·

Agreed. However if an author of the solution does insist on implementing it in one binary with orchestration step being in the code rather than pulled out into

Agreed. However if an author of the solution does insist on implementing it in one binary with orchestration step being in the code rather than pulled out into the infrastructure management, the author should not be surprised that no one outside tiny single server operations would consider it to be a contender.

mholt 7y ago
Your logic assumes that Caddy's auto-HTTPS cannot be configured and must be self-contained, but that's not accurate. Caddy can be configured with traditional, manually-managed (or externally-managed) TLS certificates just like other web servers too, if you need that. All we're saying with this project is, "There is a better way going forward, and we're solving that problem."
- notyourday 7y ago
  You are presuming that as a designer of the Caddy you understand how the non-single-VM customers are running their infrastructure. Here's a typical problem of a distributed entry point system - network partitioning. * If your key/cert store relies on key servers being always accessible from everywhere, it simply won't work. * If your solution is to bake a key into a file system, then it is no better than existing nginx implementation. Basically, if you want your solution to be adopted, it needs to be significantly better than the entrenched ones.
jrockway 7y ago
Yeah, I think that's a fine analysis. I don't think Caddy cares that it's not the "right way" if it solves problems for some people. It is certainly easier than certbot and nginx for cases where you have one VM that you play with as though it's a pet. And a lot of people treat their production environments that way, so it does solve a problem. The next problem that people will run into is that because they can't reliably run multiple "things", they won't have a monitoring stack to tell them that certs aren't renewing. But, maybe nothing bad will happen and it won't be a problem. "Hope is not a strategy" if you're a Google SRE, but people do pretty OK with hope in the real world ;)
- mholt 7y ago
  > The next problem that people will run into is that because they can't reliably run multiple "things", they won't have a monitoring stack to tell them that certs aren't renewing. Can you elaborate on this? I'm not sure I follow; there's nothing preventing people from using something like https://ohdear.app/ https://ohdear.app/ (or any other monitoring tool) with a self-contained solution like Caddy. In fact, I recommend that people do.
  - jrockway 7y ago
    No, something like that is fine. I am just trying to convey that there is a huge industry around fixing these problems very incrementally. ohdear.app today, then DataDog... all because they can't just run Prometheus and Alertmanager. This isn't how I like it, but I totally see the use case. Caddy is a part of that use case and is probably the reason it exists. I think that's fine! (Edit: ohdear is really neat though, I think people might want that no matter what. You have to serve your status page from somewhere, might as well get some cert checks thrown in for free!)
    - Whitestrake 7y ago
      Just to clarify, Caddy v1 exports metrics to Prometheus. V2 could easily do the same, it's just as extensible as v1. https://caddyserver.com/v1/docs/http.prometheus https://caddyserver.com/v1/docs/http.prometheus
      - jrockway 7y ago
        I am not talking about Caddy, I'm talking about the thought process that leads to needing everything integrated in one process.
- notyourday 7y ago
  > The next problem that people will run into is that because they can't reliably run multiple "things", they won't have a monitoring stack to tell them that certs aren't renewing. But, maybe nothing bad will happen and it won't be a problem. "Hope is not a strategy" if you're a Google SRE, but people do pretty OK with hope in the real world ;) Sort of agreed with this. Based on my experience, the reality is a bit more complicated. As soon as one is past the "this VM is a special pet and it is the only one I have" stage in my experience even smaller companies get dozens and soon hundreds of distinct HTTPs entry points: * Main site/API ( code ) * Ops support * bizops ( invoicing/quoting ) Which is where the issues of monitoring and observability come up. I bet techcrunch has close to a hundred HTTP/HTTPS entry points and every time they evaluate a solution to replace their current entry point structure they ask if the new method would at least solve all of their existing problems. Ops people aren't gong to add another partial solution so the mix.

mholt 7y ago

Your logic assumes that Caddy's auto-HTTPS cannot be configured and must be self-contained, but that's not accurate. Caddy can be configured with traditional, manually-managed (or externally-managed) TLS certificates just like other web servers too, if you need that. All we're saying with this project is, "There is a better way going forward, and we're solving that problem."

notyourday 7y ago
You are presuming that as a designer of the Caddy you understand how the non-single-VM customers are running their infrastructure. Here's a typical problem of a distributed entry point system - network partitioning. * If your key/cert store relies on key servers being always accessible from everywhere, it simply won't work. * If your solution is to bake a key into a file system, then it is no better than existing nginx implementation. Basically, if you want your solution to be adopted, it needs to be significantly better than the entrenched ones.

jrockway 7y ago

Yeah, I think that's a fine analysis. I don't think Caddy cares that it's not the "right way" if it solves problems for some people. It is certainly easier than certbot and nginx for cases where you have one VM that you play with as though it's a pet. And a lot of people treat their production environments that way, so it does solve a problem. The next problem that people will run into is that because they can't reliably run multiple "things", they won't have a monitoring stack to tell them that certs aren't renewing. But, maybe nothing bad will happen and it won't be a problem. "Hope is not a strategy" if you're a Google SRE, but people do pretty OK with hope in the real world ;)

mholt 7y ago
> The next problem that people will run into is that because they can't reliably run multiple "things", they won't have a monitoring stack to tell them that certs aren't renewing. Can you elaborate on this? I'm not sure I follow; there's nothing preventing people from using something like https://ohdear.app/ https://ohdear.app/ (or any other monitoring tool) with a self-contained solution like Caddy. In fact, I recommend that people do.
- jrockway 7y ago
  No, something like that is fine. I am just trying to convey that there is a huge industry around fixing these problems very incrementally. ohdear.app today, then DataDog... all because they can't just run Prometheus and Alertmanager. This isn't how I like it, but I totally see the use case. Caddy is a part of that use case and is probably the reason it exists. I think that's fine! (Edit: ohdear is really neat though, I think people might want that no matter what. You have to serve your status page from somewhere, might as well get some cert checks thrown in for free!)
  - Whitestrake 7y ago
    Just to clarify, Caddy v1 exports metrics to Prometheus. V2 could easily do the same, it's just as extensible as v1. https://caddyserver.com/v1/docs/http.prometheus https://caddyserver.com/v1/docs/http.prometheus
    - jrockway 7y ago
      I am not talking about Caddy, I'm talking about the thought process that leads to needing everything integrated in one process.
notyourday 7y ago
> The next problem that people will run into is that because they can't reliably run multiple "things", they won't have a monitoring stack to tell them that certs aren't renewing. But, maybe nothing bad will happen and it won't be a problem. "Hope is not a strategy" if you're a Google SRE, but people do pretty OK with hope in the real world ;) Sort of agreed with this. Based on my experience, the reality is a bit more complicated. As soon as one is past the "this VM is a special pet and it is the only one I have" stage in my experience even smaller companies get dozens and soon hundreds of distinct HTTPs entry points: * Main site/API ( code ) * Ops support * bizops ( invoicing/quoting ) Which is where the issues of monitoring and observability come up. I bet techcrunch has close to a hundred HTTP/HTTPS entry points and every time they evaluate a solution to replace their current entry point structure they ask if the new method would at least solve all of their existing problems. Ops people aren't gong to add another partial solution so the mix.