[Seaside-dev] Re: [Esug-list] [ANN] SmallHarbour project

[Nick Ager]

Hi Romain, Laurent,


> 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/
>>>
>>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20110518/12e7ba86/attachment.htm