[ANN] HelloPharo - webapp deployment tool

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

On 14 Aug 2014, at 13:08, François Stephany <[hidden email]> 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 <[hidden email]> 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
>

On 14 Aug 2014, at 15:21, François Stephany <[hidden email]> 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 <[hidden email]> wrote:
>
> On 14 Aug 2014, at 13:08, François Stephany <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org

On 14/8/14 13:02, François Stephany 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.

Excellent!
I love infrastructure.
Keep pushing that.
Did you announce it on the seaside mailing-list

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

François,

Thanks for providing this.

I am setting this up for my own environment (CentOS) and it is very useful to have your sample.

I'll have to -m yum a bit but definitely a super starting point.

Phil

On Thu, Aug 14, 2014 at 10:42 PM, François Stephany <[hidden email]> wrote:

Just sent it to the Seaside ML, thanks for mentioning it ;)

On Thu, Aug 14, 2014 at 5:13 PM, stepharo <[hidden email]> wrote:

On 14/8/14 13:02, François Stephany 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.

Excellent!
I love infrastructure.
Keep pushing that.
Did you announce it on the seaside mailing-list

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