The Cure for Death by CPanel: OpenShift Explained for Web Hosting Providers

OpenShift is lightyears ahead of services like cPanel. Instead of limiting the availability of languages and frameworks, OpenShift’s Cartridge-based application launching process incorporates a composible approach to service delivery – allowing web hosting providers and sysadmins to offer reliable access to a diverse polyglot universe of open source components, while remaining in control.

Sysadmins, CentOS and Web Hosting Providers

I had (happily) forgtten that cPanel still existed until a recent conversation with a group of sysadmins from a large web hosting provider at the CentOS dojo event in Europe. CentOS has long been a favorite OS at some of the largest web hosting providers in the world since it’s “free and practically RHEL (without the support). Now that it’s part of the Red Hat family of sponsored open source projects – we on the OpenShift Origin team have ‘come out of the closet’ as CentOS fans. Its been our go to test/build environment for some time and we now include a CentOS VM for easy download and installation of OpenShift Origin, the open source upstream code base of OpenShift.

Having been a convert to PaaS for quite some time now, I have come to expect the extensibility of PaaS (aka the ability to deploy just about any language or application or framework I want), SSH access to my Linux environments, easy updating of everything from the OS to every part of the LAMP stack that my applications depend on, auto-scaling, and cost savings from not having to pay for dedicated resources I don’t need.

The System Administrators at the CentOS dojo understood the complexity of not only deploying the code, but procuring, provisioning and maintaining a production level system. They understood the need to stay up to date on the latest security patches and errata, ensure the security is properly configured, maintain a consistent and reliable backup and restore plan, monitor the application and servers for CPU load, disk IO, HTTP requests, etc. None of them liked cPannel.

CPanel: Easy for users, Costly for Admins

The nice thing about cPanel is that it obscures all this complexity from the end user. It provides a common interface across most web hosting providers that makes it easy for end users to move from one provider to the next without having to relearn the interface. cPanel has enabled millions of web sites and applications to be deployed by people devoid of any understanding of the complexity that lies beneath them.

This commonality comes at a high cost especially for the unsuspecting customer of a web hosting company that is entirely reliant on cpanel/whm to provide services. Even for those companies that have a small army of sysadmins laboring away behind the scenes giving support to the uninformed can be a thankless task trying to retro-fit patches and upgrades into a cPanel-based provider manually overriding and applying fixes.

Much of this pain is caused because cPanel compiles its own custom versions of software that it makes available to be deploy (such as WordPress,Drupal,and other common CMS and eCommerce suites) and restricts the range of versions of languages and frameworks that are available such as PHP, Python, and Perl. CPanel’s approach to applying patches and security updates has been to simply upgrade to the newest version in which bugs have not yet been found, rather than applying the patches to the existing versions of the applications. This is understandable, as the work required to debug and apply patches to all of these custom compiled versions can be immense. The result often is that that the applications simply aren’t patched as quickly or as methodically as they should be. Another outcome is software versions are either stale, or so bleeding edge that things break. CPanel also stores configuration and log files in non standard locations making diagnostics and support very difficult and outages are longer. All of which adds up to some very unhappy sysadmins.

An Extensible services architecture

OpenShift provides developers and IT organizations an auto-scaling cloud application platform for quickly deploying new applications on secure and scalable resources with minimal configuration and management headaches. This means increased developer productivity, a faster pace in which IT can support innovation, and the means to procuring, provisioning and maintaining a production level system.

Rather than automation by restriction or by obscuring the complexity, OpenShift takes a different more extensible approach. Instead of restricting the range of applications and frameworks, our update and upgrade approach enables us to embrace and encourage diversity and support a polyglot universe.

OpenShift: Easy for Users, Awesome for Admins

OpenShift’s web console allows end-users to launch applications right from the web. From the end-user’s perspective, all they need to do is select an application. Cartridges represent pluggable components that can be combined within a single application. At a minimum, an application needs a language or environment cartridge (like PHP or JBoss EAP). Most applications will also take advantage of a database cartridge.

OpenShift automatically allocates additional system resources for scaled applications without requiring any support from IT. This is the level of automation that that the end user’s demand – especially when they do not have a dedicated IT resource.

Gears combine the partitioning capabilities of control groups with the security features of SELinux. In this manner, OpenShift serves up user applications without (additional) virtual machine overhead. Whenever a new Gear is created on a Node server, CPU and RAM “shares” are allocated for it and along with a directory structure.

The user experience is actually quite similar to that of the cPanel end user for those using the web console. The end user logs in and is authenticated, they choose their application which more than likely has some default “cartridges” already filled in for them. Cartridges represent pluggable components that can be combined within a single application. At a minimum, an application needs a language or environment cartridge (like PHP or JBoss EAP). Most applications will also need a database cartridge (like MySQL or Postgres).

OpenShift supports several “built-in” cartridges based on the most popular app development languages and databases. In order for these to work, the underlying technology must be installed on every Node server in an OpenShift system. This process is described in detail in the Comprehensive Deployment Guide. Additional cartridges can be developed and distributed independently of the rest of the OpenShift system. The OpenShift web console and the rhc utility enable users to add cartridges from a git repository. See the Cartridge Author’s Guide for more information on this. Unlike the cPanel approach, this cartridge model puts the control back into the hands of the PaaS provider and system administrators.

OpenShift Upgrades gracefully with SysAdmins in control

The OpenShift runtime contains an cluster-wide upgrade system used to upgrade the cartridges in a gear to the latest available version and to apply gear-scoped changes which are orthogonal to cartridges to a gear. OpenShift provides SysAdmins with the ability to the upgrade system and can be used to upgrade all gears in an OpenShift environment, all gears on a node, or a single gear.

But wait, There’s more!

OpenShift is infrastructure agnostic. You can run OpenShift on bare metal, virtualized instances, or on public/private cloud instances. The only thing that is required is on top of any Red Hat Enterprise Linux based operating system (RHEL, CentOS or Fedora) as the underlying operating system. We require this in order to take advantage of SELinux and other enterprise features so that you can ensure your installation is rock solid and secure.

This means that in order to take advantage of OpenShift, you can use any existing resources that you have in your hardware pool today. It doesn’t matter if your infrastructure is based on EC2, VMware, RHEV, Rackspace, OpenStack, CloudStack, or even bare metal as we run on top of any Red Hat Enterprise Linux based operating system as long as the architecture is x86_64.

OpenShift offers secure multitenancy. OpenShift leverages the multitenancy and security models within RHEL to provide fine-grained and trusted control over the compute and storage resources available to any single OpenShift application. SELinux allows OpenShift to “firewall” one user’s application from another in order to insure security and survivability. Taking a “multi-tenant in the OS” approach vs. a “multi-tenant hypervisor” approach allows OpenShift to scale resources much more quickly so that your end users’ applications will never lack the horsepower that they need and you can maximize the efficiency of your resources.

OpenShift is Open Source. Unlike cPanel, OpenShift by Red Hat is built on open-source technologies (we are one of the world’s leading open source companies, after all). A decade of enhancements in these technologies contributed by the open source community has resulted in a set of very robust technology components that provide the inner-workings of the OpenShift PaaS.

It’s time to make the change, put cPanel out to pasture and make your sysadmins’ lives easier.

Next Steps:

OpenShift Container Platform, OpenShift Online, OpenShift Origin, Thought Leadership
, , ,
Comments are closed.