Announcing OpenShift Enterprise 2.0

Welcome to the 2013 holiday season.

The OpenShift community has worked hard this past year to bring you many amazing new features. Since OpenShift is available as a Public PaaS offering via OpenShift Online, many of these features are already available today.

If you want to run OpenShift ten layers under a firewall inside your own datacenter, you can with OpenShift Enterprise. OpenShift Enterprise gives you the same features of OpenShift Online as a Private, or on-premise, Platform as a Service (PaaS) deployment model. OpenShift innovates because of input from both of these diverse user bases combined with our upstream OpenShift Origin community. Through this unique triumvirate we've driven innovation and delivered many new features spanning a mutlitude of use cases.

Without further adieu, we give to you OpenShift Enterprise 2.0!

Datacenter Integration

OpenShift Enterprise is deployed across a number of datacenters owned by a diverse and growing customer base. Every customer and industry segment has unique infrastructure, facilities, ITIL requirements, regulations, and general best practice runbooks. We've taken many frequent and common requests and given them to you in OpenShift Enterprise 2.0. In a nutshell, we improved the integration points between the PaaS platform itself and the datacenter around it.

• Installation: OpenShift Enterprise has redesigned the installation experience. In previous releases we exposed the installation engine directly as the interface layer to the customer. Now with the OpenShift Enterprise 2.0 release, we've wrapped installation logic and a CLI wizard around that engine to greatly simplify installation and improve the out of the box user experience. While the installation wizard will drive our OpenShift Enterprise installer scripts, it can also generate YAML configuration files that can alternatively be used to drive popular installation methods such as Puppet, Chef, and Anisible. Plus, to assist in the identification of OS level configuration and entitlement issues, we have created a pre-flight check that will help fix any issues it might find in your RHEL environment before installation.

• OpenShift on OpenStack: To simplify the installation of OpenShift on OpenStack, we've also developed OpenStack Heat orchestration templates to automate your OpenShift PaaS deployment.

If you haven't had time, please check out the following information resources:

• OpenShift Installer Documentation
• OpenShift Installation Video
• OpenStack Deploys OpenShift

Sample snippet from a oo-install-cfg.yml

Description: This is the configuration file for the OpenShift Installer.

Version: 0.0.1

Vendor: OpenShift Origin Community

Subscription:

  type: none

Deployment:

  DNS:

    app_domain: barrett.com

    register_components: "no"

  Hosts:

  - ip_addr: 192.168.1.25

    user: root

    ip_interface: eth0

    roles:

    - broker

    - mqserver

    - dbserver

    - node

    host: rhel-6-5-services

    ssh_host: rhel-6-5-services

• Routing Fabric Integration: Customers typically have large investments and entire groups of dedicated staff to insure the health of the network across large datacenters. They wanted OpenShift to offer more subscription based interfaces so they could leverage their existing load balancers and routers with the applications that are running on the PaaS platform. This release opens the door to pre-determined (publically defined events) communication from the OpenShift messaging layer with a special attention paid to application events that should be leveraged by external routers and load balancers. On top of that, we know that high availability comes down to the weakest link in the chain, so we have created the option to deploy more than one HAProxy for scalable applications. The connection between those two features coming together allows for a very tolerant configuration.

• Kerberos Support: Although developers value having direct ssh access to the gears containers where their applications run, some datacenters have desire the additional security of kerberos integration. OpenShift 2.0 now allows kerberos principals to be associated with a user account for SSH access to gears as an alternative to key-based access.

• IPtables: IPTables DNAT is now being leveraged in the platform. This moves the node level port routing to the most efficient layer possible at the kernel.

• Gear Idling Improvements: Gear idling is an optional feature that enables administrators to recover idle capacity from applications that are no longer being accessed. Idle gear restoration (wake-up) now works via web socket requests. This is in addition to the previously supported http/https requests.

Application Deployment Enhancements

• Environment Variables: Over this past year, customers have loved the consistency and configuration control they have received from their self-service PaaS solution. At the same time, in order to re-use the common cartridges and applications for multiple deployment types across QA, Staging, and Production, customers have asked to be able to expose environmental variables so they can drive configuration changes at time of deployment. Environmental variables open the door to endless possibilities. Imagine wanting to deploy a web stack that feeds from a test database one minute and then the next minute wanting to deploy the same stack except this time pulling from the production database. That can be as easy as setting an environmental variable. Or maybe you want to set a license string, a password, or username. The list goes on forever. Whatever the cartridge author wants to expose to the deployer or user is up to him. Then for the user, leverging those is as easy as using the existing rhc command line. See some examples.

    $ rhc env list -a myapp

    $ rhc env set Variable=Value Variable2=Value2 -a myapp

    $ rhc env unset Variable -a myapp

    $ rhc env show Variable Variable2 -a myapp

Or you can use the Eclipse IDE user interface:

• Smart Deployment Options: Developers love the streamlined application deployment workflows that are possible through the out of box integration OpenShift has with Git, Jenkins, and build automation tool chains like Maven. But users demanded even more flexibility in how they deploy application content. Everything from which code branch, time traveling back (rollback) to a previous deployment, deploying binary artifacts instead of code once you enter into specific PDLC life cycles and more. With that in mind we have given both operations and development something to write home about with new "smart" deployment options. See the following blogs for some great examples:

  • Online Release for November 2013
  • Introduction to Deployments and Rollbacks on OpenShift

    $ rhc configure-app -a app_name --no-auto-deploy

    $ rhc deploy test_branch -a app_name

    $ rhc configure-app -a app_name --keep-deployments 10

    $ rhc deployments app_name

    $ rhc activate-deployment deployment_ID -a app_name

    $ rhc configure-app -a app_name --deployment-type binary|git

    $ rhc deploy ./app.tar.gz -a app_name

    $ rhc deploy http://foo.com/path/to/file.tar.gz -a app_nam

Operational Awareness

Anything that is as popular as OpenShift within your datacenter is going to grow quickly. People love a solution that equally enables operations and development to get stable applications to customers as quickly as possible. But with growth comes the concern of how do you control and "see" the environment.

• Administration Console: Welcome to the OpenShift Enterprise 2.0 Administration Console. The main goal of the console is to show usage penatration and oversubscription across this high density platform while helping to find out who is living where on the platform and what they have deployed.

Learn more about this great new feature.

• Statistics: We spent a lot of time this release improving the oo-stat interface. You'll find a more complete view of important usage information is available now through this easy to use command line interface.

Developer Experience

We can't forget about the users of the platform. For them it comes down to how well the solution fits into their own world. It must make them as comfortable and productive as possible. That involves both depth of content and ability to leverage it effectively. There is no point to a PaaS if you can't do what you want on it.

• Team Collaboration: No one person is an island. OpenShift has added an amazing feature set around teaming that can be used for peer to peer agile scrum'ing or as a control mechanism for an operations/owner to developer/user experience. Now a developer or user of the PaaS can add other developers to his application so that more than one person can work on a project in a controlable manner. At the same time, if regulations prevent that from occuring, operations can control the projects and add or remove developers and quality assurance engineers as needed. You can organize for high velocity or traditional ITIL life cycle relationships. Team members can be added via the Web console and rhc command line interface.

Now that more people will be able to get involved in application projects in a controlled manner, we need to estiblish some defined roles. OpenShift has added the classic three roles of viewer, editor, and admin.

• Viewer: view application data (except for env variables)
• Editor: edit/add/remove apps/cartridges/env vars and settings including git/ssh
• Admin: adds modifying domain/team members plus roles (except for changing gear sizes or changing domain's name)

• Cartridge Upgrades: As a leader in both operating system development and middleware solutions, Red Hat is in a unique position to provide some amazing content to PaaS users, which are integrated as OpenShift Cartridges. With the advent of the RHEL Software Collections we are now able to bring Node.js to our OpenShift Enterprise users and also have updated our Python, Ruby and Postgresql cartridges. OpenShift Enterprise users can also continue to leverage existing cartridges for Java (via JBoss EAP or Tomcat), Ruby, PHP, Perl, MySQL, Jenkins and more.

Red Hat is unique in providing native support for all these cartridge runtimes. Users can count on Red Hat support as well as runtime secuirty updates and bug fixes from the yum channels that are entitled through your subscription to OpenShift. Plus we have a growing community of developers and ISV partners that produce more and more content daily out on openshift.com and github that is at your finger tips.

• JBoss Developer Studio 7.1 Feature Integration: We have updated the eclipse IDE solution to take advantage of both the new teaming and related multi-domain namespace feature as well as the new environmental variable feature. This allows for the developers to remain in the tooling they are more comfortable with for longer periods of time.

• Better Integrations with Jenkins: We have improved the interaction between Jenkins and some of the cartridges available on the platform. PHP PEAR now works with Jenkins.

• Look and Feel Enhancements: We spent time going over the coloring, menu choices, and general layout of the Web user interface. We feel you will enjoy these usability improvements.

• Cartridge Extensiblity: Applications and runtimes delivered through cartridges can now bind to any port above 1024 within a gear (linux container). This will help users keep application configuration more consistent off and on the PaaS platform.

As you can see, OpenShift Enterprise 2.0 is ready to take your datacenter to its next generation of architecture and design. Let OpenShift help connect your past to your future and enable your teams to deliver the applications your customers desire at the speed of business.

Red Hat is a champion of opensource solutions and offers a variety of ways to get involved.