Name: hipache
Owner: SalesforceIQ
Description: Hipache: a distributed HTTP and websocket proxy
Created: 2018-01-23 00:44:59.0
Updated: 2018-04-03 16:53:26.0
Pushed: 2018-04-03 16:53:27.0
Homepage: http://blog.dotcloud.com/announcing-hipache-dotclouds-open-source-webs
Size: 359
Language: JavaScript
GitHub Committers
User | Most Recent Commit | # Commits |
---|
Other Committers
User | Most Recent Commit | # Commits |
---|
This project is officially deprecated due to upstream inactivity (last updated Feb 2015, 2d36766; last release Apr 2014, 0.3.1).
The following is a list of other HTTP proxies which might be suitable replacements depending on your needs:
traefik vulcand nginx haproxy httpd
This is the documentation for master
. If you are installing Hipache from NPM,
you should look at the documentation on the 0.3.x
branch.
Hipache (pronounce h?'pæt??
) is a fully-featured distributed
proxy designed to route high volumes of HTTP and WebSocket traffic to unusually
large numbers of virtual hosts, in a highly dynamic topology where backends are
added and removed several times per second. It is particularly well-suited for
PaaS (Platform-as-a-Service) and other environments that are both
business-critical and multi-tenant.
Hipache was originally developed at dotCloud, a popular platform-as-a-service, to replace its first-generation routing layer based on a heavily instrumented nginx deployment. It currently serves production traffic for tens of thousands of applications hosted on dotCloud. Hipache is based on the node-http-proxy library.
From the shell:
$ npm install hipache -g
The '-g' option will make the 'hipache' bin-script available system-wide (usually linked from '/usr/local/bin').
Basic Hipache configuration is described in a config.json
file. For example,
this is the configuration file for the master
version of Hipache (i.e. under
development, you should rather look at the documentation of the latest stable
version you installed):
{
"server": {
"debug": false,
"workers": 10,
"maxSockets": 100,
"tcpTimeout": 30,
"deadBackendTTL": 30,
"retryOnError": 3,
"accessLog": "/var/log/hipache/access.log",
"httpKeepAlive": false,
"deadBackendOn500": true,
"staticDir": null
},
"http": {
"port": 80,
"bind": ["127.0.0.1"]
},
"https": {
"bind": [],
"port": 443,
"ca": [],
"secureProtocol": "SSLv23_method",
"secureOptions": 50331648,
"key": "/etc/ssl/ssl.key",
"cert": "/etc/ssl/ssl.crt",
"passphrase": undefined,
"ciphers": "DH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+a RSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4",
"honorCipherOrder": true
},
"driver": "redis:",
"user": "www-data",
"group": "www-data"
}
10
if not specified.100
if not specified.0
, then the existing idle
timeout is disabled. Defaults to 30
seconds.30
seconds.3
./var/log/hipache/access.log
if not specified.false
(disabled).500
HTTP status code as critical
error if sets to true
. Defaults to true
.null
means it uses Hipache's
pages. Defaults to Hipache's static/
directory.80
.{address:
IP, port: PORT}
if you want to use a specific port on a specific ip.
Defaults to 127.0.0.1
.443
.SSLv23_method
(auto-negotiation).50331648
, and stands
for SSL_OP_NO_SSLv3 | SSL_OP_NO_SSLv2
(constants).true
.redis:
.root
(which you might do if you want to use a
privileged port), will drop root privileges as soon as it's bound. Defaults
to www-data
. Note that you MUST specify a user if you start Hipache as
root. You can specify user: 'root'
if you don't mind (strongly
discouraged!). You can use either user names or identifiers.root
, will downgrade group to this. If left
empty, will try to downgrade to a group named after the specified user
.
Defaults to www-data
.From the shell (defaults to using the config/config.json
file):
$ hipache
If you use a privileged port (e.g.: 80
):
$ sudo hipache
If you want to use a specific configuration file:
$ hipache --config path/to/someConfig.json
If you want to just test a specific configuration file:
$ hipache --dry --config path/to/someConfig.json
Managing multiple configuration files:
The default configuration file is config/config.json
. It's possible to have
different configuration files named config_<suffix>.json
, where the suffix is
the value of an environment variable named SETTINGS_FLAVOR
.
For instance, here is how to spawn the server with the config_test.json
configuration file in order to run the tests.
$ SETTINGS_FLAVOR=test hipache
All VHOST configuration is managed through a configuration backend (cf. drivers). This makes it possible to update the configuration dynamically and gracefully while the server is running, and have that state shared across workers and even across Hipache instances.
The recommended backend to use is Redis. It also makes it simple to write configuration adapters. It would be trivial to load a plain text configuration file into Redis (and update it at runtime).
Different configuration adapters will follow, but for the moment you have to provision the Redis manually.
Let's take an example to proxify requests to 2 backends for the hostname
www.dotcloud.com
. The 2 backends IP are 192.168.0.42
and 192.168.0.43
and
they serve the HTTP traffic on the port 80
.
redis-cli
is the standard client tool to talk to Redis from the terminal.
Follow these steps:
Create the frontend and associate an identifier:
$ redis-cli rpush frontend:www.dotcloud.com mywebsite
(integer) 1
The frontend identifer is mywebsite
, it could be anything.
Associate the 2 backends:
$ redis-cli rpush frontend:www.dotcloud.com http://192.168.0.42:80
(integer) 2
$ redis-cli rpush frontend:www.dotcloud.com http://192.168.0.43:80
(integer) 3
Review the configuration:
$ redis-cli lrange frontend:www.dotcloud.com 0 -1
1) "mywebsite"
2) "http://192.168.0.42:80"
3) "http://192.168.0.43:80"
While the server is running, any of these steps can be re-run without messing up with the traffic.
Upstart
Copy upstart.conf
to /etc/init/hipache.conf. Then you can use:
t hipache
hipache
art hipache
The configuration file used is /etc/hipache.json
.
Hipache supports several drivers for dynamic VHOST configurations.
This is the default backend.
If you want a master/slave Redis, specify a second url for the master, e.g.:
driver: ["redis://slave:port", "redis://master:port"]
. More generally, the
driver syntax is: redis://:password@host:port/database#prefix
- all parameter
are optional, hence just redis:
is a valid driver URI. You can omit this
entirely to use the local redis on the default port, which is the default.
See the drivers documentation.
See the drivers documentation.
See the drivers documentation.
As seen in the example above, multiple backends can be attached to a frontend.
All requests coming to the frontend are load-balanced across all healthy backends.
The backend to use for a specific request is determined randomly. Subsequent requests coming from the same client won't necessarily be routed to the same backend (since backend selection is purely random).
If a backend stops responding, it will be flagged as dead for a configurable amount of time. The dead backend will be temporarily removed from the load-balancing rotation.
To optimize response times and make use of all your available cores, Hipache uses the cluster module (included in NodeJS), and spreads the load across multiple NodeJS processes. A master process is in charge of spawning workers and monitoring them. When a worker dies, the master spawns a new one.
The memory footprint of Hipache tends to grow slowly over time, indicating a probable memory leak. A close examination did not turn up any memory leak in Hipache's code itself; but it doesn't prove that there is none. Also, we did not investigate (yet) thoroughly the code of Hipache's external dependencies, so the leaks could be creeping there.
While we profile Hipache's memory to further reduce its footprint, we implemented a memory monitoring system to make sure that memory use doesn't go out of bounds. Each worker monitors its memory usage. If it crosses a given threshold, the worker stops accepting new connections, it lets the current requests complete cleanly, and it stops itself; it is then replaced by a new copy by the master process.
You can alter the configuration stored in Redis at any time. There is no need to restart Hipache, or to signal it that the configuration has changed: Hipache will re-query Redis at each request. Worried about performance? We were, too! And we found out that accessing a local Redis is helluva fast. So fast, that it didn't increase measurably the HTTP request latency!
Hipache supports the WebSocket protocol. It doesn't do any fancy handling on its own and relies entirely on NodeJS and node-http-proxy.
Hipache supports SSL for “regular” requests as well as WebSocket upgrades. Hipache's default configuration matches latest recommandations for a secure and well-configured SSL/TLS layer.
When something wrong happens (e.g., a backend times out), or when a request for
an undefined virtual host comes in, Hipache will display an error page. Those
error pages can be customized, and a configuration parameter (server.staticDir
)
is available to specify where these custom pages are located.
When adding virtual hosts in Hipache configuration, you can specify wildcards.
E.g., instead (or in addition to) www.example.tld
, you can insert
*.example.tld
. Hipache will look for an exact match first, and then for a
wildcard one up to 5 subdomains deep, e.g. foo.bar.baz.qux.quux
will attempt
to match itself first, then *.bar.baz.qux.quux
, then *.baz.qux.quux
, etc.
Even though Hipache support passive health checks, it's also possible to run active health checks. This mechanism requires to run an external program (see third-party softwares below).
See CONTRIBUTING.md
Health-checkers:
A web interface to manage VHOSTs:
PaaS