Thursday, March 31, 2011

SUSE Studio is an awesome tool, with a couple of clicks you can create an openSUSE/SUSE based system and deploy to your hard drive, an usb flash, a live dvd, a VMware/VirtualBox/Xen server and even Amazon EC2 cloud. Suppose you want to create a tailored SUSE Studio appliance to run a Ruby on Rails app, this is a list of things you have to take care of:

install all the gems required by the app (this can be a long list).

install and configure the database used by the app.

install and configure a webserver.

ensure all the required services are started at boot time.

You can save some time by cloning this appliance shared on SUSE Gallery, but this is still going to be boring.

Dister to the rescue!

Dister is a command line tool similar to the one used by Heroku (one of the coolest ways to run your Rails app into the cloud). Within a few steps you will be able to create a SUSE Studio appliance running your rails application, download it and deploy wherever you want. Dister is named after SUSE Studio robot. It has been created by Dominik Mayer and me during the latest hackweek.

How it works

We are going to create a SUSE Studio appliance running a rails application called "SUSE history". The app uses bundler to handle its dependencies. This is its Gemfile file:

﻿﻿source 'http://rubygems.org'

gem 'rails', '3.0.5'

gem 'pg' gem "flutie", "~>; 1.1"

As you can see the app uses rails3, the flutie gem and PostgreSQL as database.

Appliance creation

Move into the suse_history directory and execute the following command:

dister create suse_history

As you can see dister has already done a couple of things for you:

created an appliance using latest version of openSUSE supported by SUSE Studio (you can use a different base system of course)

added the devel:language:ruby:extensions repository to the appliance: this repo contains tons of ruby packages (like mod_passenger)

installed a couple of things:

devel_C_C++ pattern: this will allow you to build native gems.

devel_ruby pattern: provides ruby, rubygems and a couple of development packages needed to build native gems.

rubygem-bundler: bundler is required by dister in order to handle the dependencies of your rails application.

all dependencies are installed: this is done only during the first boot using bundler.

the database user required by your rails app is created. This is done only during the first boot using some SQL code.

the database used by the appliance is properly initialized (aka rails db:create db:migrate). This is done only during the first boot.

Upload your code

It's time to upload suse_history code. This is done using the following command:

dister push

As you can see dister packaged the application source code and all its dependencies into a single archive. Then uploaded the archive to SUSE Studio as an overlay file. Dister uploaded also the configuration files required by Apache and by PostgreSQL setup.

Build your appliance

It's build time!

dister build

The appliance has automatically being built using the raw disk. You can use different formats of course.

Testdrive

Testdrive is one of the coolest features of SUSE Studio. Unfortunately dister doesn't support it yet. Just visit your appliance page and start testdrive from your browser. Just enable testdrive networking and connect to your appliance:

Download

Your appliance is working flawlessly. Download it and deploy it wherever you want.

dister download

Current status

As you can see dister handles pretty fine a simple Rails application, but there's still room for improvements. Here's a small list of the things on my TODO list:

The dependency management should install gems using rpm packages. This would make the installation of native gems easier, right now the user has to manually add all the development libraries required by the gem. Moreover it would reduce the size of the overlay files uploaded to SUSE Studio.

Tuesday, March 29, 2011

We've recently introduced a new beta feature, allowing you to clone a specific version of one of your appliances to a new appliance; effectively creating a branch. This feature is at the heart of any strategy beyond rudimentary mainline development.

The following is an example of how the current Studio feature set can be used for a release-oriented branching strategy.

Lets assume an appliance, MyAppliance, which I intend to develop over a long term using my own milestones, and share on SUSE Gallery. I also intend to offer updates with bugfixes on each milestone release.

I will develop on MyAppliance, treating it as a mainline branch. When I reach my version 1 milestone, instead of immediately sharing that build to the Gallery, I will clone that version to a new appliance: MyAppliance 1.0, perform a build without making any changes, and share that build. In the Gallery, it will appear as "MyAppliance 1.0" with one shared build: version 1.0.0.

While v1.0 is out in the wild, I can return to my mainline branch, MyAppliance, and continue development towards my next milestone. When (not if... but when) a bug is reported on my 1.0 release, I can switch over to that branch (appliance MyAppliance 1.0) and work through to a fix. When I'm satisfied with the quality of the fix, I can release an update on that branch, sharing the build to the Gallery. In the Gallery, I will now have "MyAppliance 1.0" with two builds: the default (1.1.0) and a prior build (1.0.0).

The bug that was fixed in "MyAppliance 1.0" probably exists on my mainline branch as well. Unfortunately, Studio doesn't (yet) have diff/merge functionality, but I can view the configurations, and the changelogs, and determine exactly what needs to be done to resolve the issue on my mainline branch as well. If I have already made any other milestone branches ("MyAppliance 2.0" in the diagram), I should manually apply the update to those branches as well.

This process mirrors common behavior for projects of nearly any scale; you can adjust to your workflow simply by changing the point at which you branch. Two other common options are branching at the beginning of a version cycle (alpha branching) or when a milestone is feature-complete (beta branching).

Tuesday, March 22, 2011

We've been working on ways to make collaboration on SUSE Studio appliances easier. The first step down that road is to make your appliance's build history act live a revision control system. To that end, our beta users will find a few new features available to them: viewing an appliance's complete configuration on one page; the opportunity to branch an appliance by cloning a specific version; and a dynamically generated changelog between each version.

All of these features are available on the Build tab, linked under each version's header:

The Changelog gives you a bulleted list of the delta between the selected version and the prior version.

We've also added a link to it under the 'current' version, so you can see the changes you've made since your last build. One caveat here: the changelog takes a few seconds to generate (we do it in the background normally to save you the wait, but that won't work for the current version) so please be patient when you click the link.

Next up is the Configuration, which sums up all the settings on your appliance in one view - no tabbing necessary, just a bit of scrolling ;-)

And lastly (for now) is version cloning, which provides you new opportunities to branch and manage your appliance's lifecycle, but we'll talk more about that in another post. Keep in mind, cloning a version will copy all the configuration options from that version to a new appliance, but you will still be updating any selected software to the current versions.

Please remember, these are beta features. If you're not participating in our beta program, you won't see them at all. If you are in our beta program, please give us some feedback on the new features so we can get them just right!

What exactly “magic” means here? We try to change repositories to their 11.4 equivalents and sometimes add or remove few packages to ensure everything works smoothly. You can see what exactly was done in the log accessible from the bar at the bottom of the Start tab.

Sometimes the upgraded appliance will need some more tweaks to make it work. Just inspect the log, see what was changed, and apply any additional adjustments. Let us know what you had to do on our forum or mailing list so we can improve the upgrade in the future.

If you are not satisifed with the upgrade, you can always revert to original version by clicking the “Undo upgrade” link.

Thursday, March 10, 2011

This week the openSUSE community launches the newest version of their flagship Linux distribution: openSUSE 11.4. We're doing our part to congratulate the community on their hard work by providing openSUSE 11.4 templates on Release Day! So hop into SUSE Studio, and start customizing your own version of openSUSE 11.4, be it for your desktop or server workloads. You can build all usual image formats except Amazon EC2 (which is coming soon).

And remember — as always, if you have a suggestion for us or encounter a problem, you can let us know on our forum (or our mailing list, which is just another view of the forum).

We've made a small iteration to the Studio UI, removing the option to prevent cloning of appliances you share on SUSE Gallery. Out of respect for you, our users, if you have already shared an appliance and prevented cloning we'll leave it that way, but we feel that, in the spirit of openness, all of our users have the right to build on the work shared in the Gallery's community. If you prefer not to share your work to that degree, SUSE Gallery may not be the appropriate venue. You may, as always, download your appliances and host them elsewhere, on your own terms, or simply keep them to yourself. The choice is yours.

Saturday, March 5, 2011

openSUSE 11.4 will be officially released on March 10, and we have been working hard to support it in SUSE Studio for a same day release. While you're waiting for that, check out the openSUSE 11.4 public AMIs on Amazon EC2! (All built with SUSE Studio.)

Region

Type

Arch

AMI ID

US East (Virginia)

EBS

i386

ami-e626de8f

US East (Virginia)

EBS

x86_64

ami-d226debb

US East (Virginia)

S3

i386

ami-b2768edb

US East (Virginia)

S3

x86_64

ami-e468908d

US West (N. California)

EBS

i386

ami-d3471596

US West (N. California)

EBS

x86_64

ami-dd471598

US West (N. California)

S3

i386

ami-274c1e62

US West (N. California)

S3

x86_64

ami-8f4c1eca

EU West (Ireland)

EBS

i386

ami-9e2e1fea

EU West (Ireland)

EBS

x86_64

ami-982e1fec

EU West (Ireland)

S3

i386

ami-f81f2e8c

EU West (Ireland)

S3

x86_64

ami-201e2f54

Asia Pacific (Singapore)

EBS

i386

ami-647d0536

Asia Pacific (Singapore)

EBS

x86_64

ami-6a7d0538

Asia Pacific (Singapore)

S3

i386

ami-aa750df8

Asia Pacific (Singapore)

S3

x86_64

ami-38760e6a

Asia Pacific (Tokyo)

EBS

i386

ami-8e3e948f

Asia Pacific (Tokyo)

EBS

x86_64

ami-903e9491

Asia Pacific (Tokyo)

S3

i386

ami-5e319b5f

Asia Pacific (Tokyo)

S3

x86_64

ami-72319b73

List of public openSUSE 11.4 AMIs. S3 = instance-store.

Amazon is offering a free usage tier, which means you can now run an openSUSE 11.4 micro instance in Amazon EC2 completely free of charge for one year! Do check it out.

Tuesday, March 1, 2011

Since last October it is possible to build images for Amazon Elastic Compute Cloud (EC2) with SUSE Studio. However, to upload an image, until now you had to download it, unpack it and either run our provided shell script locally or use some other third party tools to be able to grasp the power of Amazon Web Services (AWS).
With time comes change. SUSE Studio now provides all users that have beta-features enabled (visit your account page to do that) with the opportunity to build your appliance and deploy it to the cloud in the most simple and convenient way. Meaning you don't even have to download your appliance or install any tools to your local machine anymore.
Let us guide you through those few steps necessary to achieve that seemingly difficult task of conquering the cloud.
First you need to build an EC2 image of your appliance. We already explained how to do that in a previous post.

After your build has finished you should be able to see a link labelled "Upload to EC2" as can be seen in the picture above. Just click on it and proceed.
If this is the first time that you are using SUSE Studio to access EC2, you'll have to enter your AWS credentials.

Note: For running a SLE-based appliance on EC2, you can use Elastic Block Storage (EBS). However for openSUSE-based appliances currently there is only one option: Simple Storage Service (S3) . Therefore, if you've built an appliance based on an openSUSE template, you'll need to provide SUSE Studio with your X.509 certificate and private key as well as your account ID, since those are needed to upload an image to S3.
Even though we are working on EBS support for openSUSE-based appliances, we highly recommend using SLES or SLED for the most comfortable and effective cloud experience. To find out more about SUSE Linux Enterprise on EC2 go to http://aws.amazon.com/suse/.

After you have entered your AWS credentials, you will be redirected to your EC2 appliances page. Since you already specified the appliance and its build version by accessing this page through your appliance's build tab, the "Add instance" dialogue should already be preconfigured correctly, leaving you with one last choice: Do you want to instantly launch an instance after uploading your appliance to EC2 or not?
And that's all the magic there is. You are now one click away from entering the cloud!