Who’s On Phirst

Official blog of Phurnace Software.

Tag >> Amazon Web Services

Posted by: Daniel Nelson on

We are in the middle of a two week industry analyst tour right now and we completed some really good briefings last week.  Lots of discussion on the need to provide rapid ROI, the need to show immediate cost savings to IT departments, how to leverage the desire in companies to use even more automation and of course, the Cloud.  Phurnace is in a very good place related to the hottest trends in IT.  Automation, a shift to an application centric mind-set in IT, cost reduction, and cloud computing.  The analysts see this and almost before we got to slide 2 in our presentation asked the question, “what do you think of VMWare’s acquisition of SpringSource?  Is the bubble back?”  First, no, the bubble isn’t back.  While $420 million is a great price for SpringSource, this is NOT like the days of $1.2 billion for Toothpaste.com or such silly things.   Those days are gone forever.  SpringSource has a huge following, real revenue and will add to VMWare’s product portfolio in a good way.   I see the SpringSource acquisition as good for everyone.  For them, for VMWare, for the market, for the momentum of virtualization and cloud computing.

We took the opportunity with the analysts that we met to talk about the future of app deployment in the cloud and where Phurnace fits today, but even more exciting, where we will fit in the near future.  We got great feedback and our ideas were validated.  We have some exciting plans for additional products targeted at the cloud.  Amazon Web Services first, other public clouds after that.

We were continually asked, “why aren’t you partnering with VMWare?”  Actually, that makes sense.  Our software deploys applications into physical, virtual or cloud environments.  VMWare would be a logical partner.  We have just been so busy with other customer requests.  I guess since our software works out of the box with VMWare, we didn’t really see a need to call them and bother them.  I bet they have their hands full right now with SpringSource. 

In VirtualizationCloud ComputingAmazon Web Services
Comment (0) Read More...


Posted by: Wesley Willard on

Amazon Elastic Compute Cloud (EC2) has generated enormous amounts of buzz in the last couple of months. EC2 allows scalable deployment of applications by providing a way for customers to create server “instances” which can run any number of operating systems, such as Windows XP and Vista, and any number of Linux distributions. The customer can load any software of their choice on to the machines, and customize them at will. A customer can create, launch, and terminate server instances as needed, paying only for usage.

In addition to providing a Amazon Management Console to manage these instances, Amazon also provides command line tools which allow for the automation of instance administration. By combining these tools with some basic shell commands, you can customize the startup of your EC2 instances. I will provide an example that shows how this can be accomplished.

This example assumes you have the following available:


Okay, let's get started. First of all, we'll define some basic shell variables:

export EC2_HOME=/opt/ec2/tools/ec2-api-tools-1.3-30349/
export EC2_PRIVATE_KEY=~/ec2/pk-HGHEBCKY657B2ZUH7YIVXZKT5QVNBWFM.pem
export EC2_CERT=~/ec2/cert-HGHEBCKY657B2ZUH7YIVXZKT5QVNBWFM.pem
export amiid="ami-cccb2ca5"
export key="mykey"
export zone="us-east-1c"
export group="server"
export id_file="mykey.pem"
export vol_name="vol-8abe59e3"
export mount_point="/mnt/vol"
export device_name="/dev/sdf"
export ip="174.129.232.50"

The variables that start with the name “EC2” are used by the Tools API. They are the directory where you downloaded your Tools installation and the key and cert files provided to you by Amazon when you created your instance. The other variables are used by the shell commands in this example, and include:
  • Amazon Image ID
  • Key name associated with this instance
  • The zone in which this instance was created
  • The group associated with this instance
  • The name of the user's EC2 identity file
  • The ESB volume ID
  • The mount directory within the EC2 instance
  • The device name to associate with the ESB volume when attached
  • The Elastic IP address to associate with the instance

Now it's time to start the instance, and then loop until it is running.

#
# Start the instance
# Capture the output so that
# we can grab the INSTANCE ID field
# and use it to determine when
# the instance is running 
#
echo Launching AMI ${amiid}
${EC2_HOME}/bin/ec2-run-instances ${amiid} -z ${zone} -k ${key} --group ${group} 
--group default > /tmp/a if [ $? != 0 ]; then echo Error starting instance for image ${amiid} exit 1 fi export iid=`cat /tmp/a | grep INSTANCE | cut -f2` # # Loop until the status changes to “running” # sleep 30 echo Starting instance ${iid} export RUNNING="running" export done="false" while [ $done == "false" ] do export status=`${EC2_HOME}/bin/ec2-describe-instances ${iid} | grep INSTANCE | cut -f6` if [ $status == ${RUNNING} ]; then export done="true" else echo Waiting... sleep 10 fi done echo Instance ${iid} is running

Now we have the running instance ID, which we will use going forward. We next attach the ESB volume to the running instance, associating a device name. After we attach the volume, we wait until its status indicates that it is attached.

#
# Attach the volume to the running instance
#
echo Attaching volume ${vol_name}
${EC2_HOME}/bin/ec2-attach-volume ${vol_name} -i ${iid} -d ${device_name} 
sleep 15

#
# Loop until the volume status changes
# to "attached" 
#
export ATTACHED="attached"
export done="false"
while [ $done == "false" ]
do
   export status=`${EC2_HOME}/bin/ec2-describe-volumes | grep ATTACHMENT | grep ${iid} | cut -f5`
   if [ $status == ${ATTACHED} ]; then
      export done="true"
   else 
      echo Waiting...
      sleep 10
   fi
done
echo Volume ${vol_name} is attached

Now we associate the Elastic IP address with the running instance. This capability is important in an environment where instances are being started and stopped at various points for scalability reasons, so these operations will happen with no interruption for the user.

#
# Associate the Elastic IP with the instance
# After this operation we just sleep a bit
#
echo Associating elastic IP address ${ip}
${EC2_HOME}/bin/ec2-associate-address 174.129.232.50 -i ${iid}
sleep 30

Our final step for starting our instance is to copy and execute some additional commands within the running instance. These operations will create a mount point and mount the volume. Our commands assume that any partitioning and file system type creation has already been setup in the Amazon image’s /etc/fstab file. We use SSH to copy and execute these commands. Because EC2 does not allow username/password authentication, we must provide our identity file to SSH.

#
# Start the operations within the instance
# Copy over the mount script and execute it
# The script setup_vol does:
#     mkdir /mnt/vol
#     mount /mnt./vol
# 
scp -i ${id_file} setup_vol root@${ip}:/root
ssh -i ${id_file} root@${ip} . ./setup_vol

Finally, because this instance was created with an Ubuntu Desktop image, we can set up an NX Server to allow us to access our running instance with a remote desktop:

ssh -i ${id_file} root@${ip} /usr/NX/bin/nxserver --stop
ssh -i ${id_file} root@${ip} /usr/NX/bin/nxserver --start

Last, but not least, tell the user that we are ready to start using the running instance.

echo Image ${amiid} instance ${iid} is ready to go!
echo ${iid} > current_instance

I have attempted to demonstrate how you can use automation to facilitate the easy startup of your Amazon EC2 instance. This example can serve as a starting point for further customizations specific to your environment.

In Amazon Web ServicesAmazon EC2
Comment (6) Read More...