I have been using Eucalyptus heavily (as a quality engineer it is my day to day) for the past 1.5 years. I know the ins and the outs of system and am constantly tracking new features and bug fixes that arrive. With this knowledge it makes me a prime candidate to find out how other pieces of the cloud story can integrate with Eucalyptus.
I run a small cloud at home that I use for development and testing of different software stacks. Some of the tools that I’ve learned to use and hack on since Ive turned up my cloud include Graphite, Gitorious, Jenkins, Testlink, Zenoss. The issue with getting most of these (and any) open-source tools running is that they often require a very particular base OS and dependency versions in order to install cleanly. This makes Eucalyptus a great tool for figuring out the right/easiest way to deploy an open source tool as it allows users to create and save any particular stack they have created for later use. Another great part about using Eucalyptus as a development tool is that it allows any and all distros to be loaded into a cloud and available for use by many users. When I look into a new tool to use I can rest assured that I can find one of their supported distros in my Eucalyptus cloud. Currently I have images registered for Debian 5/6, Ubuntu 12.04/12.10/13.04, Fedora 17, CentOS 6, and begrudgingly Windows 7 (99% used to manage vCenter nodes yuck).
There are many ways to populate and provision application stacks in a cloudy model. One way would be to load all of the application stack onto an image then re-bundle it and save it off. Another approach, and the one that I rely on, is to populate base images that can then be provisioned by scripts in order to run the application of choice. In using this model I had come up with many different scripts/user-data to populate the images listed above with applications. My approach allowed for apps to be deployed easily but I ended up with lots of replicated code across the user-data that I was passing to instances. Another pain was that it required me to remember which user-data scripts belonged with which images. Although not impossible to turn up and down my apps, it was definitely cumbersome and certainly not push button.
Scalr allows me to populate scripts into a common database that is shared across all images/clouds. Because Scalr allows multiple scripts to be run during instance turn up (and manually for that matter), I am now able to modularize my scripts to reduce the amount of code I need to maintain. Another element of Scalr that makes my life easier is its ability to auto scale an application. For my purposes I am not scaling an app to more than 1 instance, but if I ever bring down an instance erroneously Scalr will automatically repopulate the instance and run the scripts necessary to reconstruct the app. The final efficiency I get out of using Scalr is that I can load up multiple clouds and use the same scripts against similar base images within various clouds. As a tester I bring up and down at least 1 private cloud a day, on top of using my AWS account for both testing and production use, so this may be the last feature but certainly not least in my mind.
Eucalyptus+Scalr is a developer/tester’s dream, so lets get down to business on how to get this solution running on your own cloud.
- Run the script found here on a Ubuntu Precise 12.04 server or instance: https://gist.github.com/4527791
- You will be prompted a few times to enter the password listed in the script (default is yourpassword)
- Ensure that the default virtual host (scalr.local) can be resolved by either adding a DNS entry to the server or a host entry on your client. Default hostname can be changed on lines 4-5 in the script from step 1.
- Login to Scalr as admin/admin: http://scalr.local
- Click on Accounts in the top left corner and create a user account
- Click Settings->Core Settings, and set the “Event handler URL” at the bottom to the hostname you chose in step 3 (default is sclar.local)
- Logout and back in with your user credentials created in step 5
Scalrize Your Images
You need to install an agent, Scalarizr, on any any images used to create server templates, or in Scalr parlance roles. After installing the Scalarizr agent you will register each of your images as a role. To install Scalarizr:
- Install the repository package as appropriate for your distro: Debian RHEL/CentOS
- Install the Scalarizr package appropriate to the cloud that will be used. In our case “scalarizr-eucalyptus”
- Ensure that your image can properly resolve the “Event Handler URL” entered when installing Scalr
- Rebundle and register the image with Eucalyptus
Register Your Eucalyptus Cloud
Scalr works with many cloud providers including AWS. They were able to leverage a good amount of client code in order to support Eucalyptus. It would seem that the last time that the Eucalyptus integration was looked at was in the Euca 2.x timeframe so many things that Eucalyptus now has full support for with 3.1+ (EBS backed images for example) are not supported. Other missing functionality is support for keypairs (which can be patched using scripts in Scalr) and all instances are launched in the default group (not sure what the reason for this is).
In order to setup Scalr with your cloud credentials:
- In the top left of the navigation bar click “default”, the “Manage”
- Click “Actions” on the right, then “Configure”
- Set your timezone
- Click the Eucalyptus logo
- Click the green plus sign to add a new Eucalyptus cloud
Creating a Role
Scalr uses a paradigm for cloud automation that requires that cloud images be registered as Roles. These roles are then added to Farms in order to deploy an app. Each role can only appear once per Farm. Scalr allows you to catalog, version and deploy scripts using a templating mechanism where values can be set at the Role, Farm, or individual server level.
Some common role types are:
- Base Images
- Load Balancers
- Web Servers
In order to create a Role:
- Go to this page, replacing the hostname if necessary: http://scalr.local/#/roles/edit
- Once there, enter a name for the role, for example: Ubuntu Precise Base
- Click on the check box that represents what category of role this is, in our case we will check the checkbox for Base
- Click over to the Images tab and enter the information about the image you registered in the steps above
- Enter the image info including its machine image ID
- Click Add (left side) then Save (bottom center)
Adding your scripts
One of the most powerful parts about Scalr is the ability to write and reuse templated scripts. Scalr also allows you to share, fork, and version your scripts. Scripts can be added to Roles, Farms or individual servers for execution at boot, termination or manually during any part of an instances’ lifecycle. Creating, managing, and deploying scripts allows you to work around some shortcomings of the current Scalr/Eucalyptus integration like only being able to use the default security-group and no keypair being passed to instances launched through Scalr.
- Go to http://scalr.local/#/scripts/view in order to add some basic scripts
- Click the green plus sign on the right of the Scalr Web Console
- When adding scripts you will need to give them a name and a description along with the actual code
- The first script we will add will be called “SSH Key Inject” and ensure that our SSH key can be added to an instance:
echo %ssh_key% > /root/.ssh/authorized_keys
- The next script we will add will install Graphite, a scalable realtime graphing application and can be found here
You will notice that the script added in step 2 uses a wild card parameter, %ssh_key%, that can be configured at script run time, role provisioning or farm launch time. Once we’ve created our scripts its time to create our farm which will pair our scripts with our images, or Roles, so that we can run and terminate our application at will.
Creating a Farm
Farms are collections of roles that constitute a single deployment. All servers in a farm can be turned up and down in unison in order to deploy an application. Individual roles within a farm can be autoscaled. When Scalr notices less than a certain threshold of servers in a particular role, it will automatically launch more servers. As an example Farm, I will be showing how to deploy Graphite (Scalable Realtime Graphing).
- Add a role using the procedure above that references a Scalarized Precise Base Image
- Click over to the Farms pane in the Scalr web interface
- Click the green plus sign on the right of the Scalr Web Console
- Enter a name for this farm, in our case: Graphite
- Click over to the Roles tab and then click on Roles Library
- Click the plus sign next to Base Images
- Click on the icon for the Precise Base Image, then click the green plus sign.
Now that we have added the Base Image role to the Farm we will need to add scripts to the Role that run once the instance is up and running.
- Click on the icon that has now appeared towards the top of the page in order to configure what scripts we will run on this Role in the Farm
- On the bottom left click Scripting. In this configuration page we can choose which scripts to run, in which order and at what times
- Under the “When” dropdown click “Host Up”, then under the “execute” drop down choose the “SSH Key Inject” script we added in the steps from above. Once those two options have been chosen, click the green plus sign
- Click on the row that has shown up for that script
- On the right side of the pane:
- Ensure that “Where” is set to “All instances of this role”
- Under the parameters section at the bottom of the pane, set which public key we want to inject for this role
- Add our second script “Install Graphite” at “Host Up”, ensure that “Where” is set to “All instances of this role”
- Click save at the bottom of the interface
Once we have defined what roles and scripts are paired up to make our application we can launch our Farm.
- Go to the Farms interface: http://scalr.local/#/farms
- Click Actions on the right side page
- Click Launch
Scalr will now launch your image and run the desired scripts to build out the application. You can use this interface to turn up and down your applications as necessary. If Scalr notices that your app is no longer running on the cloud it will be automatically relaunched for you. I have used this feature many times to help me with disaster recovery. Once I have an application running properly in my cloud I ensure that I can terminate any individual instances and my Scalr configuration is setup to properly rebuild the app.