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
_______________________________________________ Supervisor-users mailing list Supervisor-users@lists.supervisord.org https://lists.supervisord.org/mailman/listinfo/supervisor-users
