Look at your watch.

Fifteen minutes from now you could be running any of the JumpBoxes that are  now available as public beta AMI’son Amazon’s EC2 service. As the least technical person in our office, I’ve known what EC2 is in the abstract sense for awhile now. Let me say it was extremely satisfying to finally fire up a JumpBox on EC2 and see how that service works first hand. I took screenshots of the entire process start to finish (which took just under 15min) in order to share here for anyone else who might be as daunted by EC2 as I was.

It should be noted that EC2 as a web hosting mechanism has some flaws (no persistent disk storage so if you’re node dies you can lose data not to mention your app can come back up under another IP address and disappear from its domain- this  is not a hosting substitute for critical apps at this point). But this  is a very slick way to get a public instance of a JumpBox running quickly for a non-critical application. It’s perfect for a scenario where you need to evaluate an application with a distributed team or proof a job for a remote client.

Here are the steps that I took to get the  MarKamp.org wiki working yesterday:

  • First you’ll need to setup an account on Amazon Webservices if you don’t already have one. Go to  aws.amazon.com, complete their application process and specify your payment details. * Next you have to enable the  EC2 (Elastic Compute Cloud) and  S3 (Simple Storage) services for your account. * Now you need to find out what your AWS credentials are. * Copy your Access Key ID and your Secret Access Key to some place where you can get them later. * I put mine in Textedit temporarily. * You’ll need to  install Firefox and launch it if you’re not already using it. Go get the  Elastic Fox extension from Amazon’s site. * Once you have this extension installed go to the Tools menu and launch it. * This is the main dashboard that shows you what’s available and which instances you have running. You’ll need to tell it how to access your AWS account. Click the “Credentials” icon in the upper-left. * Pick a name to refer to this account in Elastic Fox and enter those credentials that you stored in your text editor. * Now when you go back to the dashboard and click the “refresh” icon in the AMI panel, you should see every public AMI that’s available to you. * We’re only concerned about JumpBoxes so let’s filter this list by entering “jumpbox-amis” in the filter area. When you click refresh you should see the four JumpBoxes that we currently make available. * Now we need to setup a security policy that allows our JumpBox to communicate over the ports it needs. Navigate to the “Security Groups” tab. We could create a new group if we using this EC2 account for multiple projects and wanted to isolate the JumpBox-related stuff. For now we’ll just configure the default group to do what we want- click the green checkmark to add a new rule. * The three ports we need to open up are 22 (for ssh), 80 (for web) and 3000 (for the administrator). Leave everything as the default and enter the port info. We’ll need to do a rule for each port.   Update: If you intend to access your JumpBox over SSL you should add port 443.   Also, some JumpBoxes will require access to additional ports.   Consult the JumpBox Documentation Wiki for details on the JumpBox in question. * Go back to the “AMI’s and Instances” tab and launch whichever JumpBox you want to use by highlighting it and clicking on the “power button” icon. * It will bring up this scary-looking dialogue. If you’re using the default security group like we are you can ignore everything and click “Launch.” * Refresh the “Your Instances” panel and you should see your running EC2 instance. Grab the right edge of the Status header and drag it to the right so you can read the status. * When it’s finished booting it should turn green and switch to “Running.” Right-click on it and copy it’s public DNS name to your clipboard. * Now paste this into a web browser and you should get an SSL warning on first load- click OK. * This screen should look familiar if you’ve ever booted a JumpBox. Complete the configuration info as you normally would and click “Configure.” * It will think for a minute and give you the success screen once it’s finished. Click on the long address to access your application. * Your instance is running! It’s perfectly acceptable to use the application at this point but you may want to run it under a more friendly URL. Go back to the admin. * Click on the “Network” icon. * The public address you see is the URL you’re currently using to refer to your application. You’ll notice that it’s composed of four sets of numbers separated by dashes. Copy this segment of the sequence. * Paste it into your web browser, substitute dots for the dashes and you’ll find that this happens to be the public IP address of your JumpBox. At this point you’ll need to go to your domain registrar and change the “A Record” on the domain you wish to use to point to this IP address. If you need help with these steps search the help docs on your domain registrar for “DNS A Record.” For GoDaddy you access this by clicking on “My Domains,” choosing the domain in question and clicking “Total DNS Control.” * Come back to the hostname panel in your admin and specify the domain you wish to use as the public address. * You may need to wait a bit for DNS to propagate but you should very soon after be able to access your JumpBox in a browser under this domain. Congratulations! You now have a public instance of your JumpBox running on EC2 under your own domain. Two things to keep in mind: -You’ll want to make sure you configure  automatic backups to S3 if you’re using it for any application where you care about the data. -Remember EC2 bills based on usage - don’t leave town with an instance running that you forgot about or you will come back from vacation with an unpleasant bill from Amazon. It costs roughly $72/mo + minor bandwidth charges to host a site on EC2 24/7.

At this point you can do various cool things like work offline on your laptop to to add data to your application and then use the backup/restore features to inject these changes into your public EC2 instance. We’ll cover more of these techniques in future posts. For now, have fun tinkering with EC2!