Deploying to OpenShift

Chapter 1. The OpenShift Container Platform

The OpenShift platform was launched in May 2011. The source code was made available through an open source project, with anyone being able to download it and use it. Red Hat also offered a supported version of OpenShift for use in enterprise deployments, and a hosted service called OpenShift Online.

OpenShift has always been implemented on top of containers, but technology is always evolving. In June 2013 a major rewrite began to reimplement OpenShift on top of the latest evolving technologies in the container space. Version 1.0 of OpenShift Origin, based around Kubernetes and the Docker container runtime, was released in June 2015. At the time of writing this book OpenShift 3.6 was the latest version, with the 3.7 release imminent and new releases coming out on a quarterly basis.

What exactly is OpenShift, though?

In simple terms, it is a platform to help you develop and then deploy applications to one or more hosts. These can be public-facing web applications, or backend applications including microservices or databases. Applications can be implemented in any programming language you choose. The only requirement is that the application can run within a container.

OpenShift can run anywhere you can run Red Hat Enterprise Linux (RHEL), CentOS, or Fedora. This can be on public or private cloud infrastructure, directly on physical hardware, or using virtual machines.

In this initial chapter you will learn more about the technologies that OpenShift uses, and where it fits within the cloud computing ecosystem.

The Role of Containers

The National Institute of Standards and Technology (NIST) defines as part of their definition of cloud computing three standard service models for the provision of cloud computing services:

Software as a Service (SaaS)

The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

Platform as a Service (PaaS)

The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.

Infrastructure as a Service (IaaS)

The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls).

Under these traditional definitions for cloud service computing models, OpenShift would be classified a PaaS. In both PaaS and SaaS models, containerization is often used for separating applications from each other and from different users.

Containers as a technology have a long history, with forerunners being FreeBSD jails and Solaris Zones. In Linux, support for containers revolves around the Linux Containers project (LXC). This brought user-space tooling on top of Linux kernel features such as cgroups and namespaces, with security additions from Seccomp and SELinux. The LXC tools made the use of containers in Linux accessible, but it could still be a fiddly process to set up and run applications in containers.

In 2013 a company called dotCloud, a PaaS provider, announced in a lightning talk at PyCon US a tool called Docker. This tool was an outgrowth of the proprietary technology that dotCloud used to help run applications in containers; it provided a wrapper for making it easier to launch applications in containers using LXC.

The Docker tool was quickly picked up by developers as it addressed two key issues. The first was a definition of a common packaging format for an image, which contained an application and all the dependencies it required, including operating system libraries and programs. The second was tooling for building this image.

These together made it possible to create application images that could be easily moved between different systems, to then be run in a container, with higher confidence that they would work out of the box.

The technology around the Docker tool was split out separately from the company dotCloud and a new company, Docker Inc., was created to manage development of the technology. Because of the growing interest in the technology, the Open Containers Initiative (OCI) was later formed to provide an open governance structure for the express purpose of creating open industry standards around the container format and runtime. This process was seeded with specifications derived from the Docker tool. OCI currently acts as the steward for two specifications: the Runtime Specification (runtime-spec) and the Image Specification (image-spec).

Orchestrating at Scale

The Docker tool made it easier for developers to build application images and run a single application in a container on a single host. But scaling up an application to have multiple instances running on the same host, or across multiple hosts, required additional software components to help orchestrate the deployment and running of the application, as well as a router to load-balance traffic to each instance of the application.

During the initial phase of Docker adoption, no out-of-the-box solutions existed for the orchestration and routing layer, which resulted in users handcrafting homegrown solutions.

In mid-2014, Google announced the Kubernetes project, an open source system for automating deployment, scaling, and management of containerized applications. This provided one of the missing components required in trying to handle running containers at scale.

At the time, Red Hat was already well into a project to reimplement OpenShift around Docker but had been implementing its own orchestration layer. With the announcement of Kubernetes, Red Hat decided to drop its own efforts, adopting Kubernetes and becoming a major contributor to the project.

Kubernetes was subsequently released as 1.0 in July 2015, with the project being donated to the Cloud Native Computing Foundation (CNCF). It has since become the de facto standard for container orchestration.

Containers as a Service

Kubernetes does not fit any of the existing service model classifications for cloud computing. This has resulted in the new name, Containers as a Service (CaaS), being coined. This service model can be seen as similar to IaaS, except that instead of being provided with a virtual machine, you are provided with a container. Figure 1-1 shows where CaaS fits in among the other service models.

Figure 1-1. Cloud services

To run your application in a CaaS, you need to provide the application image you have built, which contains your application and any operating system libraries and programs you require. Although an application image contains a copy of these operating system libraries and programs, it is only your application process that is run.

Platform as a Service

Using the CaaS capability of Kubernetes, OpenShift is able to deploy an application from a container image stored in any image registry. Kubernetes alone does not provide any support for building the container image. You need to run a build tool to create your application image on a separate system and push that to an image registry from which it can be deployed. This is because a CaaS focuses on just running containers and lacks the capability of a PaaS, where you can provide your source code and the platform will work out how to get that running in a container.

To provide the PaaS capability of being able to take source code and deploy it, OpenShift adds automation for performing builds on top of Kubernetes. OpenShift supports two main strategies for building from source code.

In the style of a traditional PaaS, OpenShift can take your application source code and, using a builder for the programming language you are using, create your application image. You as a developer do not need to provide instructions on how to create the container image; the platform will do this for you.

In addition, OpenShift can also accept source code that includes a set of instructions to create the application image in a Dockerfile. This is what you need to do if building a container image yourself using Docker, but OpenShift will do it for you, inside the OpenShift platform.

In both cases, OpenShift will cache the application image in an image registry that it provides. The application image will then be deployed from this internal image registry.

Using OpenShift to build the application image from a Dockerfile means you do not need to have the Docker tool on your own system, nor do you need to use a separate image registry to hold your images.

With both types of builds, OpenShift can pull the source code for the build from a hosted Git repository. If you’re using a service such as GitHub, GitLab, or Bitbucket, you can configure the Git repository hosting service to notify OpenShift whenever you push changes to your code back to the hosted Git repository. This notification can trigger a new build and deployment of your application.

This automation means that once you have set up your application in OpenShift, you do not need to interact directly with OpenShift as you continue with your application development. As soon as you push back changes to your hosted Git repository, OpenShift will know and can build and redeploy the application automatically.

Deploying Your Application

By building on top of Kubernetes, adding its own automation for builds and deployments, OpenShift operates as both a CaaS and a PaaS. In other words, OpenShift implements a general-purpose container platform. You can deploy your own bespoke applications, or you can import third-party applications such as databases, messaging systems, or other business suites to support the business processes of your organization.

In this book you will learn about the different ways you can deploy applications to OpenShift. This will include deploying from a prebuilt application image using the CaaS functionality of OpenShift, and building from source code in the manner of a PaaS.

You will also learn how to integrate your application into the OpenShift platform, how to configure it through OpenShift, how to mount persistent volumes, how to make it public so users can access it, and how to monitor and debug your application.

To interact with OpenShift you can use either a web console or a command-line client. This book will focus on using the command-line client.

The main application example that will be used throughout the book is a Python application implemented using the Django web framework. This is the same sample application that is used in many of the tutorials found on the OpenShift Interactive Learning Portal. In addition to reading through this book, you can use those tutorials to further investigate many of the topics we cover.

The source code for the sample application can be found on GitHub.

If you wish to work through the example in the book yourself, you can use the playground environments on the OpenShift Interactive Learning Portal. The playgrounds don’t follow a set tutorial, and you are free to try anything you want.

You can also install OpenShift yourself, or use a hosted OpenShift service. The next chapter will discuss options for running OpenShift, with the remainder of the book then showing you how to use it so you can learn to deploy your own applications.