A Day At The Races » amazon

Presentation: Introduction to Amazon Elastic Beanstalk

Wolfgang Schell — Fri, 22 Apr 2011 14:06:55 +0000

Lars Vogel gave a talk on Google AppEngine at the Mannheim Java User Group (Majug).

Afterwards, I gave a short introduction to Amazon Elastic Beanstalk. The slides are available here:

The slides are available under the CreativeCommons license BY-NC-SA.

How to customize an Amazon Elastic Beanstalk instance

Wolfgang Schell — Tue, 08 Feb 2011 02:24:57 +0000

The default Amazon Elastic Beanstalk AMI provides a Java-based application container with Apache Tomcat as the work horse. All you have to do is to deploy a standard Java WAR file containing your web application.

But sometimes, the standard AMI does not provide everything. Maybe the Apache configuration needs to be tweaked or some package, e.g. a local memcached server, is missing.

Customizing the Beanstalk AMI is easy, there are only a few simple steps, which are outlined here.

First of all, start the AMI to be customized in the AWS console. Note: as described by foremosttravel in the Beanstalk forum, the instance should be started from the EC2 console, NOT the Beanstalk console, as running the AMI within the Beanstalk environment may lead to it being terminated during the EBS snapshot, as it might fail to answer to the Beanstalk health checks.

Preparation

So here are the step by step instructions for the preparation:

Go to the EC2 console
Select region US-East, as Beanstalk is currently available only there
Click Launch instance
Enter either ami-100fff79 for the 64bit AMI or ami-060fff6f for the 32bit AMI (as of Feb 8th, 2011; these AMIs contain fixes to preserve the original hostname and protocol, which are stripped by the load balancer)
Click Select, then Continue, until the step Create Key Pair
Choose an existing key pair or create a new one. This will be used to access the running instance using SSH
In the next step, specify an appropriate security group, which allows SSH access, e.g. SSH
Press continue and finally launch the instance
In the instance list, press the right mouse button over the instance and choose Connect
Copy the SSH command line, adjust the path to your private key and connect to the instance using a SSH client.
Note: you need to connect as user ec2-user, root access can be obtained using the command sudo su -. See this blog post for details on how to access the instance.

Customization

Now we are free to customize the AMI’s files to our heart’s content.

Note: As the AMI is running outside the Beanstalk environment, Apache, Tomcat, and HostManager (the software interface to Beanstalk), are not running, as they didn’t get the expected parameters, such as the path of the application to start. This doesn’t matter, as soon as we start the customized AMI in an Beanstalk environment, everything works again.

As a proof of concept, we change HostManager‘s default index page (/opt/elasticbeanstalk/srv/hostmanager/views/index.erb) to contain the following HTML body:



		

		Host Manager


		Haz customization!

Note: when changing HostManager or the Apache configuration, please make sure, that HostManager still answers to Beanstalk requests on /_hostmanager and the application to health checks on /, otherwise the instance will be terminated and another will be started!

Persisting changes

Now that we are done, we need to create an EBS snapshot to preserve our customizations. The AMI is EBS-backed, so a snapshot can be used to register an AMI, which is based on the snapshot.

Again, here are the step by step instructions:

Remove eveything you do not want to remain in the instance such as the bash history, SSH keys, …
Create an EBS snapshot, either from the EC2 console or the command line tools. See the user guide for details.
You now have an AMI. See Images > AMI on the left side of the EC2 console and choose Owned By Me in the AMI tab to view your newly create AMI. Note down the AMI id.

If you want to make some more changes, keep the current instance running, while you test your changes from within Beanstalk. After a test drive (see below), make some more changes and create another image. Rinse and repeat until you are satisfied with the results. Don’t forget to clean up any unnecessary EBS snapshots and AMIs, as they cost actual money!

Start customized instance in Beanstalk

If you want to test-drive your customized AMI, you need to start an Beanstalk environment with the id of the customized AMI. There are two ways to perform this, via the Beanstalk console or from the command line.

Via Beanstalk console

Go to the Beanstalk console
Create an environment
Wait for everything to be started so you can change the configuration
Adjust the AMI id as described in the user guide
Restart the environment
Test your changes. In our example, we go to the changed HostManager index page at http://myenv.elasticbeanstalk.com/_hostmanager

Via command line

We use my simplified script to start an Amazon Elastic Beanstalk application from command line. See here for a detailed description. We can specify all parameters right from the start, so we do not need to wait for the initial start, before we can adjust the configuration.

Download the script from GitHub
Start an environment with the following command:
eb-create-app.sh -a myapp -i ami-be55a5d7 -t t1.micro -C 64 -e myenv -k mykeypair

Make sure to specify the id of your AMI as created above. Also don’t forget to specify a keypair, otherwise you won’t be able to log in using SSH. The name of the environment must be unique, as it is also used as CNAME (this can be overridden with -c though)
Test your changes. In our example, we go to the changed HostManager index page at http://myenv.elasticbeanstalk.com/_hostmanager

Outlook

Have fun creating customized instances. Please leave feedback and/or a note in the comments, which describes your changes. I will try to change HostManager to run the Virgo OSGi server instead of Tomcat, so stay tuned for the next installment.

Script to start an Amazon Elastic Beanstalk application from command line

Wolfgang Schell — Thu, 03 Feb 2011 03:28:35 +0000

After playing around with Amazon Elastic Beanstalk, I started to explore the command line tools.

Starting an Amazon Elastic Beanstalk application from the AWS console is easy and reasonably fast. The main problem is that you can’t currently provide additional settings such as the instance type (e.g. m1.small or t1.micro), a SSH key or application parameters.

After starting the application environment, it must be stopped again, before the configuration can be changed. This costs an instance hour but, more importantly, this procedure takes quite a while, as AWS must reconfigure the load balancer, auto-scaling group, start your instance(s), etc.

I created a script, which can be used to start an application environment from the command line. The most important parameters can be set as command line parameters:

All you need is to install the Elastic Beanstalk command line tools and my script.

Example

Starting an application myapp with environment myenv on a m1.small instance with SSH key mysshkey is as simple as:

eb-create-app.sh -a myapp -k mysshkey -e myenv -t m1.small -f 'mybucket/myapp.war'

Some notes:

the application WAR file must already be uploaded to S3. The format of the file name (parameter -f) is bucketname/key. If the file name is not specified, Beanstalk will deploy the sample application
the environment can only be created, if the CNAME (which is identical to the environment name, if not specified with -c) is not already used. The CNAME is used as sub-domain under elasticbeanstalk.com. When creating an environment with name (and CNAME) myenv, the full DNS name would be myenv.elasticbeanstalk.com
starting an environment will fail, if the SSH key name does not exist. You can look up the name of your SSH key in the EC2 console

Elastic Beanstalk Parameters

Elastic Beanstalk provides many parameters, which can be set. A full list can be obtained using elastic-beanstalk-describe-configuration-settings, also from the command line tools (NOTE: fix required!).

I created a list of all Elastic Beanstalk configuration options using another script (requires ruby gem jazor):

The long version in JSON format is available here.

Final words

Starting an application environment is easy and the command line tools help a lot. There are still some bugs, but I’m sure, the Beanstalk team will address them soon. The forum is a great resource.

My next post will be about creating a customized Beanstalk AMI. Stay tuned!

Dissecting an Amazon Elastic Beanstalk instance

Wolfgang Schell — Sat, 22 Jan 2011 13:15:41 +0000

Amazon Elastic Beanstalk provides a PaaS similar to Google AppEngine, bundling many of their existing offerings such as Elastic Compute Cloud (EC2), Simple Storage Service (S3), Simple Notification Service (SNS), Elastic Load Balancing, Auto Scaling, and monitoring using Cloud Watch into a simple to use service. Additionally, other Amazon services such as SimpleDB, Relational Database Service (RDS), Simple Queue Service (SQS) may be used as well.

Currently, Elastic Beanstalk provides a Java-based application container with Apache Tomcat as the work horse. All you have to do is to deploy a standard Java WAR file containing your web application.

Simply create a Java web application with Spring MVC, Grails, OSGi, Eclipse RAP, or any other of the numerous Java web frameworks and upload it using the AWS web console.

Additional containers for other platforms such as Ruby, Python or PHP may follow later, but as Tomcat hosts standard Java WAR files, anything with a Java implementation may be run. Ruby apps based on Rails or Rack using Warbler and JRuby, Python apps using Jython, even PHP apps can be made to run on Beanstalk.

In this blog post, I’ll dive into the inner workings of a Beanstalk server instance and poke around its internals. I invite you to come along for the ride.

Accessing your instance
The first step in dissecting a Beanstalk instance is getting access via SSH.
In order to acces your running instance(s), you first need to configure the SSH key pair to be used:

Configuration dialog in Elastic Beanstalk web console

Enter the name of a key pair as configured in your EC2 web console. See the EC2 guide and the description in the Elastic Beanstalk guide for details on creating and configuring a key pair.

Setting the key pair requires a restart of your Beanstalk environment, which may take a couple of minutes.

Finally look up your instance id and get the instance’s hostname. Connecting to the server is now as simple as this:

ssh -i .ec2/mykeypair.pem ec2-user@ec2-184-72-134-2.compute-1.amazonaws.com

Please note, that you need to connect as user ec2-user, root access can be reached using the command

sudo su -

Getting around your instance
The first steps are to collect some interessting facts. The instance uses a Amazon Linux AMI (release 2010.11.1 (beta), README). The AMI id for the ElasticBeanstalk-Tomcat6-32bit is ami-7609f81f, the kernel id is aki-407d9529. The instance is EBS-based and there is no ephemeral storage. Currently, Beanstalk is only available in the US East zone.

Software
The process list reveals: along with Apache Tomcat, Beanstalk uses the venerable Apache Web Server. Additional software includes Bluepill for basic process monitoring, and Amazons own HostManager (see below), which is run within a Thin web server.

Network setup
Elastic Beanstalk scales EC2 instances as needed. Therefore the first target is a load balancer provided by Elastic Load Balancing. Each instance runs Apache as the front end on port 80, with web request being reverse proxied into Tomcat on port 8080. Requests for URI /_hostmanager are forwarded to HostManager on port 8999.

CloudWatch performs health checks by periodically requesting the root page (URI /) of your application. Both health check URI and frequency are configurable. If an instance is no longer available or the load changes, CloudWatch starts or stops instances.

[Image from AWS Elastic Beanstalk Concepts blog post]

HostManager
Local instance management is performed by Amazons HostManager. HostManager is a Ruby application based on Rack and running in a Thin server on port 8999. It receives requests on URI /_hostmanager.

Some examples from the access log:

72.21.217.96 (72.21.217.96) - - [21/Jan/2011:22:00:45 +0000] "POST /_hostmanager/tasks HTTP/1.1" 200 368 "-" "AWS ElasticBeanstalk Health Check/1.0" 10.223.61.43 (10.223.61.43) - - [21/Jan/2011:22:01:05 +0000] "GET /_hostmanager/healthcheck HTTP/1.1" 200 90 "-" "ELB-HealthChecker/1.0" 10.122.19.154 (10.122.19.154) - - [21/Jan/2011:22:01:11 +0000] "GET /_hostmanager/healthcheck HTTP/1.1" 200 90 "-" "ELB-HealthChecker/1.0" 10.223.61.43 (10.223.61.43) - - [21/Jan/2011:22:01:36 +0000] "GET /_hostmanager/healthcheck HTTP/1.1" 200 90 "-" "ELB-HealthChecker/1.0" 10.122.19.154 (10.122.19.154) - - [21/Jan/2011:22:01:42 +0000] "GET /_hostmanager/healthcheck HTTP/1.1" 200 90 "-" "ELB-HealthChecker/1.0" 72.21.217.96 (72.21.217.96) - - [21/Jan/2011:22:01:46 +0000] "POST /_hostmanager/tasks HTTP/1.1" 200 368 "-" "AWS ElasticBeanstalk Health Check/1.0" 10.223.61.43 (10.223.61.43) - - [21/Jan/2011:22:02:07 +0000] "GET /_hostmanager/healthcheck HTTP/1.1" 200 90 "-" "ELB-HealthChecker/1.0" 10.122.19.154 (10.122.19.154) - - [21/Jan/2011:22:02:13 +0000] "GET /_hostmanager/healthcheck HTTP/1.1" 200 90 "-" "ELB-HealthChecker/1.0" 10.223.61.43 (10.223.61.43) - - [21/Jan/2011:22:02:38 +0000] "GET /_hostmanager/healthcheck HTTP/1.1" 200 90 "-" "ELB-HealthChecker/1.0" 10.122.19.154 (10.122.19.154) - - [21/Jan/2011:22:02:44 +0000] "GET /_hostmanager/healthcheck HTTP/1.1" 200 90 "-" "ELB-HealthChecker/1.0" 72.21.217.96 (72.21.217.96) - - [21/Jan/2011:22:02:47 +0000] "POST /_hostmanager/tasks HTTP/1.1" 200 368 "-" "AWS ElasticBeanstalk Health Check/1.0"

Files
HostManager is installed in /opt/elasticbeanstalk/srv/hostmanager. A file list can be found here. /opt/elasticbeanstalk/lib also contains a full Ruby 1.9.1 installation.

Some log files can be found at /opt/elasticbeanstalk/var/:

/opt/elasticbeanstalk /opt/elasticbeanstalk/var /opt/elasticbeanstalk/var/state /opt/elasticbeanstalk/var/state/hostmanager.pid /opt/elasticbeanstalk/var/state/healthcheck /opt/elasticbeanstalk/var/tmp /opt/elasticbeanstalk/var/log /opt/elasticbeanstalk/var/log/LogDirectoryMonitor.log /opt/elasticbeanstalk/var/log/DaemonManager.log /opt/elasticbeanstalk/var/log/bluepill.log /opt/elasticbeanstalk/var/log/hostmanager.log /opt/elasticbeanstalk/var/log/ApplicationHealthcheck.log /opt/elasticbeanstalk/var/log/CatalinaLogMonitor.log

Final words
That’s all for today’s blog post. Further posts will take a closer look at HostManager and deployment including the application setup sequence.

I’m looking forward to any feedback and additional information.

Maybe we can even hack HostManager to accept other application containers, e.g. for OSGi applications.

Web Application Infrastructure

Wolfgang Schell — Sun, 10 Feb 2008 16:45:00 +0000

Congratulations: after spending plenty of time on creating and polishing your perfect web application in your development environment, it is finally meant to be released for public consumption.

If it proves to be popular (or simply gets slahdotted), the application is in for a first real-world stress test. A single server will be overloaded pretty fast, but hosting the application on a server farm for traffic that might never come will get expensive very soon.

Amazons Elastic Compute Cloud (EC2) to the rescue. EC2 offers great flexibility for running web applications. Pre-created or custom application server images (so called AMI – Amazon Machine Images) based on Linux and Xen allow fine-grained control over available software. The web application might be running on a single server, but if the load is rising, the load may be dispersed by starting new server instances. If the load decreases, the number of servers may be reduced again.

The possibility to provide your own server images (AMIs) allows for server instances with different roles: one or more database servers might provide central storage services for your application servers while another server instance simply processes incoming and outgoing emails. Network security is ensured and can be specified with a fine-grained security policy.

Amazon bills by running instance per hour with three different hardware configurations available starting at 0.10 USD per hour. A single server of the lowest category amounts to roughly 70 USD per month, which is probably more expensive than other hosters. But the flexibility to balance load by starting or stopping server instances is priceless.

Web applications need one or more servers to run on, but what about storage? Each server provided by EC2 offers 160 GB (or more, depending on your hardware configuration) of space, but that storage space is only available as long as the server instance is running. Again Amazon provides a solution: its Simple Storage Service (S3). Space (almost) without limit at 0.15 USD per GB and month (+ data transfer, when accessed from outside Amazon’s network). About the only drawback is that the storage can not be accessed like a ordinary file system. This is due to the distributed architecture, which in turn provides high availability and safety for your precious data.

Communication between your servers may be performed using a third service offered by Amazon: its Simple Queue Service (SQS) allows message to be sent using one or more queues, which provides for an elegant load balancing solution for distributed services.

A recently established service, Amazon SimpleDB offers structured data storage. The service is still in limited beta, but seems to cater for your basic database needs without using a full-blown database server of your own.

All these services can be controlled and accessed through web service APIs with a wide variety of clients available in all major programming languages. For Java, these libraries offer all functionality exposed by Amazon’s services:

The excellent JetS3t library (Apache license) provides access to Amazon S3
Typica (Apache license) exposes the functionality of EC2, SQS and SimpleDB for Java developers

Toolkits and support for other languages can be found on the Amazon Resource Center pages.

All in all, Amazons EC2, SQS, and S3 provide the perfect environment for
web applications: great flexibilty for a reasonable price with plenty of room to grow according to your needs.

For an example of deploying distributed J2EE Applications using Amazon EC2 see this article, another example of using Amazon SQS, EC2, and S3 for distributed processing is described in an article by David Kavanagh, author of the excellent Java library Typica (see above).