[Pharo-project] [Esug-list] [ANN] SmallHarbour project
laurent.laffont at gmail.com
Wed May 18 11:51:49 CEST 2011
Thanks a lot Nick for your feedback, it is helpful.
On Wed, May 18, 2011 at 9:46 AM, Nick Ager <nick.ager at gmail.com> wrote:
> Hi Romain, Laurent,
>> Having Amazon ec2 image is also a very good idea, and some
>>>> Smalltalkers have already made first important steps like:
> 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
> 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
> The task is then to create recipes for Seaside specific parts. There are a
> couple of Gemstone recipes already (
> 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,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-project