3 ms·

I see a lot of patches for nginx coming from cloudflare, how much of their infrastructure is based on nginx, anyone know any good articles on their internal set

I see a lot of patches for nginx coming from cloudflare, how much of their infrastructure is based on nginx, anyone know any good articles on their internal setup?

jgrahamc 10y ago
I don't think we've every done a blog post on the overall architecture of a machine. But as of today it's a mixture of nginx (our own fork since nginx folks won't accept all our patches), rrdns (our own DNS server written in Go), a whole load of Lua (because we use OpenResty), a whole load of other services written in Go, ... Depending on the protocol (or version) traffic may or may not be served via nginx.
- grey-area 10y ago
  Thank you, would love to see a blog post like that outlining the architecture you have ended up with and how it all fits together.
- garblegarble 10y ago
  >nginx (our own fork since nginx folks won't accept all our patches) Is there any interest in publishing this whole fork? I know you already publish separate modules to github, beyond that is there crossover with nginx plus functionality they don't want to accept?
  - jgrahamc 10y ago
    The problem with publishing it is that we have to maintain it and sometimes we put stuff in there that we wouldn't normally want to make public or it would be a pain to extract because it's linked to our infrastructure. Open sourcing stuff has a real cost. We do as much as we can.
- daenney 10y ago
  But as of today it's a mixture of nginx (our own fork since nginx folks won't accept all our patches) Could you elaborate, within the limits that you're allowed, on the patches that got rejected? I'm curious as to what they were about and why they didn't make it in.
  - jgrahamc 10y ago
    For example, we support both SPDY and HTTP/2 and will do SPDY if an older client can't do HTTP/2. NGINX guys didn't want that. We tend to publish rejected stuff as patches: https://github.com/cloudflare/sslconfig/tree/master/patches https://github.com/cloudflare/sslconfig/tree/master/patches
    - daenney 10y ago
      Awesome, thanks! I can sort of understand not wanting to maintain the SPDY code but I can see how that would be useful to CF to have. I'm a bit disappointed the chacha20 ones aren't making it in. I'm curious about the Dynamic TLS records patch. Could you or someone else that understands what that's doing elaborate on what's going on?

I see a lot of patches for nginx coming from cloudflare, how much of their infrastructure is based on nginx, anyone know any good articles on their internal setup?

jgrahamc 10y ago

I don't think we've every done a blog post on the overall architecture of a machine. But as of today it's a mixture of nginx (our own fork since nginx folks won't accept all our patches), rrdns (our own DNS server written in Go), a whole load of Lua (because we use OpenResty), a whole load of other services written in Go, ... Depending on the protocol (or version) traffic may or may not be served via nginx.

grey-area 10y ago
Thank you, would love to see a blog post like that outlining the architecture you have ended up with and how it all fits together.
garblegarble 10y ago
>nginx (our own fork since nginx folks won't accept all our patches) Is there any interest in publishing this whole fork? I know you already publish separate modules to github, beyond that is there crossover with nginx plus functionality they don't want to accept?
- jgrahamc 10y ago
  The problem with publishing it is that we have to maintain it and sometimes we put stuff in there that we wouldn't normally want to make public or it would be a pain to extract because it's linked to our infrastructure. Open sourcing stuff has a real cost. We do as much as we can.
daenney 10y ago
But as of today it's a mixture of nginx (our own fork since nginx folks won't accept all our patches) Could you elaborate, within the limits that you're allowed, on the patches that got rejected? I'm curious as to what they were about and why they didn't make it in.
- jgrahamc 10y ago
  For example, we support both SPDY and HTTP/2 and will do SPDY if an older client can't do HTTP/2. NGINX guys didn't want that. We tend to publish rejected stuff as patches: https://github.com/cloudflare/sslconfig/tree/master/patches https://github.com/cloudflare/sslconfig/tree/master/patches
  - daenney 10y ago
    Awesome, thanks! I can sort of understand not wanting to maintain the SPDY code but I can see how that would be useful to CF to have. I'm a bit disappointed the chacha20 ones aren't making it in. I'm curious about the Dynamic TLS records patch. Could you or someone else that understands what that's doing elaborate on what's going on?