| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
necessary for the stunnel to communicate
|
|
this already exists in class site_stunnel::setup which is instantiated in this
class
|
|
|
|
|
|
|
|
|
|
|
|
bigcouch cluster protocol communicate via the fqdn of
the neighbor hosts. So we need to bend all requests to
<fqdn>:4369 to localhost:400x (which is the entry of
an stunnel connection to the other neighbor)
|
|
|
|
|
|
|
|
cluster protocol
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
if we move, then we need to re-create the file on the next deploy
|
|
privileges, putting the unprivileged ones in as user webapp in couchdb.yml. This allows us to migrate the couchdb design docs on deployment, but use an unprivileged user the remainder of the time
|
|
|
|
|
|
|
|
haproxy listener 'bigcouch-in'. This haproxy listener is configured to listen on
port 4096 (arbitrarily chosen) and balance across the locally configured
stunnels to the bigcouch instances
It may be that we will need some additional haproxy options for handling
persistence, cookies, or other HTTP headers, I'm unsure as of this moment
|
|
|
|
|
|
|
|
|
|
|
|
|
|
rate limited).
|
|
requires that we use domain.full_suffix instead of provider.domain, whenever possible.
|
|
|
|
Until we have a proper load balancing setup
(see https://leap.se/code/issues/1994)
|
|
|
|
|
|
|
|
|
|
|
