Posted tagged ‘seaside’

EC2 AMI with Smalltalk and Seaside: Update 3

October 10, 2010

Today I published a new version of the Amazon EC2 image with Smalltalk and Seaside. The third version contains the following software:

  • Ubuntu Server 32bit 10.04 LTS (release 2010-09-23)
  • Apache HTTP Server 2.2
  • SqueakVM 4.0.3.2202 Unix VM
  • PharoCore 1.1.1
  • Seaside 3.0

The AMI identification: ami-c2fe0aab

The update to the Ubuntu server makes it easier to run the AMI as a Micro (t1.micro) instance type. This is currently the smallest and cheapest EC2 image type. The image type is very well suited for running Seaside web applications. When your application becomes more popular you can scale by using a bigger instance type or by running multiple instances.

Creating a Seaside runtime image with Pharo

September 8, 2010

For the ec2 machine image with Seaside I prepared an image with only the runtime packages of Seaside. The image was based on PharoCore 1.1. This is the core Pharo image without development tools and extra libraries. The Seaside development tools can be very convenient during development but in a production environment they can be a serious security risk. You can disable them but the easiest and safest option is to not load these packages into your runtime image.

This is the recipe I used to setup the image:

1. Download the latest (stable) PharoCore

2. Load the Seaside 3.0 metacello configuration:

Gofer new
	squeaksource: 'MetacelloRepository';
	package: 'ConfigurationOfSeaside30';
	load.

3. Load the Seaside runtime packages we need

((Smalltalk at: #ConfigurationOfSeaside30 ) project latestVersion) 
	load: #( 'Base' 'Seaside-Adaptors-Comanche' 'JQuery-UI' 'Seaside-Examples').

4. Start the Komanche http server on port 8080

(WAComancheAdaptor port: 8080) start

5. Load the VNC Server (for remote image “management”)

Gofer new
	renggli: 'unsorted';
	package: 'RFB';
	load.

And finally I loaded my Seaside app and configured this app as the default app in Seaside.

"Load small demo Seaside app"
Gofer new
	squeaksource: 'Cloudfork';
	package: 'Cloudfork-EC2Demo';
	load.
	
"Make ec2demo the default Seaside app"
WAAdmin defaultDispatcher defaultName: 'ec2demo'.

This “lean-and-mean” Smalltalk image worked fine for me. I also exported the FileLibrary to the Linux file system so the static resources can be served by Apache directly. This is documented in the Deployment chapter of the Seaside book.

Update: Tip from Mariano Martinez Peck
You may want to evaluate a “ScriptLoader new cleanUpForProduction” after downloading PharoCore.
This will clean a lot of stuff and remove a lot of code (like tests) that may not be needed in production environments.

A new public EC2 AMI with Smalltalk and Seaside

August 29, 2010

This weekend I created a public Amazon Machine Image (AMI) setup as a Smalltalk web server with a Linux SqueakVM, a Pharo 1.1 Smalltalk image and the Apache2 web server. Anyone can use this AMI as a robust and scalable runtime platform for their Seaside applications.

In this article I will try to explain how you can you can use and customize this image. First their are some prerequisites:

Using EC2 is not free, you have to pay for each hour the server runs and you have to pay for storage and bandwidth. Seaside runs fine on the smallest 32bit AMI that costs $0,085 cents per hour. Bandwidth is $0,15 per GB (the first GB is free). You can get a discount on the costs per hour if you reserve you AMI’s beforehand.

The AMI is based on a 32bit Ubuntu 10.04 server AMI. The Ubuntu server is a very minimal install, I have added Apache2 and the SqueakVM. I have also setup a Pharo image with the Seaside runtime packages and Apache2 is configured in such a way that all requests are forwarded to Seaside.

How can you start using this AMI?

Start an EC2 instance using the public AMI ami-0800ea61 (ubuntu-10.04-i386-smalltalk-server-v01). The AMI is available in the US East region. This is the cheapest region :-) When you start the image you have to select a security group. This defines the firewall rules for the AMI. You can select the default group or some other group that allows TCP connections for the ports 22 and 80.

When the image is started it should have a generated a public DNS name. When you enter this name in the address bar of your browser, you should see something similar to http://ec2demo.doit.st If the web page is shown it means that everything is running OK.

You can connect to the running AMI instance using ssh. You should login with the userid ubuntu. No password is required because a private key is used for authentication. The Pharo image that runs on the AMI includes RFB, a VNC server implementation. With a VNC client we can remotely control the Smalltalk image. The best way to do this is to tunnel the VNC connection (port 5900) through ssh:

ssh -i id_rsa-gsg-keypair -L 5900:localhost:5900 ubuntu@ec2demo.doit.st

Now you can connect to the image using a VNC client use display number 0 and the password is seaside. Note that you have to keep port 5900 closed for direct access otherwise this would be very unsecure.

Through the VNC client you have access to the Smalltalk image. You should see a workspace. I used the code in this workspace to build the image from a standard PharoCore 1.1 image. Note that I only loaded the runtime parts of Seaside and some small examples. This image is used for hosting an application and not for development so it is probably safer and more efficient to leave out the development packages.

If the image suits your needs you can just load your packages through Monticello. There is no config web application to configure your Seaside components. You can do this via the workspace or better, make a class side initialize method that does this automatically when the package is loaded. I used the the Apache2 configuration described in the Seaside book (the non-clustered setup for now). You can read the Deployment chapter for more details. You should have you app running within a few minutes.

If the Smalltalk image does not suit your needs you can replace it with another Squeak or Pharo image. The image is stored in the directory /srv/seaside If your new image has a different name you need to update the run script in the same directory.

Of course you can also install more Ubuntu packages. You could install a local database system like MySQL or PostgreSQL. But if you are really into cloud computing you probably don’t want to maintain a database yourself. Instead you can use RDS, an AWS managed MySQL service or SimpleDB. SimpleDB is a key-value store with a simple API and great scalability. You can use the Cloudfork ActiveItem Smalltalk library to persist your Smalltalk objects to SimpleDB.

To setup a nice domain name for your app (like ec2demo.doit.st) you should reserve a static IP using the AWS Console. You can then go to your domain name registrar and update the name servers to point to this IP number.

Ok, this is about it. If you have questions or ideas on how to improve the Smalltalk AMI please let me now. I think the current AMI can be used as a production environment for Seaside apps.

Uploading to an Amazon S3 Bucket from Seaside

February 18, 2009

The Cloudfork repository on Squeaksource contains a package named Cloudfork-S3Upload. This package contains a Seaside component that shows how you can let a web user upload data directly to a S3 bucket. The Seaside component uses the AWS POST feature to implement this.

An advantage of this approach is that the data goes directly to S3 and doesn’t pass through your server. This increases the scalability and robustness of the system. Especially when uploading large files like media files.

The Cloudfork-S3Upload package doesn’t depend on any other Cloudfork package. It depends on the Seaside web framework and also on the Cryptography Team Package (required for the SHA1 hash function). I used the alpha version of Seaside 2.9 to develop this package.

My ambition is to develop a reusable S3 upload component that uses AJAX functionality to start the upload process without submitting the complete page. In this way it will be possible to perform multiple uploads simultaneously from a single page. This is not trivial and with my limited AJAX knowledge it will take me some time to get this working. The current code (version jvds.3) contains the functionality to configure the policy and to make a signature of this policy. The Seaside component CFS3UploadExample1 shows how this code can be used to implement an upload form. This sample form doesn’t have any fancy AJAX functionality but it does work without problems.


Follow

Get every new post delivered to your Inbox.