Wiki source code of Deploying on Amazon EC2
Version 70.1 by Pascal Robert on 2013/02/18 18:56
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | == Introduction == | ||
| 2 | |||
| 3 | [[Amazon Elastic Compute Cloud>>url:https://aws.amazon.com/ec2/||shape="rect"]] (Amazon EC2) is part of [[Amazon Web Services>>url:https://aws.amazon.com/||shape="rect"]]. 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. | ||
| 4 | |||
| 5 | == Automated Deployment on Amazon EC2 == | ||
| 6 | |||
| 7 | 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: | ||
| 8 | |||
| 9 | 1. Launch an instance of Amazon Linux AMI of whatever Type (size) you require | ||
| 10 | 1. Install required packages (httpd, mod-ssl etc) | ||
| 11 | 1. Download, install and configure WO deployment tools (JavaMonitor / wotaskd) | ||
| 12 | 1. Download, build and install the WO Apache adaptor | ||
| 13 | 1. Download and install dependancies (e.g. ImageMagick, http-devel) | ||
| 14 | 1. Download and install custom httpd.conf/ssl.conf and JavaMonitor configurations | ||
| 15 | 1. Download, install and boot your apps | ||
| 16 | |||
| 17 | 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. | ||
| 18 | |||
| 19 | {{info}} | ||
| 20 | To find out the Access Key and Secret Key, [[check this blog post>>url:http://howtoguides247.com/where-and-how-to-get-your-amazon-access-key-id-and-secret-key/||shape="rect"]]. | ||
| 21 | {{/info}} | ||
| 22 | |||
| 23 | {{note title="Dependencies"}} | ||
| 24 | * You need to have an Amazon Web Services account [[https:~~/~~/console.aws.amazon.com>>url:https://console.aws.amazon.com||shape="rect"]] | ||
| 25 | * The community scripts depend heavily upon "aws" ([[http:~~/~~/timkay.com/aws/>>url:http://timkay.com/aws/||shape="rect"]]), a command line utility for interacting with amazon ec2 and s3. | ||
| 26 | * The community scripts are built to support Amazon Linux ([[http:~~/~~/aws.amazon.com/amazon-linux-ami/>>url:http://aws.amazon.com/amazon-linux-ami/||shape="rect"]]). This process should work with most any flavor of UNIX, but is tested and reliable on Amazon Linux. | ||
| 27 | {{/note}} | ||
| 28 | |||
| 29 | === Hello World Walkthrough === | ||
| 30 | |||
| 31 | 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: | ||
| 32 | |||
| 33 | [[http:~~/~~/webobjects.s3.amazonaws.com/launch.sh>>url:http://webobjects.s3.amazonaws.com/launch.sh||shape="rect"]] | ||
| 34 | |||
| 35 | [[http:~~/~~/webobjects.s3.amazonaws.com/helloworld-userdata.sh>>url:http://webobjects.s3.amazonaws.com/helloworld-userdata.sh||shape="rect"]] | ||
| 36 | |||
| 37 | * chmod 775 both files | ||
| 38 | * Edit both and put in your AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. | ||
| 39 | * Edit launch.sh 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: | ||
| 40 | |||
| 41 | {{code}} | ||
| 42 | |||
| 43 | aws run-instance ami-38c33651 -i t1.micro -a public -n 1 -g Basic -k aws -f ./helloworld-userdata.sh --region=us-east-1 | ||
| 44 | |||
| 45 | {{/code}} | ||
| 46 | |||
| 47 | * Finally, run the launch.sh script | ||
| 48 | |||
| 49 | 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. | ||
| 50 | |||
| 51 | === Your own scripts === | ||
| 52 | |||
| 53 | 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! | ||
| 54 | |||
| 55 | === Uploading your own apps to S3 from Hudson === | ||
| 56 | |||
| 57 | 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. | ||
| 58 | |||
| 59 | Here is how we do it: | ||
| 60 | |||
| 61 | 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. | ||
| 62 | 1. Install the aws command line tool on your Hudson server. Remember to install it as root so it is not user-specific. | ||
| 63 | 1. A Hudson job does the uploading, simply executes a shell with the following command: | ||
| 64 | |||
| 65 | {{code}} | ||
| 66 | |||
| 67 | AWS_ACCESS_KEY_ID=[YOUR_KEY]; export AWS_ACCESS_KEY_ID | ||
| 68 | AWS_SECRET_ACCESS_KEY=[YOUR_SECRET_KEY]; export AWS_SECRET_ACCESS_KEY | ||
| 69 | cd /location/of/your/products | ||
| 70 | for i in *.tar.gz; do s3put your-bucket-name $i ; done; | ||
| 71 | |||
| 72 | {{/code}} | ||
| 73 | |||
| 74 | 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. | ||
| 75 | |||
| 76 | == Other resources == | ||
| 77 | |||
| 78 | You can get more information about Amazon EC2 in the [[presentation>>url:http://www.wocommunity.org/podcasts/wowodc/west09/WOWODCW09-WOInCloud.mov||shape="rect"]] Ubermind made about it at WOWODC West 2009. | ||
| 79 | |||
| 80 | {{note title="WOlastic is no longer supported by Übermind"}} | ||
| 81 | 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: | ||
| 82 | |||
| 83 | >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. | ||
| 84 | {{/note}} | ||
| 85 | |||
| 86 | Also see [[doc:Deploying via Chef]]. |