On 26.01.2011 17:50, Roberto De Ioris wrote:
> After lot of words, comments and proposal i have finally committed a first
> version of the uWSGI Emperor.
>
> For the newcomers in the list, the uWSGI Emperor is a special uWSGI
> instance that will manages other uWSGI instances. Its main purpose is the
> massive hosting of different apps without the limits of multiple
> interpreters or without headaches managing tons of different uWSGI
> instances.
>
> This is only a base for future development so feel free to spit out ideas
> or improvements.
Thanks, Roberto! It's really useful feature. In my efforts for
packaging uWSGI for Debian, I've implemented something like Emperor mode
in init.d script (but just for one-time starting/stopping uWSGI
instances). It's hard to support such a complex init.d script, so native
Emperor mode is very much appreciated.
And I'd want to offer several improvements for Emperor mode:
1. passing some options to instances with possibility of templating
in option value
2. hooks for phases of starting/stopping instances (namely:
pre-start, post-start, pre-stop, post-stop).
Firstly, how command line for uWSGI Emperor could've looked with using
of offered improvements (new options are started from --vassal-pidfile):
/usr/bin/uwsgi --emperor /etc/uwsgi --pidfile
/var/run/uwsgi/emperor.pid --daemonize
/var/log/uwsgi/emperor/uwsgi-emperor.log --vassal-pidfile
/var/run/uwsgi/%n/pid --vassal-socket /var/run/uwsgi/%n/socket
--vassal-logto /var/log/uwsgi/%n.log --vassal-pre-start-hook
/usr/lib/uwsgi/hooks/pre-start --vassal-post-stop-hook
/usr/lib/uwsgi/hooks/post-stop
1. --vassal-pidfile, --vassal-socket and --vassal-logto are options
passed to started instances as --pidfile, --socket and --logto. '%n' is
replaced for name of configuration file (without extension).
For example, if uWSGI Emperor noticed configuration file
'/etc/uwsgi/cool-site.yml', it'll start instance '/usr/bin/uwsgi
--pidfile /var/run/uwsgi/cool-site/pid --socket
/var/run/uwsgi/cool-site/socket --log-to /var/log/uwsgi/cool-site.log
--yaml /etc/uwsgi/cool-site.yml'.
Or, options could be passed to started instance "implicitly", as
environment variables. So Emperor exports variables
UWSGI_PIDFILE=/var/run/uwsgi/cool-site/pid,
UWSGI_SOCKET=/var/run/uwsgi/cool-site/socket and
UWSGI_LOGTO=/var/log/uwsgi/cool-site.log and starts instance in modified
environment with more sane command line '/usr/bin/uwsgi --yaml
/etc/uwsgi/cool-site.yml'.
2. Hooks are simple executables (shell scripts or any other scripts or
compiled executables) which are invoked in corresponding phase with
passing emperor and instance options and configuration file name
(without extension) as environment variables.
For example, pre-start hook (/usr/lib/uwsgi/hooks/pre-start) could've
looked like
#!/bin/sh
RUNDIR=/var/run/uwsgi/$UWSGI_EMPEROR_VASSAL_CONF_NAME
if [ -z $UWSGI_UID ]; then
UWSGI_UID=www-data
fi
if [ -z $UWSGI_GID ]; then
UWSGI_GID=www-data
fi
/usr/bin/install -o $UWSGI_UID -g $UWSGI_GID -d $RUNDIR
Suppose that uWSGI Emperor noticed configuration file
'/etc/uwsgi/cool-site.yml' with following content:
uwsgi:
uid: cool-site-user
Then Emperor (before starting of new instance) will run pre-start hook
with following environment:
* UWSGI_EMPEROR=/etc/uwsgi
* UWSGI_EMPEROR_PIDFILE=/var/run/uwsgi/emperor.pid
* UWSGI_EMPEROR_DAEMONIZE=/var/log/uwsgi/emperor/uwsgi-emperor.log
* UWSGI_EMPEROR_VASSAL_PIDFILE=/var/run/uwsgi/cool-site/pid
* UWSGI_EMPEROR_VASSAL_SOCKET=/var/run/uwsgi/cool-site/socket
* UWSGI_EMPEROR_VASSAL_LOGTO=/var/log/uwsgi/cool-site.log
* UWSGI_EMPEROR_VASSAL_CONF_NAME=cool-site
* UWSGI_EMPEROR_VASSAL_PRE_START_HOOK=/usr/lib/uwsgi/hooks/pre-start
* UWSGI_EMPEROR_VASSAL_POST_STOP_HOOK=/usr/lib/uwsgi/hooks/post-stop
* UWSGI_UID=cool-site-user
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
