wohali commented on a change in pull request #318: Add Caddy Server reverse-proxy config examples incl. cluster load balancing URL: https://github.com/apache/couchdb-documentation/pull/318#discussion_r210107054
########## File path: src/best-practices/caddy.rst ########## @@ -0,0 +1,167 @@ +.. Licensed under the Apache License, Version 2.0 (the "License"); you may not +.. use this file except in compliance with the License. You may obtain a copy of +.. the License at +.. +.. http://www.apache.org/licenses/LICENSE-2.0 +.. +.. Unless required by applicable law or agreed to in writing, software +.. distributed under the License is distributed on an "AS IS" BASIS, WITHOUT +.. WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the +.. License for the specific language governing permissions and limitations under +.. the License. + +.. _best-practices/Caddy: + +======================== +Caddy as a Reverse Proxy +======================== + +CouchDB recommends the use of `HAProxy`_ as a load balancer and reverse proxy. +The team's experience with using it in production has shown it to be superior +for configuration and monitoring capabilities, as well as overall performance. + +CouchDB's sample haproxy configuration is present in the `code repository`_ and +release tarball as ``rel/haproxy.cfg``. + +However, ``Caddy`` is a suitable alternative. Below are instructions on +configuring Caddy appropriately. + +.. _HAProxy: http://haproxy.org/ +.. _code repository: https://github.com/apache/couchdb/blob/master/rel/haproxy.cfg + +Basic configuration +=================== + +Here's a basic excerpt from a Caddyfile in +``/<path>/<to>/<site>/Caddyfile``. This will proxy all +requests from ``http(s)://domain.com/...`` to ``http://localhost:5984/...`` + +.. code-block:: text + + domain.com { + + import /path/to/other/config.caddy # logging, error handling etc. + + proxy / localhost:5984 { + transparent + } + + } + +Note that, because Caddy is https-by-default, you must explicitly include the +``http://`` protocol in the site address if you do NOT want Caddy +to automatically acquire and install an SSL certificate and begin accepting +``https`` connections on port 443. + +Reverse proxying CouchDB in a subdirectory with Caddy +===================================================== + +It can be useful to provide CouchDB as a subdirectory of your overall domain, +especially to avoid CORS concerns. Here's an excerpt of a basic Caddy +configuration that proxies the URL ``http(s)://domain.com/couchdb`` to +``http://localhost:5984`` so that requests appended to the subdirectory, such +as ``http(s)://domain.com/couchdb/db1/doc1`` are proxied to +``http://localhost:5984/db1/doc1``. + +.. code-block:: text + + domain.com { + + import /path/to/other/config.caddy # logging, error handling etc. + + proxy /couchdb localhost:5984 { + transparent + without /couchdb + } + + } + +Note that in the above configuration, the *Verify Installation* link in +Fauxton may not succeed. + +Reverse proxying + load balancing for CouchDB clusters +====================================================== + +Here's a basic excerpt from a Caddyfile in +``/<path>/<to>/<site>/Caddyfile``. This will proxy and evenly distribute all +requests from ``http(s)://domain.com/...`` among 3 CouchDB cluster nodes +at ``localhost:15984``, ``localhost:25984`` and ``localhost:35984``. + +Caddy will check the status, i.e. health, of each node every 5 seconds; +if a node goes down, Caddy will avoid proxying requests to that node until it +comes back online. + +.. code-block:: text + + domain.com { + + import /path/to/other/config.caddy # logging, error handling etc. + + proxy / http://localhost:15984 http://localhost:25984 http://localhost:35984 { + policy round_robin + health_check /_up + health_check_duration 5s + try_interval 500ms + timeout 1h Review comment: So the issue isn't specifically the timeouts, it's that HAProxy currently closes out every request on the backend (i.e. HAProxy <-> CouchDB) when a request finishes, so there really isn't a reuseable connection pool at the moment. I've personally seen some weird behaviour in production when people have used LB-managed connection pools under heavy load that cleared up when we disabled the connection pooling. I know for a fact it's especially bad if you use SSL between the reverse proxy (in the case I'm thinking of, it was an F5 BigIP) and CouchDB, but that has more to do with the poor implementation by Erlang of SSL. (We put a workaround into 2.2.0 for this via a `vm.args` config setting to auto-close any SSL connections after 300s.) So the only change I'm recommending to the docs here is not to recommend backend connection pooling, when we recommend the exact opposite in `haproxy.cfg`. You could choose to leave out that part of the configuration, as I did with the Nginx config (the point was to provide a working example, not a tuned high-perf one), or we can hold up this PR until I have time to build a test harness and compare pooled vs. unpooled, which might be months. My recommendation: remove the `timeout` line entirely. The Caddy default is 30s, which is fine, and if people want something higher, they can do that. If you want to match the haproxy config more exactly, I would add `keepalive 0`. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
