Thanks a lot Nick for your feedback, it is helpful. Laurent.
On Wed, May 18, 2011 at 9:46 AM, Nick Ager <[email protected]> wrote: > 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 >
