The two major open source PaaS (platform as a service) offerings are Red Hat's OpenShift and Pivotal's Cloud Foundry. Like Cloud Foundry, OpenShift was designed to provide rapid self-service deployment of common languages, databases, Web frameworks, and applications. One of OpenShift's current differentiators is that continuous integration (using Jenkins) is a standard part of its workflow.
OpenShift is useful for both developers and operators, as well as for streamlining the process from development through testing and production deployment. Like Cloud Foundry, it can run in a public or private cloud, or on-premise.
[ Also on InfoWorld: PaaS shoot-out: Cloud Foundry vs. OpenShift | Review: Cloud Foundry brings power and polish to PaaS | Work smarter, not harder -- download the Developers' Survival Guide | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]
OpenShift comes in three versions: Online (no version number, but monthly updates), Enterprise (version 2.1), and Origin (version 3.0), all produced from the same upstream code. The Origin version is the bleeding edge, community supported, free open source edition. It receives daily updates and runs on your hardware using Fedora as the underlying operating system. You can download a preconfigured virtual machine, configure it yourself with Puppet or Vagrant, or even build it yourself from source code. Origin is not really intended for production environments, but can provide a good, fast, free development environment that runs on a laptop or desktop.
The OpenShift team takes a three-week-sprint "cut" from the Origin version for the Online version on a monthly basis. OpenShift Online runs on Red Hat Enterprise Linux (RHEL) hosted on Amazon and has seen roughly 1.8 million total apps deployed. Any bugs that surface under this heavy use are fixed in the Origin version. The Online version is appealing to developers and testers and to provide anyone interested in trying it out a quick, installation-free PaaS.
Cartridges represent pluggable components that can be combined within a single application. These include programming languages, database engines, and various management tools. The built-in cartridges are different for the three versions of OpenShift, but the lists are all extensive, albeit limited to items that run on RHEL. (There is a version of OpenShift that runs on Windows Server, but we have not reviewed it.)
If your company has LDAP, OpenShift can use it for creating teams. If not, you can still create teams, using OpenShift's own identities.
OpenShift supports the cloning of applications and uses multiple subdomains. When you combine these, you can set up OpenShift to easily do promotion of builds from development to QA to staging to production. You would give the owner of each level read access to the next lower level; for example, QA could pull a clone to its domain when the developers say they have a build ready for testing.
OpenShift applications can be versioned. You can define how many versions are retained in your cloud at any time in the application lifecycle. If you discover a bug after you deploy a new version, you can revert to a stored version.
The OpenShift Watchman feature automatically stops and restarts misbehaving applications, which helps avoid downtime. Automatic scaling adds gears and even nodes when an application becomes heavily used. It's built into OpenShift and doesn't require a front-end scaling service. Both features reduce the amount of monitoring and operations work you have to do to run an application on OpenShift.
Downloading the 2GB Zip file for the OpenShift Origin VM took all of 10 minutes. I tried to use Parallels on my iMac to run the virtual machine even though the OpenShift documentation didn't mention it. Alas, Parallels could not convert the VM to its own format, although it was able to mount the disk image for Mac OS X.
I could have used VirtualBox, which is free from Oracle and supported by Red Hat for this purpose, but I didn't feel like putting another virtual machine manager on my iMac at the time. (I later installed VirtualBox to run Vagrant, a tool to automate the management and provisioning of development environments.) I also could have used
hdiutil or Apple's Disk Utility to make an ISO from the mounted image. Instead, I copied the Zip archive across my LAN to my MacBook, where VMware Fusion was able to load and run the OpenShift Origin VM with no problem.
I was pleasantly surprised that the OpenShift VM pretty much configured itself, right down to using Bonjour for local DNS. OpenShift told me its admin URL, told me the full command line to use for configuring
rhc setup correctly, generated SSH key pairs on my MacBook, uploaded the public key to the server VM, and asked me for a domain namespace name so that it could publish itself to the LAN. Finally, it offered to create and save an access token to allow me to avoid constant logins and told me the approximate token lifetime.
Deploying apps with cartridges and QuickStarts
All versions of OpenShift offer menus of cartridges -- Web frameworks, databases, and JBoss services -- and menus of QuickStarts. As I noted earlier, OpenShift Origin has the newest versions, OpenShift Online has older and more stable versions with bug fixes, and OpenShift Enterprise has the most stable versions. All the various cartridge types are plentiful and easy to install, as are the QuickStarts.
To get a feeling for what an application QuickStart installation involves, I installed the WordPress QuickStart both in OpenShift Online and in the Origin VM locally. I expected the local install to take longer because of download time, but I was wrong: The online install took two minutes, while the local install took 25 seconds. The online installation makes the application URL public in DNS, which is part of the reason for the additional time. The online installation can also be aliased to your own public DNS name, and a form lets you configure this easily.
Building a QuickStart is simple. You start by creating a base OpenShift application, installing any necessary cartridges, and replacing the default OpenShift example pages with your QuickStart code. You'll want to save all of your code as a single Git commit.
Then you'll want to remove any unnecessary files -- such as the application's log files and samples -- from the repository. Then configure the
.openshift/action_hooks (build and configuration scripts) to enable your application to run on OpenShift and to use OpenShift environment variables.
Review your QuickStart code and modify it as necessary to replace any static security values with values that are established on a per-instance basis, and use security libraries when available. Test the QuickStart extensively, and finally submit it for adoption.
Updating and scaling your application
When you want to update your application, you'll typically do a
git push. When OpenShift sees the new code, it will rebuild your application if necessary, then restart it.
Note that if you want automatic application scaling, you just check a box when creating the application. You can then configure the traffic trigger points for adding and dropping gears. Using the HAProxy software load balancer, OpenShift will horizontally scale the application with increasing load. As OpenShift senses increased traffic, it creates additional capacity at the middle tier of the application by spinning up more gears. OpenShift scales applications across nodes for reliability.