Hello

The best way is going with
Emperor<http://uwsgi-docs.readthedocs.org/en/latest/Emperor.html>AND
supervisor <http://supervisord.org/>, as officially
recommended<http://uwsgi-docs.readthedocs.org/en/latest/WSGIquickstart.html#automatically-starting-uwsgi-on-boot>
by
uWSGI docs.
In this case, supervisor (which is a sort of init.d) serves to start
Emperor at boot time.

broodloord/zerg actually are an advanced usage of the Emperor, so I think
they are not an option for you at the moment.

But in your case Emperor is not enough: for managing Sentry you have to use
supervisor (there isn't a uWSGI plugin for it, as far as I know), as stated
in Sentry's docs:
http://sentry.readthedocs.org/en/latest/quickstart/index.html#running-sentry-as-a-service
But hey! No problem: you will already have setup supervisor, following my
and uWSGI's guidelines :)

Well, one thing is sure: supervisor is a must (as sentry needs it).
So if you'd like a cheaper option, you may use supervisor only (no
emperor), and have it manage all the instances.
Have a look at an example configuration for a process to be managed by
supervisord:
http://supervisord.org/configuration.html#program-x-section-example
Moreover, with the supervisor-only option, *you can cut&paste the commands
you are using right now* in the config of
supervisor<http://supervisord.org/configuration.html#program-x-section-example>
('command'
parameter): no efforts!
And it's good to learn Supervisor because you will certainly find other
cases where you will need it.

Anyway, setting up Emperor is a bunch of devops time very well invested!
I know it for sure.. I've recently setup an architecture for automating the
development process of Django projects for a web agency. uWSGI Emperor
helped sooo much!
Now you have only one web app served by uWSGI? Well if you're going to have
2-3-4 web apps, you will definitely need it.



*Alberto Scotto*

skype:dasgazzo
http://about.me/alb_i986


2013/5/30 Jonathan Vanasco <[email protected]>

> Hi.
>
> I originally deployed a Pyramid app in production like this:
>
>         nginx -> uwsgi -> pryamid
>
> uwsgi is for the app started with this `uwsgi --options` command
>
> That was great, but my needs changed as I've had to launch new
> applications on the same server.  I'm a bit confused with all the options.
>
> my (current) needs are starting to look like this:
>
>         WebApplication – 8-16 processes
>         Graphite (stats) – 1-2 processes
>         Sentry (stats) – 1-2 processes
>
>
> I'm not sure what makes more sense:
>
>         1. managing a separate uwsgi master process + processes for each
> of the 3+ apps
>         2. using an emperor process handle the 3+ apps
>
> the broodloord/zerg stuff looks really interesting, and like it might
> benefit us a lot.  but that would mean switching from the command-line
> version to the  file based config -- and that will be a chunk of devops
> time.
>
> can someone weigh in with that they'd do ?
> _______________________________________________
> uWSGI mailing list
> [email protected]
> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
>
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to