ben
2015-08-16 11:37:51 UTC
Hello all,
I'm working in a production supervisor environment, where we need a rolling
upgrade that holds the listening socket.
It's a single process handling a single inbound tcp listening socket, but
one where the downtime caused by a normal upgrade has a considerable
disruption cost.
I have a working solution in node, leveraging nodejs/cluster, to hold the
socket, and maintain a 'cluster of 1', so that the upgrade process can
install, a new process spawns and prepares to listen, signalling readiness,
and then the master kills the old child, and signals the new process to
start listening on the shared fd. But this means a middle-man process
between supervisor and my actual service. (This can be generically achieved
via https://github.com/zimbatm/socketmaster and
https://github.com/pusher/crank.)
It feels like I should be able to get this directly out of supervisor, but
I haven't figured out how. I can do the FD handoffs via fcgi, but I haven't
figured out how to manage the process control aspects. Supposing I have
fcgi configured with a 'numprocs=1' setting, I would need to, in order:
supervisord config: { numprocs=1 }
- install new service code (external to supervisord?)
- superd spawns second service process
- service loads up to the point of calling listen, signals "ready", awaits
"go"
- superd kills original service proc, waits for death
- superd signals "go" to waiting new/second process
Is this doable in the current supervisord world? numprocs doesn't seem
dynamic enough to handle this, and the signalling and waiting is also a bit
strange. I found a couple plugins that touch elements of this, but nothing
really in the ballpark. Anybody have experience, or other notions of how to
go about doing this? Worst case, I just wrap the proc with socketmaster or
crank; but there's gotta be something better.
Thanks :)
ben
I'm working in a production supervisor environment, where we need a rolling
upgrade that holds the listening socket.
It's a single process handling a single inbound tcp listening socket, but
one where the downtime caused by a normal upgrade has a considerable
disruption cost.
I have a working solution in node, leveraging nodejs/cluster, to hold the
socket, and maintain a 'cluster of 1', so that the upgrade process can
install, a new process spawns and prepares to listen, signalling readiness,
and then the master kills the old child, and signals the new process to
start listening on the shared fd. But this means a middle-man process
between supervisor and my actual service. (This can be generically achieved
via https://github.com/zimbatm/socketmaster and
https://github.com/pusher/crank.)
It feels like I should be able to get this directly out of supervisor, but
I haven't figured out how. I can do the FD handoffs via fcgi, but I haven't
figured out how to manage the process control aspects. Supposing I have
fcgi configured with a 'numprocs=1' setting, I would need to, in order:
supervisord config: { numprocs=1 }
- install new service code (external to supervisord?)
- superd spawns second service process
- service loads up to the point of calling listen, signals "ready", awaits
"go"
- superd kills original service proc, waits for death
- superd signals "go" to waiting new/second process
Is this doable in the current supervisord world? numprocs doesn't seem
dynamic enough to handle this, and the signalling and waiting is also a bit
strange. I found a couple plugins that touch elements of this, but nothing
really in the ballpark. Anybody have experience, or other notions of how to
go about doing this? Worst case, I just wrap the proc with socketmaster or
crank; but there's gotta be something better.
Thanks :)
ben