Technical Thoughts on OpenShift and Docker - Archived

OpenShift Gear Picture
In case you haven’t heard, last week we announced a partnership with the folks over at DotCloud with their Docker technology. We think it’s a great fit for us and others like TechCrunch agreed: DotCloud Pivots And Wins Big With Docker.

Some have asked me,” Why Red Hat would do this? Aren’t gears and SELinux part of our core strategy?”

Integration Points

To answer those questions, it’s important to take a look at what OpenShift is doing and why this integration is important to us. OpenShift today is comprised of three main components; console/user interface, Broker/API and individual nodes. The nodes contain all the customer applications and for those that pay close attention to such things, they’ll note that the node really has three primary components. The node code (anything that controls the nodes), gears, and cartridges (what makes the gears useful).

Containers and the Composition of a Gear

When we say “gear” we’re functionally talking about a specially defined container. The OpenShift gears of today aren’t traditional LXC style Linux containers that others, including Docker, rely on. Instead they are several different technologies that are combined to look just like a container. At the core of this strategy is our SELinux policy.

The gears we use today prevent access to the other gears and parts of the system we don’t want you to look at. This is a high security computing environment. What this means is trying to get a process list with “ps” inside a gear would show you that ps is actually trying to read everyone’s process info, but SELinux is preventing it. Instead of throwing a bunch of errors, ps just lists what it can read, only your processes. It looks just like you’re in a container, but in reality you’re not. At least not in the way most people think of containers.

Docker and LXC

This is different from traditional namespaced containers. A namespaced container like Docker provides a virtual “dedicated” environment in which to work. Under the covers it’s using LXC. Every container on the system would have a unique /proc/ for example. Each container would also have their own set of users, network interfaces, process id’s, etc. The ps example above behaves differently in a Docker style container, ps would read everything as normal, it’s just that there’s less there to read, the stuff in /proc/ is only relative to what is inside that container.

Chosing Between Security and LXC

There are pros and cons to each setup but in the end when creating OpenShift, we chose the high security route. One of the bigger cons, however, is portability. Every gear has an assigned home directory (different for each gear) as well as an assigned IP. Uniqueness like that in each container is cumbersome to work with. Properly namespacing everything helps go a long way to making gears easier to use.

So along came Docker, a relatively new project that has had wonderful reception in the developer community and elsewhere. We found ourselves at a fork in the road, thinking we only had two options: 1) continue down our current high security path; or 2) pivot and head down the Docker road with traditional containers. Instead we found a way to do both.

Combining Gears, SELinux, and Docker for OpenShift

In looking at the Docker technology and it’s underlying reliance on LXC, as well as our own roadmap, we saw incredible alignment. Creating and managing gears is hard work. By utilizing Docker these bits will be easier. That work combined with the work Krishna Raman has been doing on OpenShift gears in Origin makes it easy to see how Docker fits in to this picture.

This is one major benefit for OpenShift in that we now have an even more secure environment than before. By adding additional container features to our user’s processes we have additional redundancy built in should any of the security features fail. Break out of SELinux? Doesn’t matter, you’re still in a container. Break out of the container and get root? SELinux keeps you stuck in a high security computing environment–look for yourself! It’s not 100% secure and no environment is, but this is a multi-layered security solution and that’s a better computing environment for our users.

Built-in Portability Without Lock-in

Portability and reducing lock-in have been core OpenShift values since we first announced. The truth of the matter is many of our users don’t want to be locked in to OpenShift or any PaaS. We don’t want them to be locked in either. By partnering with a technology like Docker we’re putting our cards on the table and embracing the same technologies the community is embracing. As OpenShift grows, Docker benefits. As Docker grows, Openshift benefits. As our work with Docker continues, our users benefit.

Reading the tea-leaves on when all of this will happen is difficult, we’ve got a lot of work to do. But being able to move Docker containers around and allowing users to run what they want to run in OpenShift and elsewhere is a sure bet. Giving our users options like this will further demonstrate that we’re serious about portability. Red Hat is a different kind of company and we provide a different experience for users. We’re not here to trap you into some long term solution with ever increasing prices. We want to make the kind of technology that we would want to use and with Docker we want to use OpenShift more than ever!

News, OpenShift Container Platform, OpenShift Online, OpenShift Origin
Comments are closed.