Re: [Pharo-users] Starting a pool of worker images using command line parameters

Oct. 24, 2014

      ...
...
I'd like to know the development process of others, from SCM to
building, deploying and server provisioning.
I would say the standard approach is:
- use Monticello with any repo type
- split your code in some big modules, some private, some from public source
- have a single overarching Metacello configuration
- use zeroconf to build images
- optionally use a CI
Note that zeroconf handlers allow you to build images incrementally (the image is saved after each build), which is way faster than always starting from scratch.
I'm good then, I'm doing everything you listed except CI.
...
...
After a year o Pharo development I think I'm ready to embrace a CI
server (I already use scripts to build images), but I think I will
move all my repositories to git before.
These are orthogonal decisions, most CI jobs on the Pharo contribution server run against StHub.
I want git because I want to use BitBucket to store my code :)
...
...
However, my remote server provisioning is still manual, and too
rudimentary even for my own taste. If I could speed up this, I would
deliver features faster to my customers. Now everything runs inside a
two week sprint window.
...
I am not into provisioning myself, but more automation is always good, though sometimes setting up and maintaining all these things takes a lot of time as well.
It does take time, and "in theory" it works. I have this printed in my
desktop: http://xkcd.com/1319/ :)

Wrapping up, I implemented your no-commandline handler solution.

I added a few servers to the upstreams of my site nginx configuration like this:

upstream seaside {
  ip_hash;
  server 127.0.0.1:8080;
  server 127.0.0.1:8081;
  server 127.0.0.1:8082;
  server 127.0.0.1:8083;
}

upstream apimobile {
  server 127.0.0.1:8180;
  server 127.0.0.1:8181;
}

And added the following to my following supervisord.conf [1]

[program:app_webworker]
command=/home/trentosur/app/pharo app.image webworker.st 818%(process_num)1d
process_name=%(program_name)s_%(process_num)02d ; process_name expr
(default %(program_name)s)
numprocs=4
directory=/home/trentosur/app
autostart=true
autorestart=true
user=trentosur
stopasgroup=true
killasgroup=true

[program:app_apiworker]
command=/home/trentosur/app/pharo app.image apiworker.st 918%(process_num)1d
process_name=%(program_name)s_%(process_num)02d ; process_name expr
(default %(program_name)s)
numprocs=2
directory=/home/trentosur/app
autostart=true
autorestart=true
user=trentosur
stopasgroup=true
killasgroup=true

Then this will spawn a [numproc] number of monitored processes, using
the process number (process_num, in terms of pool) as a parameter to
the startup script.
The good thing here is, IMO, I can add more workers without having to
modify anything on the Pharo side, it is... I can delegate this to
regular sysadmin :)

Best regards,

Esteban A. Maringolo

[1] http://supervisord.org/