Welcome to OpenShift Enterprise 2.2! We released the OpenShift Enterprise 2.0 (OSE) code base back in December of 2013 and had a significant minor release just this past spring when we released OpenShift Enterprise 2.1. The goal and focus of the OSE 2.x product release has revolved around datacenter integration and enterprise workflows.
People want to the take the vibrant eco-system of applications and runtimes their developers are leveraging out on OpenShift Online and run them inside their datacenter while offering a tighter integration with IDEs, code version systems, and build factories. Operationally, they want to increase workload density on existing server assets, automate security, enhance configuration management, and unravel networking tasks involved with the rapid pace of continuous delivery.
Today we announce OpenShift Enterprise 2.2. The OSE 2.2 release continues the focus of previous minor releases and rounds out the more common datacenter intersection points we have encountered during the many deployments of OpenShift Enterprise in 2014. As I look across the release, these core features jump out at me the most.
We hope you enjoy using these features as much as we have enjoyed making them. 2013 and 2014 have been amazing years for OpenShift Enterprise. We have seen customers accomplish amazing things with the platform and we look forward to the future.
JBoss A-MQ and JBoss Fuse Cartridges
This is a brand new day for PaaS platforms. With the inclusion of Red Hat JBoss A-MQ and JBoss Fuse cartridges, OpenShift opens PaaS platforms to being able to support non-HTTP/S TCP based traffic over a larger variety of ports. This opens the flood gates to being able to run more complex, enterprise application topologies natively on the PaaS rather than on the side.
JBoss Fuse for xPaaS is an enterprise service bus technology for building and implementing communication between different applications, services, and data. It is specifically designed for extensive connectivity. It includes JBoss A-MQ for xPaaS, a messaging service to connect applications and devices using notifications and messages. With OpenShift you can easily deploy and run JBoss Fuse for xPaaS components like messaging brokers and containers and deploy solutions to connect applications and data using the most extensive set of messaging protocols and connectors. JBoss Fuse for xPaaS is available on OpenShift Enterprise and provides private iPaaS like capabilities.
oo-install: High Availability Made Easy
OpenShift introduced oo-install as a simple to use command line utility for installations of the product. Over the course of 2014, oo-install has become more mature. With OSE 2.2, oo-install becomes capable of deploying multiple Brokers, multiple message servers, and multiple mongoDB nodes all from a single, easy to understand question and answer session. The result is a highly available deployment of OpenShift. Previously to this release, customers could achieve the same HA result by manually following the documented steps, using one of the supplied puppet modules, or using the OpenStack HEAT templates for OpenShift.
By adding this feature to oo-install, we complete HA coverage across all the installation methods for the product. All the configuration needed around sharding mongoDB and clustering the Broker and message servers have been automated. From a single node, you can remotely install a complex and highly available deployment of OpenShift Enterprise solution by answering a few simple questions from oo-install.
Cartridge to Gear Profile Relationships
Platform administrators have asked us for a way to force end users to select specific gear profiles (small, med, large, etc) based on the cartridge they have chosen to deploy. If the administrator knows that a cartridge should only be able to be installed on a medium sized gear, s/he now has the ability to force a mandatory selection of that gear profile.
Not only does this help alleviate performance issues that can come up later if an application was under resourced from the beginning, but it also allows platform administrators to place cartridges on specific nodes, in specific districts, in specific zones, and in specific regions. Previously, customers would direct applications based on gear profile selection (small-prod, med-QA, small-prod). Now customers can expose applications in the self service catalog and know with certainty that the end user is going to land on an environment made for that application.
RHC Region Selection
In a previous release, OSE offered an ability for administrators to create availability zones within regions. This would trigger an automatic spanning of end user’s deployed application across zones as automatic scaling occurred. We did not however expose the region selection in the browser user interface for the end user. End users needed to issue a REST API to select the region or select a gear profile that mapped to a zone within a region.
Hopefully you noticed that OpenShift Online is now available with AWS EU region selection options. We have seen some great usage and exercise of region selection and decided to ship the user experience in OSE 2.2. Enjoy!
Broker X.509 Authentication
OpenShift has been deployed in more and more areas of the datacenter that are highly protected (in terms of security) over the course of 2014. We have found a few customers asking us for X.509 PKI/PMI certificate support. As you may know, OpenShift’s broker layer can handle whatever AUTH apache can handle and so X.509 is supported. What we had not done until now was to document how to configure the Broker for X.509. That task is now complete.
One of the best, most extensible interfaces in OpenShift Enterprise is the DNS Plugin framework. Why? Well let’s face it. What’s the point of creating an application that no one can see? The ability for the product to call out to an external DNS and expose a newly created application on the network is key to the devOps experience.
One of the nice things about sitting back and watching over the many OpenShift Enterprise production deployments is that you get to see commonalities. We then take the more frequently usage integrations, and place them into the product. This year we have seen a lot of DYN(tm) and Infoblox(tm) usage. And so we are excited to introduce an out of the box experience for those infrastructure DNS services. Not only that, but we also included a DNS Fog plugin which allows you to integrate OpenShift with any DNS service that supports Fog with very little customization.
We have found that the operations team responsible for the PaaS is not always the same team that is in charge of the DNS. An out of the box experience for the more common implementations really help these two teams deploy a mutually acceptable solution in the least amount of time.
Ruby has been a popular language for developers that have been interested in our PaaS. With OSE 2.2, we add Ruby 2.0 to the already supported Ruby 1.8 and 1.9 versions. Within the Ruby community, the move from 1.9 to 2.0 has been well received and so we have a number of on premise customers anxious to get their hands on this cartridge. Keep in mind, you can always deploy a cartridge with a newer version of Ruby (for example 2.1.4). The difference is, with our cartridge we are supporting not only OpenShift but also Ruby itself. We are taking on the responsibility to provide security and bug fixes to Ruby for you. Your subscription to OpenShift includes within it a subscription for RHEL and the RHEL Software Collections. OpenShift is bringing to you a tremendous amount of value through that entitlement relationship.
It might not jump out at you at first as to why this bug protection is important. What we have found over the course of 2013 and 2014 is due to the fact we offer this protection on not only OpenShift, but also the application runtimes and framework plus underlying operating system, it opens the door to enterprise customers being able to leverage newer languages within their datacenters. For you see, once an enterprise gets to a certain size it needs to live by rules and regulations. Many of those compliance laws require them to stay within 30 days of known CVEs and bug fixes. If OpenShift was not doing this (like is the case with other on premise PaaS providers), our customers would be forced to spend time and money establishing a process to not only find the issues but also get and install the fixes. OpenShift Enterprise removes that operational cost.
Nginx Application Integration
OpenShift not only deploys your application, but it also deploys a scalable routing tier right in front of your application. Every application deployed automatically gets an HAProxy instance to load balance the network traffic across the multiple gears it might consume. Many customers integrate that HAProxy with existing datacenter fabrics. In OpenShift Enterprise 2.1, we introduced an ability to have more than 1 HAProxy get deployed. The number of HAProxies is configurable to the applications needs. We then offered an example listener to enable people to place a load balancer in front of the HAProxies.
As was the case with the DNS plugins, we noticed a strong usage of nginx in the community for this layer. And so we decided to ship a supported routing listener for nginx in OpenShift Enterprise 2.2 that allows you to effectively balance incoming traffic across the HAProxy instances that support your application. At the same time, we also decided to improve the end user experience. In the past a developer had to issue a REST API to receive a highly available application. We have decided to allow developers to access this feature through the rhc command line. Thus making it very easy to obtain a highly available application on OpenShift.
You can always tell a product is getting serious traction in production usage if people are asking it to support IPv6. OpenShift Enterprise is no exception. We have seen a strong use of IPv6 in the government and telecommunication customers. With this release of OpenShift Enterprise we support the use of IPv6 where it matters the most; on the external interfaces. How you access applications deployed on the PaaS, how you access the Broker, how you connect to the platform (pretty much the interfaces humans use) can be IPv6. Where we still need IPv4 is on the interfaces where internal communication occurs. For example, how the broker talks to mongoDB, or where the mcollective talks to the messaging server, those all need to be IPv4. Thus, in this release, we are qualified for IPv6 tolerance.