On 10/05/2018 15:30, Esteban A. Maringolo wrote:

How would you know when to kill the running vm+image? It might have active sessions.

If you don't care about that, what I used to manage a bunch of "worker images" (process groups) with supervisord [1], so in that case you'd stop all the related workers, copy the new image, and start the workers again.

My supervisord.conf entry for a pool of working images was:

[program:psworker] command=/home/trentosur/perfectstore/pharo-vm/pharo --nodisplay /home/trentosur/perfectstore/ps.image worker.st 818%(process_num)1d process_name=%(program_name)s_%(process_num)02d ; process_name expr (default %(program_name)s) numprocs=2 directory=/home/trentosur/perfectstore autostart=false autorestart=true user=trentosur stopasgroup=true killasgroup=true

Part of the worker.st file handling the port number was:

"Seaside server start" Smalltalk isHeadless ifTrue: [ Smalltalk commandLine arguments ifEmpty: [ Transcript show: 'No port parameter was specified.'; cr. Smalltalk quitPrimitive. ] ifNotEmpty: [:args | | port | port := args first asNumber asInteger. Transcript show: 'Starting worker image at port ', port asString; cr. ZnZincServerAdaptor startOn: port. ZnZincServerAdaptor default server debugMode: false. ] ] ifFalse: [ | port | port := 8080. Transcript show: 'Starting worker image at port ', port asString; cr. ZnZincServerAdaptor startOn: port. ZnZincServerAdaptor default server debugMode: true. ].

I hope it helps.

Best regards,

I forgot to mention - you are correct that this isn’t a good solution for a widely use production system - as I think you would want to use a load balancer to stop traffic to one image while sessions complete before terminating it. OR - there must be some cloud based solution for this these days - presumably using docker…

Still for hobby experiments - this and Digital Ocean seems ideal.

Tim

On 10 May 2018, at 22:17, Tim Mackinnon tim@testit.works wrote:

Ah - I see (hadn’t thought about having a configurable port number),

So if Ive understood correctly I could install supervisord with a config file like yours.

Then on completion of my build, I could sftp my new image up to DO, and then execute a command like: supervisorctl restart psworker?

Doing a check does seem to show lots of people use either it or monit (the latter being a bit more complicated).

Thanks for the help - this is my next learning step.

Tim

...

On 10 May 2018, at 19:47, Esteban A. Maringolo emaringolo@gmail.com wrote:

On 10/05/2018 15:30, Esteban A. Maringolo wrote:

...

How would you know when to kill the running vm+image? It might have active sessions.

If you don't care about that, what I used to manage a bunch of "worker images" (process groups) with supervisord [1], so in that case you'd stop all the related workers, copy the new image, and start the workers again.

My supervisord.conf entry for a pool of working images was:

[program:psworker] command=/home/trentosur/perfectstore/pharo-vm/pharo --nodisplay /home/trentosur/perfectstore/ps.image worker.st 818%(process_num)1d process_name=%(program_name)s_%(process_num)02d ; process_name expr (default %(program_name)s) numprocs=2 directory=/home/trentosur/perfectstore autostart=false autorestart=true user=trentosur stopasgroup=true killasgroup=true

Part of the worker.st file handling the port number was:

"Seaside server start" Smalltalk isHeadless ifTrue: [ Smalltalk commandLine arguments ifEmpty: [ Transcript show: 'No port parameter was specified.'; cr. Smalltalk quitPrimitive. ] ifNotEmpty: [:args | | port | port := args first asNumber asInteger. Transcript show: 'Starting worker image at port ', port asString; cr. ZnZincServerAdaptor startOn: port. ZnZincServerAdaptor default server debugMode: false. ] ] ifFalse: [ | port | port := 8080. Transcript show: 'Starting worker image at port ', port asString; cr. ZnZincServerAdaptor startOn: port. ZnZincServerAdaptor default server debugMode: true. ].

I hope it helps.

Best regards,

-- Esteban A. Maringolo _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

---

seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Am 10.05.2018 um 23:55 schrieb Tim Mackinnon tim@testit.works:

I forgot to mention - you are correct that this isn’t a good solution for a widely use production system - as I think you would want to use a load balancer to stop traffic to one image while sessions complete before terminating it. OR - there must be some cloud based solution for this these days - presumably using docker…

All of this can be done. It just depends on the learning curve you want to take. I successfully escaped the unix/linux hell (used daemontools, monti, systemd before) for my services and entered docker hell :P I use docker swarm and that has everything you describe above. I can deploy any number of images across all my machines with ease. There is a zero-downtime option so there is no service interruption. But the amount of time I had to put into there was massive. So while I would encourage the usage of docker I’m not sure it is for everyone. The medium heavy approach for you should be:

1. nginx as frontend server. This proxies all requests to a docker service traefik (https://traefik.io/ https://traefik.io/) 2. traefik listens on docker whenever a container is started and adds it to the load balancing routine. 3. You deploy any number of your application and they will automatically load balanced.

Norbert

Still for hobby experiments - this and Digital Ocean seems ideal.

Tim

...

On 10 May 2018, at 22:17, Tim Mackinnon tim@testit.works wrote:

Ah - I see (hadn’t thought about having a configurable port number),

So if Ive understood correctly I could install supervisord with a config file like yours.

Then on completion of my build, I could sftp my new image up to DO, and then execute a command like: supervisorctl restart psworker?

Doing a check does seem to show lots of people use either it or monit (the latter being a bit more complicated).

Thanks for the help - this is my next learning step.

Tim

...

On 10 May 2018, at 19:47, Esteban A. Maringolo emaringolo@gmail.com wrote:

On 10/05/2018 15:30, Esteban A. Maringolo wrote:

...

How would you know when to kill the running vm+image? It might have active sessions.

If you don't care about that, what I used to manage a bunch of "worker images" (process groups) with supervisord [1], so in that case you'd stop all the related workers, copy the new image, and start the workers again.

My supervisord.conf entry for a pool of working images was:

[program:psworker] command=/home/trentosur/perfectstore/pharo-vm/pharo --nodisplay /home/trentosur/perfectstore/ps.image worker.st 818%(process_num)1d process_name=%(program_name)s_%(process_num)02d ; process_name expr (default %(program_name)s) numprocs=2 directory=/home/trentosur/perfectstore autostart=false autorestart=true user=trentosur stopasgroup=true killasgroup=true

Part of the worker.st file handling the port number was:

"Seaside server start" Smalltalk isHeadless ifTrue: [ Smalltalk commandLine arguments ifEmpty: [ Transcript show: 'No port parameter was specified.'; cr. Smalltalk quitPrimitive. ] ifNotEmpty: [:args | | port | port := args first asNumber asInteger. Transcript show: 'Starting worker image at port ', port asString; cr. ZnZincServerAdaptor startOn: port. ZnZincServerAdaptor default server debugMode: false. ] ] ifFalse: [ | port | port := 8080. Transcript show: 'Starting worker image at port ', port asString; cr. ZnZincServerAdaptor startOn: port. ZnZincServerAdaptor default server debugMode: true. ].

I hope it helps.

Best regards,

-- Esteban A. Maringolo _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

---

seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

---

seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

This has proved a very interesting exercise, and Norbert - I will add docker swarm to my todo list… thanks. Sven - I think I’ve just learned about systemd when learning how to autostart supervisord (how ironic).

Just for completeness to run supervisord = here’s the systemd sciprt ;) - https://gist.github.com/macta/0f30e73a6f5670f301795eacd25f6f0e https://gist.github.com/macta/0f30e73a6f5670f301795eacd25f6f0e

Tim

On 11 May 2018, at 14:54, Esteban A. Maringolo emaringolo@gmail.com wrote:

On 11/05/2018 10:39, Norbert Hartl wrote:

...

All of this can be done. It just depends on the learning curve you want to take. I successfully escaped the unix/linux hell (used daemontools, monti, systemd before) for my services and entered docker hell :P I use docker swarm and that has everything you describe above. I can deploy any number of images across all my machines with ease. There is a zero-downtime option so there is no service interruption. But the amount of time I had to put into there was massive. So while I would encourage the usage of docker I’m not sure it is for everyone. The medium heavy approach for you should be:

1. nginx as frontend server. This proxies all requests to a docker

service traefik (https://traefik.io/) 2. traefik listens on docker whenever a container is started and adds it to the load balancing routine. 3. You deploy any number of your application and they will automatically load balanced.

Why nginx+traefik? Isn't the latter supposed to provide reverse proxying as well?

A blog post/tutorial about how this was made would save many from investing massive time into it. :)

I'm interested in how you implement the zero-downtime.

Regards!

-- Esteban A. Maringolo _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

This is very interesting - as I was taking the hobbyist view I completely overlooked what docker solutions there are.

Would like to hear more - and whether there is something that’s easy/cheap to play with part time. I would hope for something I can just stick my Pharo images in and it takes care of restarts etc and could scale if my hobby grew.

I’m understanding your experience is that it’s still not quite that simple?

I really love the simplicity of lambda - and it’s pretty easy to run Pharo there too - but could you write a web app that way? They say no - but there are some attractions to escape this nonsense we still face today.

You’ve really got me thinking now...

Tim

Sent from my iPhone

On 11 May 2018, at 14:39, Norbert Hartl norbert@hartl.name wrote:

...

Am 10.05.2018 um 23:55 schrieb Tim Mackinnon tim@testit.works:

I forgot to mention - you are correct that this isn’t a good solution for a widely use production system - as I think you would want to use a load balancer to stop traffic to one image while sessions complete before terminating it. OR - there must be some cloud based solution for this these days - presumably using docker…

All of this can be done. It just depends on the learning curve you want to take. I successfully escaped the unix/linux hell (used daemontools, monti, systemd before) for my services and entered docker hell :P I use docker swarm and that has everything you describe above. I can deploy any number of images across all my machines with ease. There is a zero-downtime option so there is no service interruption. But the amount of time I had to put into there was massive. So while I would encourage the usage of docker I’m not sure it is for everyone. The medium heavy approach for you should be:

1. nginx as frontend server. This proxies all requests to a docker service traefik (https://traefik.io/)
2. traefik listens on docker whenever a container is started and adds it to the load balancing routine.
3. You deploy any number of your application and they will automatically load balanced.

Norbert

...

Still for hobby experiments - this and Digital Ocean seems ideal.

Tim

...

On 10 May 2018, at 22:17, Tim Mackinnon tim@testit.works wrote:

Ah - I see (hadn’t thought about having a configurable port number),

So if Ive understood correctly I could install supervisord with a config file like yours.

Then on completion of my build, I could sftp my new image up to DO, and then execute a command like: supervisorctl restart psworker?

Doing a check does seem to show lots of people use either it or monit (the latter being a bit more complicated).

Thanks for the help - this is my next learning step.

Tim

...

On 10 May 2018, at 19:47, Esteban A. Maringolo emaringolo@gmail.com wrote:

...

On 10/05/2018 15:30, Esteban A. Maringolo wrote: How would you know when to kill the running vm+image? It might have active sessions.

If you don't care about that, what I used to manage a bunch of "worker images" (process groups) with supervisord [1], so in that case you'd stop all the related workers, copy the new image, and start the workers again.

My supervisord.conf entry for a pool of working images was:

[program:psworker] command=/home/trentosur/perfectstore/pharo-vm/pharo --nodisplay /home/trentosur/perfectstore/ps.image worker.st 818%(process_num)1d process_name=%(program_name)s_%(process_num)02d ; process_name expr (default %(program_name)s) numprocs=2 directory=/home/trentosur/perfectstore autostart=false autorestart=true user=trentosur stopasgroup=true killasgroup=true

Part of the worker.st file handling the port number was:

"Seaside server start" Smalltalk isHeadless ifTrue: [ Smalltalk commandLine arguments ifEmpty: [ Transcript show: 'No port parameter was specified.'; cr. Smalltalk quitPrimitive. ] ifNotEmpty: [:args | | port | port := args first asNumber asInteger. Transcript show: 'Starting worker image at port ', port asString; cr. ZnZincServerAdaptor startOn: port. ZnZincServerAdaptor default server debugMode: false. ] ] ifFalse: [ | port | port := 8080. Transcript show: 'Starting worker image at port ', port asString; cr. ZnZincServerAdaptor startOn: port. ZnZincServerAdaptor default server debugMode: true. ].

I hope it helps.

Best regards,

-- Esteban A. Maringolo _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

---

seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

---

seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

---

seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Tim,

On 10/05/2018 18:17, Tim Mackinnon wrote:

Ah - I see (hadn’t thought about having a configurable port number),

I had a configurable port number, and at the peak of use of the now decommissioned app I had up to 8 worker images running, defined as upstream servers in nginx as well, so changing numprocs in supervisord.conf also required modifying the nginx website conf.

So if Ive understood correctly I could install supervisord with a config file like yours.

Then on completion of my build, I could sftp my new image up to DO, and then execute a command like: supervisorctl restart psworker?

Exactly. I didn't have a CI, but I did build images from scratch, and my script did exactly that, but using ssh and scp instead.

Doing a check does seem to show lots of people use either it or monit (the latter being a bit more complicated).

I found the same thing, supervisord seemed simpler to get it up and running. And once working reliably... why change it? :)

Regards,

I don't know if something changed, the setup I shared used Pharo 4 and supervisord v3.0b2.

There might have been changes in the VM parameters. Although the image parameter is still there, and it is the most important.

You should ask in the pharo-list.

On 11/05/2018 07:41, Tim Mackinnon wrote:

Hi - I’ve been trying supervisord (which looks good) - however I can’t get pharo to start - I just get "pharo: ERROR (spawn error)”, and tailing the log in supervisorctl just shows me pharo spewing out the command line help. Its like the image parameter isn’t being passed along  - very weird and frustrating.

Tim

...

On 10 May 2018, at 19:47, Esteban A. Maringolo <emaringolo@gmail.com mailto:emaringolo@gmail.com> wrote:

On 10/05/2018 15:30, Esteban A. Maringolo wrote:

...

How would you know when to kill the running vm+image? It might have active sessions.

If you don't care about that, what I used to manage a bunch of "worker images" (process groups) with supervisord [1], so in that case you'd stop all the related workers, copy the new image, and start the workers again.

My supervisord.conf entry for a pool of working images was:

[program:psworker] command=/home/trentosur/perfectstore/pharo-vm/pharo --nodisplay /home/trentosur/perfectstore/ps.image worker.st http://worker.st/ 818%(process_num)1d process_name=%(program_name)s_%(process_num)02d ; process_name expr (default %(program_name)s) numprocs=2 directory=/home/trentosur/perfectstore autostart=false autorestart=true user=trentosur stopasgroup=true killasgroup=true

Part of the worker.st http://worker.st/ file handling the port number was:

"Seaside server start" Smalltalk isHeadless ifTrue: [  Smalltalk commandLine arguments    ifEmpty: [      Transcript show: 'No port parameter was specified.'; cr.      Smalltalk quitPrimitive. ]    ifNotEmpty: [:args |      | port |      port := args first asNumber asInteger.      Transcript show: 'Starting worker image at port ', port asString; cr.      ZnZincServerAdaptor  startOn: port.      ZnZincServerAdaptor default server debugMode: false.    ]  ]  ifFalse: [      | port |      port := 8080.      Transcript show: 'Starting worker image at port ', port asString; cr.      ZnZincServerAdaptor  startOn: port.      ZnZincServerAdaptor default server debugMode: true.    ].

I hope it helps.

Best regards,

-- Esteban A. Maringolo _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org mailto:seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

---

seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 11/05/2018 08:45, Tim Mackinnon wrote:

Good to know you were pleased with it - I notice the Enterprise pharo chapter uses monit - perhaps I may have to try that in instead (but supervisord seemed much simpler). One small thought - I’ve been using my default root login account  (the tutorials showing Digital Ocean all seem to do this) - I have a nagging feeling this isn’t so cool - but I’m not sure what the general practice is these days with cloud infrastructure?

I normally don't, but mostly because the VPS I use are not "disposable", so I lock it down as if it were a physical server.

It is not "cloud" as in that my the servers have a name, not a number :) Using the analogy [1], my VPSs are pets, not cattle.

Presumably supervisord needs to run as root? But my image doesn’t - still I would have expected that it would all run fine as root (if not a bit dangerously?)

supervisord will run as root, and in the process config you can specify the user for it (for some reason I omitted that last line, sorry)

In my previous example, you should add this to the config: user=trentosur ; setuid to this UNIX account to run the program

I avoid running my software as root, in particular if the server where it is hosted contains information that shouldn't be read by anybody but me.

[1] https://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/ , there are also "insects" now with microservices/lambda.

Have you also looked at systemd ? It is the new Linux thing for a while now. I use it successfully (https://github.com/svenvc/pharo-server-tools). It takes some getting used to, but it does work.

On 11 May 2018, at 14:23, Tim Mackinnon tim@testit.works wrote:

Hey thanks for the prompts - I figured out my starting problem I was using —no-default-preferences as a VM parameter at its not, its an image parameter so it comes AFTER the image name on the command line… subtle but its the kind of thing that drives you crazy.

I will look at what it takes to add users to my DO account and run that way (its better as you suggest)

Tim

...

On 11 May 2018, at 13:02, Esteban A. Maringolo emaringolo@gmail.com wrote:

On 11/05/2018 08:45, Tim Mackinnon wrote:

...

Good to know you were pleased with it - I notice the Enterprise pharo chapter uses monit - perhaps I may have to try that in instead (but supervisord seemed much simpler). One small thought - I’ve been using my default root login account (the tutorials showing Digital Ocean all seem to do this) - I have a nagging feeling this isn’t so cool - but I’m not sure what the general practice is these days with cloud infrastructure?

I normally don't, but mostly because the VPS I use are not "disposable", so I lock it down as if it were a physical server.

It is not "cloud" as in that my the servers have a name, not a number :) Using the analogy [1], my VPSs are pets, not cattle.

...

Presumably supervisord needs to run as root? But my image doesn’t - still I would have expected that it would all run fine as root (if not a bit dangerously?)

supervisord will run as root, and in the process config you can specify the user for it (for some reason I omitted that last line, sorry)

In my previous example, you should add this to the config: user=trentosur ; setuid to this UNIX account to run the program

I avoid running my software as root, in particular if the server where it is hosted contains information that shouldn't be read by anybody but me.

[1] https://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/ , there are also "insects" now with microservices/lambda.

-- Esteban A. Maringolo _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

---

seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Thanks everyone for sharing these - having some updated examples is very useful (hopefully to others too).

Pierce you’ve also reminded me that the pharo zero conf run script needs updating to use those newer vm params like you have.

Tim

Sent from my iPhone

On 13 May 2018, at 03:56, Pierce Ng pierce@samadhiweb.com wrote:

...

On Fri, May 11, 2018 at 12:45:55PM +0100, Tim Mackinnon wrote: One small thought - I’ve been using my default root login account (the tutorials showing Digital Ocean all seem to do this) - I have a nagging feeling this isn’t so cool - but I’m not sure what the general practice is these days with cloud infrastructure?

I use daemontools. It runs as root and starts Pharo as a dedicated uid configured in its run file directly:

#!/bin/sh /usr/bin/setuidgid app1 \ /pkg/pharo5vm/gopharo -vm-display-null -vm-sound-null smallcms1.image --no-quit

gopharo is a script:

#!/bin/sh PHAROVMPATH=$(dirname `readlink -f "$0"`) LD_LIBRARY_PATH="$PHAROVMPATH" exec "$PHAROVMPATH/pharo" $@ &

I use gopharo because I place my application-specific shared libraries (such as custom-built libsqlite.so) in the Pharo VM directory, which is /pkg/pharo5vm/ in my setup.

Pierce

---

seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside