Mozilla Circus 0.10 released
blog.mozilla.org
blog.mozilla.org
http://circus.readthedocs.org/en/latest/for-ops/circusweb/#c...
To paraphrase the docs, it's possible to manage a process and specify how many of that process I want to spawn (i.e. numprocesses = 5). I can also manage sockets and pass the managed sockets' fd to the managed processes.
First question, what is a typical use case for wanting multiple instances of a specific process?
Second question, if I am running multiple managed processes, how can they all bind to the same managed socket?
I guess there are some fundamental gaps in my understanding.
distribute the load. For example I can run several "redis workers" that gets jobs to do in a redis queue.
> Second question, if I am running multiple managed processes, how can they all bind to the same managed socket?
if you bind a socket and then forks 10 child processes, they can all accept connections on that socket and let the operating system do the load-balancing.
This is exactly how the Apache pre-fork model works.
So we use circus to maintain about a dozen apps and a few of them are django apps running under Mozilla's chaussette wsgi server. When we do an autodeploy via jenkins, jenkins will run circusctl to stop that worker, replace the code, futz a symlink, and then start the worker again. We front the apps with apache 2.4 (because it is as fast as nginx) + mod_proxy. That gives us ldap access control through apache and shiney LTSV formatted logs that tools like logstash or splunk can easily consume. We then front apache with a virtual ip provided by a tool such as keepalived for moar web scales.
For all in-flight requests, they will just hang as circus proper will hold onto the connection keeping the socket open. It will pass the socket to the first worker started once it is restarted. So during a deploy, a request might hang for a few milliseconds, but it never blows up. It is awesome in that it allows you 0 downtime deploys (at least for our django web stack it does).
Circus is a super elegant piece of software. Kudos to Mozilla for finally making a release. I'd been bugging them for awhile: https://github.com/mozilla-services/circus/issues/561
Edit:
Example of a 0 downtime restart config using uwsgi (instead of chaussette): https://github.com/scottkmaxwell/circus/commit/ef0000fe4ef3c...
Major differences:
* Circus uses ZeroMQ, Supervisor uses XML-RPC. * Circus is Python 3 compatible, Supervisor is Python 2 only * Circus will let you manage sockets - see http://circus.readthedocs.org/en/latest/for-ops/sockets/
Scott is actually the person who ported Circus to Python 3, so double kudos for him.
This was probably a wrong or overly simplified conclusion, but I know supervisor and it hasn't let me down yet - so for now I see no compelling reason to switch. Maybe it's one of those "you just have to try it" moments? :)
- you need python 3 - you have a complex start/stop sequence where you need to add some custom code - you manage many servers and want to quickly jump from one to another in the same web dashboard / CLI.
Otherwise, they both provide roughly the same things I'd say
You can check out the slides here: http://blog.ziade.org/slides/pyconireland2012/
It's also easier to run in the user space if you are not root
I used to for a PaaS and we made a mistake allowing one component to run any command what so ever. This can seem appealing; but it's a security risk extraordinaire.
Security keeps taking a back seat to useability :(
In the meantime the safest way to avoid any security issue is to run IPC-only zeromq sockets or to set properly a firefwall and to use an SSH tunnel. There's such an option in Circus, where you can pass the ssh server to circusctl.
also, read up http://circus.readthedocs.org/en/latest/design/security
I guess I am missing something.
e.g. 1/ notify the world you don't accept data anymore 2/ process what you have enqueued 3/ shutdown. In Fabien's use case 1 -> 3 can last for over 5 minutes.
my (perhaps snarky) comment was more to do with 'why be so careful' with the potential data failure (that circus handily addresses) when data is being placed in a 'leaky bucket' (redis) in the first place.
The web interface is certainly pretty, though.
But writing a new plugin is very easy, see : http://circus.readthedocs.org/en/latest/for-devs/writing-plu...
We would be happy to add in the built-in collection new useful plugins contributed by the community