Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: removed lots of very old content


Amazon Elastic Compute Cloud (Amazon EC2) is part of Amazon Web Services. It provides "resizable compute capacity in the cloud"---in other words, it allows you to run what are essentially virtual private servers of various sizes and capabilities. It is relatively straightforward to set up a WebObjects application server on an EC2 instance. There are several flavours of Linux available as base images to customize.

Automated Deployment on Amazon EC2

The process is not complex, but it does contain a number of steps which are contained in public examples and you'll need at least a peripheral understanding of EC2, S3 and UNIX tools. The steps taken by these example scripts are outlined as follows:

  1. Launch an instance of Amazon Linux AMI of whatever Type (size) you require
  2. Install required packages (httpd, mod-ssl etc)
  3. Download, install and configure WO deployment tools (JavaMonitor / wotaskd)
  4. Download, build and install the WO Apache adaptor
  5. Download and install dependancies (e.g. ImageMagick, http-devel)
  6. Download and install custom httpd.conf/ssl.conf and JavaMonitor configurations
  7. Download, install and boot your apps

This process starts with a clean AMI and within a few minutes, you'll see a completely setup and fully running instance of WO/Wonder. Using your own AWS_ACCESS_KEY_ID and your own AWS_SECRET_ACCESS_KEY you will be able to modify the example scripts and rapidly build a fully complete and reliable deployment of your own.


To find out the Access Key and Secret Key, check this blog post.


Hello World Walkthrough

In this walkthrough example we'll build a brand new Amazon Linux instance, running WOnder's AjaxExample and AjaxExample2 apps. To get started, grab these scripts and pop them in a fresh directory on your Mac:

  • chmod 775 both files
  • Edit both and put in your AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.
  • Edit and comment in the appropriate line to launch in the region and AMI of choice, here is an example using a micro instance in the us-east-1 region:
Code Block

aws run-instance ami-38c33651 -i t1.micro -a public -n 1 -g Basic -k aws -f ./ --region=us-east-1
  • Finally, run the script

With no changes outside adding your own access and secrete keys, this script will run for a minute or two and produce a complete and running instance visible in your Amazon EC2 Management Console. In your Amazon EC2 dashboard you'll see the new instance, and you'll be able to find it's public DNS record and you can connect to the running WO/Wonder Apps and the configured JavaMonitor, using your browser.

Your own scripts

The best place to start with building your own scripts is to download everything used in the hello world example to see how it all works. It's not rocket science, but a useful place to build from. I cannot stress enough that you need to change everything to operate from your own private s3 buckets - unless of course you do want the world to be able to boot instances of your applications!

Uploading your own apps to S3 from Hudson

In the above example we pull the demo apps down from a public web server using wget. When you come to automate the deployment of your own apps you will want to serve them up from a private bucket or server. Amazon's S3 service using the aws command line tool is an easy way to move your own app.

Here is how we do it:

  1. Create a Hudson job that consolidates all of the build products that we want to shift to s3 into a single directory. We do this using the "copyarchiver" plugin.
  2. Install the aws command line tool on your Hudson server. Remember to install it as root so it is not user-specific.
  3. A Hudson job does the uploading, simply executes a shell with the following command:
Code Block

cd /location/of/your/products
for i in *.tar.gz; do s3put your-bucket-name $i ; done;

Elastic Load Balancing enables you to balance incoming requests between an array of EC2 instances. ELB supports SSL termination and sticky http/https sessions. The most reliable way to enable sticky sessions with WO is to store session id's in cookies, then choose "application server generated cookies" as your preferred method for sticky sessions and have the ELB monitor your wosid cookie.

Other resources

You can get more information about Amazon EC2 in the presentation Ubermind made about it at WOWODC West 2009.

titleWOlastic is no longer supported by Übermind

In a post to the WebObjects development mailing list in February 2011, Joe Kramer from Übermind notes that "WOlastic is no longer supported by Ubermind." From the engineer behind WOlastic:

The original intent of WOlastic was to quickly deploy secure WO applications into the cloud. – Public AMI's that were prepackaged were probably great for the time but now it doesn't seem as relevant as you could probably script the entire process with official AMI's that are maintained by the major Linux distros. I'll probably take down the Public AMI's later this week that I initially put up for WOlastic. I did a couple updates to the AMI's, they were barely used, so I stopped supporting them.

Also see Deploying via ChefFirst, keep in mind, though, that Amazon EC2 instances are just giving you instances of some different operating systems. For example, as of April 2021, one sees:

  • Amazon Linux 2

  • macOS (a few versions)]

  • Red Hat Enterprise Linux 8

  • Ubuntu Server

  • Microsoft Windows Server (many versions and configurations)

  • Debian

The installation instructions for a WebObjects deployment are exactly what those for your chosen operating system. If you have picked an operating system and the deployment instructions are old or incomplete, that should tell you something. There may be dragons.

Amazon Linux 2

Instructions for Amazon Linux 2 are TBD.