Red Hat OpenShift is available in four models:
- OpenShift Container Platform
- OpenShift Online
- OpenShift Dedicated
- OpenShift.io
OpenShift Container Platform
Known as OpenShift Enterprise until a June 2016 name change, OpenShift Container Platform is a private platform as a service (PaaS) for organizations that deploy and manage OpenShift on their own on-premises hardware or on the infrastructure of a certified cloud provider.
OpenShift Container Platform is implemented as an assemblage of Docker-based application containers managed via Kubernetes orchestration, all running on an operating system foundation of Red Hat Enterprise Linux (RHEL).
OpenShift Online
Introduced in 2011, OpenShift Online is for individual developers or teams that access OpenShift as a public cloud service. OpenShift Online is implemented as an on-demand consumption model hosted on public cloud platforms, including Amazon Web Services (AWS).
The latest version of OpenShift Online, released in May 2017, provides a container-based platform that developers can access from any web browser, IDE and command line. It also provides support for local development, enabling programmers to deploy a functional OpenShift cluster on their local workstations, and it supports port forwarding, which enables developers to use remote services as if they were running locally.
OpenShift Online was built with the same code as OpenShift Container Platform, and it is the deployment platform for OpenShift.io.
OpenShift Dedicated
OpenShift Dedicated offers organizations the ability to run a single-tenant OpenShift environment on a public cloud managed by Red Hat while incorporating Docker and Kubernetes orchestration technologies.
At the time of its launch in December 2015, OpenShift Dedicated ran only on AWS. Support for Google Cloud Platform was added in December 2016. As of July 2017, support for Microsoft Azure is not offered.
OpenShift.io
Announced in May 2017, OpenShift.io is a free, open-source supplement to OpenShift Online. Together, they offer an integrated approach to DevOps that incorporates tools for development teams to create and deploy microservices-based applications.
OpenShift.io also provides a Linux container environment and a machine learning system that assist developers with design decisions. OpenShift.io encompasses several open source development technologies, including fabric8, Eclipse Chef, Jenkins, OpenJDK, Performance Co-Pilot, WildFly Swarm, Eclipse Vert.x and Spring Boot.
How Red Hat OpenShift works?
According to Red Hat, the key to OpenShift lies in the combination of Docker containers and Kubernetes orchestration, both built on RHEL. By using Docker at its model, OpenShift enables any app created with it to run anywhere else that Docker containers are supported.
After developers push code to OpenShift either through software version control or continuous integration/continuous delivery (CI/CD) systems, OpenShift orchestrates how and when the apps run. It also enables dev teams to fix, fine-tune and scale those apps as quickly as needed. Containers associated with OpenShift can serve as web frameworks or stateful services, according to Red Hat.
In addition to enabling developers to create their own containers, OpenShift provides an online container catalog with contributions from Red Hat and third parties. Some popular categories include container management, mobile application development, operating systems, programming languages, logging and monitoring, and database management.
Why use Red Hat OpenShift?
As container use increases in app development and production, services such as OpenShift offer ways to manage and automate a large number of containers. Doing so frees up developers from the manual management of containers.
Also, OpenShift can help IT organizations bridge legacy servers supporting traditional applications and modern, microservices-based work. These features feed into a mobile-first approach for companies that want to produce smartphone and tablet apps quickly.
Finally, OpenShift's options promote continuous app development and common tools for development and operations teams. This approach is a cornerstone of DevOps efforts.
OpenShift Features:
Self-Service
Self-service Developers can quickly and easily create applications and deploy them. With S2I (Source-to-Image), a developer can even deploy his code without needing to create a container first. Operators can leverage placement and policy to orchestrate environments that meet their best practices. It makes your development and operations work fluently together when combining them in a single platform.
Polyglot, Multi-Language
multilanguage Since it deploys Docker containers, it gives you the ability to run multiple languages, frameworks and databases on the same platform. You can easily deploy microservices written in Java, Python or other languages.
Automation
Build automation: OpenShift automates the process of building new container images for all of your users. It can run standard Docker builds based on the Dockerfiles you provide and it also provides a “Source-to-Image” feature which allows you to specify the source from which to generate your images. This allows administrators to control a set of base or “builder images” and then users can layer on top of these. The build source could be a Git location, it could also be a binary like a WAR/JAR file. Users can also customize the build process and create their own S2I images.
Deployment automation: OpenShift automates the deployment of application containers. It supports rolling deployments for multi-containers apps and allows you to roll back to an older version.
Continuous integration: It provides built-in continuous integration capabilities with Jenkins and can also tie into your existing CI solutions.The OpenShift Jenkins image can also be used to run your Jenkins masters and slaves on OpenShift.
Scalable
When you want to start scaling your application, whether it’s from one replica to two or scale it to 2000 replicas, a lot of complexity is added. OpenShift leverages the power of containers and an incredibly powerful orchestration engine to make that happen. Containers make sure that applications are packed up in their own space and are independent from the OS, this makes applications incredibly portable and hyper-scalable. OpenShift’s orchestration layer, Google’s Kubernetes, automates the scheduling and replication of these containers meaning that they’re highly available and able to accommodate whatever your users can throw at it. This means that your team spends less time in the weeds and keeping the lights on, and more time being innovative and productive.
Opensource
opensource There are multiple versions of OpenShift (spoiler: it’s going to be the next topic in this blog post) but they are all based on OpenShift Origin. Origin provides an open source application container platform. All source code for the Origin project is available under the Apache License (Version 2.0) on GitHub
Infrastructure
OpenShift runs on your choice of infrastructure (Physical, Virtual, Private, Public). OpenShift uses a Software-Defined Networking (SDN) approach to provide a unified cluster network that enables communication between pods across the OpenShift cluster. This pod network is established and maintained by the OpenShift SDN, which configures an overlay network using Open vSwitch (OVS).
- The OVS-subnet plug-in is the original plug-in which provides a “flat” pod network where every pod can communicate with every other pod and service.
- The OVS-multitenant plug-in provides OpenShift Enterprise project level isolation for pods and services. Each project receives a unique Virtual Network ID (VNID) that identifies traffic from pods assigned to the project. Pods from different projects cannot send packets to or receive packets from pods and services of a different project. However, projects which receive VNID 0 are more privileged in that they are allowed to communicate with all other pods, and all other pods can communicate with them. In OpenShift Enterprise clusters, the default project has VNID 0. This facilitates certain services to communicate with all other pods in the cluster and vice versa.
NODES
A node provides the runtime environment for containers. Each node in a Kubernetes cluster has the required services to be managed by the master. OpenShift creates nodes from a cloud provider, physical systems, or virtual systems. Kubernetes interacts with node objects that are a representation of those nodes. A node is ignored until it passes the health checks, and the master continues checking nodes until they are valid. In OpenShift nodes are instances of RHEL (Redhat Enterprise Linux).
PODS
OpenShift leverages the Kubernetes concept of a pod, which is one or more containers deployed together on one host, and the smallest compute unit that can be defined, deployed, and managed. Each pod is allocated its own internal IP address, therefore owning its entire port space, and containers within pods can share their local storage and networking. Pods have a lifecycle; they are defined, then they are assigned to run on a node, then they run until their container(s) exit or they are removed for some other reason. OpenShift treats pods as largely immutable, changes cannot be made to a pod definition while it is running. It implements changes by terminating an existing pod and recreating it with modified configuration, base image(s), or both. Pods are also treated as expendable, and do not maintain state when recreated.
REGISTRY
Integrated OpenShift Container Registry: OpenShift Origin provides an integrated container registry called OpenShift Container Registry (OCR) that adds the ability to automatically provision new image repositories on demand. This provides users with a built-in location for their application builds to push the resulting images. Whenever a new image is pushed to OCR, the registry notifies OpenShift about the new image, passing along all the information about it, such as the namespace, name, and image metadata. Different pieces of OpenShift react to new images, creating new builds and deployments.
Third Party Registries: OpenShift Origin can create containers using images from third-party registries, but it is unlikely that these registries offer the same image notification support as the integrated OpenShift Origin registry. In this situation, OpenShift Origin will fetch tags from the remote registry upon imagestream creation.
MASTER
Managing data storage is a distinct problem from managing to compute resources. OpenShift leverages the Kubernetes PersistentVolume subsystem, which provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed. The Kubernetes pod scheduler is responsible for determining the placement of new pods onto nodes within the cluster. It reads data from the pod and tries to find a node that is a good fit based on configured policies. The Management/Replication controller manages the lifecycle of pods. For instance, when you deploy a new version of your application and create a new pod, OpenShift can wait until the new pod is fully functional before downscaling the old pod leading to no downtime. But what if the master node goes down? That’s no high availability … You can optionally configure your masters for high availability to ensure that the cluster has no single point of failure.
SERVICE LAYER
On top of the domain and persistence layer sits the service layer of the application. A Kubernetes service can serve as an internal load balancer. It identifies a set of replicated pods in order to proxy the connections it receives to them. Backing pods can be added to or removed from a service arbitrarily while the service remains consistently available, enabling anything that depends on the service to refer to it at a consistent internal address.
PERSISTENT STORAGE
Managing storage is a distinct problem from managing to compute resources. OpenShift Origin leverages the Kubernetes Persistent Volume (PV) framework to allow administrators to provide persistent storage for a cluster. Using Persistent Volume Claims (PVCs), developers can request PV resources without having specific knowledge of the underlying storage infrastructure. PVCs are specific to a project and are created and used by developers as a means to use a PV. PV resources on their own are not scoped to any single project; they can be shared across the entire OpenShift Origin cluster and claimed from any project. After a PV has been bound to a PVC, however, that PV cannot then be bound to additional PVCs. This has the effect of scoping a bound PV to a single namespace (that of the binding project).
