[ANN] SmallHarbour project
Locked
 
|
We actually have www.seasidehosting.st which can only be used for non-commercial applications. I am Romain Verduci, a french student in Information System (Master degree) who likes smalltalk since I have discovered it last year through Pharo. Today, I participate to weekly coding-dojos with other smalltalk fans (http://cara74.seasidehosting.st/). I am lucky to participate to ESUG SummerTalk this year with Laurent Laffont as mentor to develop SmallHarbour project. With the support of ESUG and under the ESUG SummerTalk 2011, we want to provide: - a simple platform to host commercial smalltalk web applications. - an easy way for everyone (and enterprise) to deploy their own hosting platform. - for the non-smalltalkers, provide ready Pier images to deploy basic blogs, event presentations and more. SmallHarbour has started from the actual Seaside Hosting code base. Our first objective is to port it to Pharo / Cog / Seaside 3 and document. For more informations about the project, you can follow us on www.smallharbour.org. If you have any needs or ideas in order to improve our project vision, we will be happy to collect them. We will setup community tools (issue tracker, public repositories, doc ....) when the exams period is over :) Best regards Romain Verduci Student in Information System (Master degree) - IMUS, IAE Savoie Mont-Blanc - Annecy Tel. : +33659892353 Mail : [hidden email] _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: [Esug-list] [ANN] SmallHarbour project
|
|
On 05/17/2011 12:37 PM, Davorin Rusevljan wrote:
> On Tue, May 17, 2011 at 9:19 PM, laurent laffont > <[hidden email]> wrote: >> Actually we have several visions (nothing is final here, ideas welcome) > .. > > Having Amazon ec2 image is also a very good idea, and some > Smalltalkers have already made first important steps like: > > http://www.nickager.com/blog/Create-a-free-Gemstone-server-in-the-cloud-in-10-minutes/ > > You probably already have enough on your plate, but I mentioned > CloudFoundry for following reasons: > - it has a promise that one would be able to deploy SmallHarbour to > different cloud providers > - CloudFoundry currently provides support for Java, Ruby and > Javascript, adding Smalltalk would be nice for visibility, and could > be used for other Smalltalk services not only SmallHarbour. > > As I said you probably have enough to do in the first place, but if > you just happen to have some student lurking that has some ruby > knowledge to hack the interface for Smalltalk to Cloudfoundry it would > be very nice to have :) > > As for your other goals - great! > > Davorin Rusevljan > http://www.cloud208.com/ > > _______________________________________________ > Esug-list mailing list > [hidden email] > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org Laurent/Davorin, We are in the process of adding support for deploying GLASS applications into the Cloud Foundry, but I wouldn't mind helping folks who are interested in adding support for other Smalltalks into the Cloud Foundry ... The Cloud Foundry is written largely in ruby, so you'll need to be wearing your ruby dancing shoes:) Dale _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
Hi Romain, Laurent,
After having shared the above Amazon AMI (Amazon machine image), and experimented with EC2 hosting, I realised there are some undesirable properties of AMIs:
1) It's an image; with all the benefits and problems that entails; namely either you like the whole thing or not. It's not composable; it's difficult to know precisely what has been configured and how, and difficult to choose the bits you like and replace the bits you don't like.
2) You can't (currently for Linux), create an AMI locally and upload it, meaning everything has to be performed remotely and operating remotely in the IDE over X11 forwarding can be slow. 3) It's difficult to share across regions. Amazon's data centres operate autonomously. I created the image in EU-WEST and copying it to US-WEST or US-EAST is non-trivial.
4) It's another configuration that I need to keep up to date and I don't.
5) Not everyone wants to use EC2; other cloud services are available eg slicehost, linode, cloud-foudry etc
6) I configured the AMI using Amazon Linux, people might prefer Ubuntu, RHEL, Suse, Windows!#*? etc
7) I configured the AMI using Nginx as a front-end server with added modules (http://nickager.com/blog/compiling-nginx-to-add-extra-modules/), others might require other modules or other different server eg Apache, Cherokee etc. Even with the same server the configuration required can vary (url redirection, static file serving etc).
8) Everyone has a different way of performing backups, monitoring the health of the server.
9) I configured the AMI using Gemstone, others might prefer image based persistence or MySQL, Postgres etc.
10) Ideally the configuration would allow you to specify the number of images (or Gems for Gemstone) you'd like to respond to request, behind a load balancer.
11) We currently require infrastructure support for https eg stunnel or reverse proxy through a webserver eg http://www.monkeysnatchbanana.com/posts/2010/06/23/reverse-proxying-to-seaside-with-nginx.html
Quite a list... The main issue is that I'd like to be able to build server infrastructure from composable pieces and share configuration knowledge with others. This led me to Chef (http://opscode.com/chef/) where people create configuration "recipes" and a specific configuration is composed from these recipes. The benefit of using something like Chef is that there are already recipes for the standard parts of the server configuration eg installing and configuring Apache, Nginx, MySql, Postgres etc have already been taken care of. Chef abstracts the OS, and the cloud (eg EC2, slicehost etc).
The task is then to create recipes for Seaside specific parts. There are a couple of Gemstone recipes already (https://github.com/timfel/gemstone-cookbooks, https://github.com/johnnyt/gemstone-cookbooks). A few of us (myself Norbert Hartl, Stephen Eggermont) plan to investigate coding our configurations is Chef - though it's still early days and it may prove that it's more complex than we need.
Our basic requirements are to be able to rapidly deploy production, staging, backup, Jenkins continuous integration and development VMs.
Do others have experience with Chef or something similar?
Ideally ESUG or someone else would provide http://www.heroku.com/ for Seaside - but it would require formalising more of our stack and providing a flexible solution to https.
Hope this helps, Nick _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
In reply to this post by Dale Henrichs
Hi, We are in the process of adding support for deploying GLASS applications into the Cloud Foundry, but I wouldn't mind helping folks who are interested in adding support for other Smalltalks into the Cloud Foundry ... The Cloud Foundry is written largely in ruby, so you'll need to be wearing your ruby dancing shoes:) There certainly a lot of (justified) buzz around CloudFoundry at the moment. Building CloudFoundry infrastructure for Smalltalk deployment would appear to be a great approach - married with a hosting service that provides that infrastructure as a service.
Nick _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: [Pharo-project] [Esug-list] [ANN] SmallHarbour project
|
|
In reply to this post by Nick
Am 18.05.2011 um 13:15 schrieb Sean Allen: Just for the record. I used stunnel for a short while. But then the need for the use of client certificates arose (I'm implementing an apple push notification server). A very easy way to add SSL handling is to write a little server in node.js [1]. It supports SSL and client certificates out of the box. It could act as an intelligent proxy for SSL handling. If the use cases are known I could even provide a small node proxy. It is written in javascript and might be interesting for some to learn javascript on the server side. Node.js btw. is a cool server to know :) Norbert _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: [Esug-list] [ANN] SmallHarbour project
|
|
In reply to this post by Nick
On May 18, 2011, at 4:02 AM, Nick Ager wrote:
Nick, VMware will/is providing a hosting service based on cloud foundry, but there is an open source variant of cloud foundry that can be used by others to provide hosting services ... Dale _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
«
Return to Seaside Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |