Replaced: Use Greenlock Express v3
See https://git.rootprojects.org/root/greenlock-express.js
"use strict"; var pkg = ; ; { // Serves on 80 and 443 // Get's SSL certificates magically! glx;}
OLD STUFF BELOW
(Preserved for historical reference)
| A Root Project | greenlock (lib) | greenlock-cli | greenlock-express | greenlock-cluster | greenlock-koa | greenlock-hapi |
greenlock-cluster
(previously letsencrypt-cluster)
Use automatic letsencrypt with node on multiple cores or even multiple machines.
- Take advantage of multi-core computing
- Process certificates in master
- Serve https from multiple workers
- Can work with any clustering strategy #1
Install
npm install --save greenlock-cluster@2.x
Usage
In a cluster environment you have some main file that boots your app and then conditionally loads certain code based on whether that fork is the master or just a worker.
In such a file you might want to define some of the options that need to be shared between both the master and the worker, like this:
boot.js
:
"use strict"; var cluster = ;var path = ;var os = ; var main;var sharedOptions = webrootPath: path // /tmp/acme-challenge // used by le-challenge-fs, the default plugin renewWithin: 14 * 24 * 60 * 60 * 1000 // 10 days before expiration debug: true; if clusterisMaster main = ; else main = ; main;
Master
We think it makes the most sense to load greenlock in master. This can prevent race conditions (see node-letsencrypt#45) as only one process is writing the to file system or database at a time.
The main implementation detail here is approveDomains(options, certs, cb)
for new domain certificates
and potentially agreeToTerms(opts, cb)
for new accounts.
The master takes the same arguments as node-greenlock
(challenge
, store
, etc),
plus a few extra (approveDomains
... okay, just one extra):
master.js
:
'use strict'; var cluster = ; moduleexports { var cores = ; var leMaster = ; cores;};
API
All options are passed directly to node-greenlock
(in other works, leMaster
is a greenlock
instance),
but a few are only actually used by greenlock-cluster
.
-
leOptions.approveDomains(options, certs, cb)
is special forgreenlock-cluster
, but will probably be included innode-greenlock
in the future (no API change). -
leMaster.addWorker(worker)
is added bygreenlock-cluster
and must be called for each new worker.
Worker
The worker takes similar arguments to node-greenlock
,
but only ones that are useful for determining certificate
renewal and for le.challenge.get
.
If you want to a non-default le.challenge
worker.js
:
"use strict"; moduleexports { var leWorker = ; { res; } var redirectHttps = ; var plainServer = ; plainServer; var server = ; server;};
API
node-greenlock
is not used directly by the worker,
but certain options are shared because certain logic is duplicated.
leOptions.renewWithin
is shared so that the worker knows how earlier to request a new certleOptions.renewBy
is passed tole-sni-auto
so that it staggers renewals betweenrenewWithin
(latest) andrenewBy
(earlier)leWorker.middleware(nextApp)
usesgreenlock/middleware
for GET-inghttp-01
, hencesharedOptions.webrootPath
leWorker.httpsOptions
has a default localhost certificate and theSNICallback
.
There are a few options that aren't shown in these examples, so if you need to change something that isn't shown here, look at the code (it's not that much) or open an issue.
Message Passing
The master and workers will communicate through process.on('message', fn)
, process.send({})
,
worker.on('message', fn)
and worker.send({})
.
All messages have a type
property which is a string and begins with LE_
.
All other messages are ignored.