On 14 Aug 2014, at 15:21, François Stephany <tulipe.mouta...@gmail.com> wrote:
> Good idea, I add monit as one of the next step. > > Load balancing is not supported at all. But we could change the nginx config > file to load balance between two images. And maybe make something for Seaside > and its state (sticky sessions?). I haven't done enough of this to actually > take an informed decision. Here is some information on how I did it recently using nginx and Seaside: http://forum.world.st/Nginx-Load-Balancing-Experiences-td4750823.html The stickiness is by client IP. It is also possible to do route based stickiness in Seaside and using Zinc (see ZnServer>>#route:), but I know only how to do that with Apache 2 (it is a paying option for nginx sadly). Of course, in most cases you will have to do some session state sharing between instances. I used memcached for that. > I'll update the README to be more clear about what is done behind the scene. > Showing the tree of directories created by HelloPharo will be worth a > thousand words (especially if you've used capistrano before). > > > On Thu, Aug 14, 2014 at 3:13 PM, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > On 14 Aug 2014, at 13:08, François Stephany <tulipe.mouta...@gmail.com> wrote: > > > Oh, I forgot to mention Sven. He wrote the original > > http://stfx.eu/pharo-server/ > > We basically stole all his Bash-fu to build the main script: > > > > https://github.com/fstephany/hello-pharo/blob/master/app > > > > Thanks a lot Sven! > > You're welcome, François. BTW, I am still using that script for all my > deploys. > > I didn't immediately see it, but does your solution include something for > process monitoring and automatic restarts (like monit) and/or some basic load > balancing ? In my experience the combination of these two makes for a more > robust solution. Maybe that is the next step ;-) > > Sven > > > On Thu, Aug 14, 2014 at 1:02 PM, François Stephany > > <tulipe.mouta...@gmail.com> wrote: > > Hello, > > > > At Ta Mère, we are used to deploy Ruby/Rails application with Heroku or on > > VPS with Capistrano. Almost everybody uses the same tools and techniques in > > the Rails community so deployment is quite easy once you grasp the process. > > > > The same process was quite frustrating with Pharo. To solve that, we've > > built HelloPharo. It is a tool to deploy small apps to a Linux VPS/VM. > > > > It is heavily inspired by Capistrano, it prones convention over > > configuration and it wants to be full stack (e.g., serve the assets, > > restart the processes). It is built with Ansible. > > > > We haven't released a fixed version yet but the tool starts to be in a > > good-enough shape to be shown. We want to grab some feedback and fix the > > most obvious limitations (see the README for more) before releasing version > > 0.1.0. > > > > If you or your company uses a well defined process to deploy pharo webapps, > > we are all ears. We think that having a canonical way to deploy simple apps > > is a must if we want to see wider Pharo adoption for small web companies. > > This process *must* be Unix friendly if we want to attract Python or Ruby > > people. Most of them are Devops anyway, the command line is their friend, > > NOT something they want to avoid. > > > > Pull requests (for code or instructions in the README) are more than > > welcome. The code and the documentation are MIT licensed. > > > > https://github.com/fstephany/hello-pharo/ > > > > Cheers, > > Francois > > > > > > _______________________________________________ > Pharo-business mailing list > pharo-busin...@lists.pharo.org > http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org
