In this blog series we are going to introduce to OpenShift,Explain, in depth, benefits of Red Hat OpenShift Container Platform,
technical architecture, CICD and Pipelines with OpenShift and basically everything you need to know about OpenShift. So stay tuned!
What is OpenShift?
OpenShift is a PaaS. For those who don’t know what a PAAS is, take a timecab to the year 2011 and check it out because PaaS is awesome.
Gartner calls OpenShift a Cloud Enabled Application Platform (CEAP).
For those who are not sure anymore, here is a quick reminder.
Platform as a service (PaaS) or application platform as a service (aPaaS) is a category of cloud computing services that provides a platform allowing customers to develop, run, and manage applications without the complexity of building and maintaining the infrastructure typically associated with developing and launching an app
So what is OpenShift then?
OpenShift Container Platform (formerly known as OpenShift Enterprise) is Red Hat’s on-premise private platform as a service product, built around a core of application containers powered by Docker, with orchestration and management provided by Kubernetes, on a foundation of Red Hat Enterprise Linux.
Where OpenShift fits in?
As you can see in the image, the IT landscape has evolved a lot in recent years. We now have DevOps, Microservices, Containers, Cloud and Kubernetes. OpenShift combines all of those things in one platform you can easily manage. So it actually fits right on top of all of that.
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.
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.
Continuous integration: It provides built-in continuous integration capabilities with Jenkins and can also tie into your existing CI solutions.The OpenShift Jenkins iBuild 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.
mage can also be used to run your Jenkins masters and slaves on OpenShift.
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.
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
There are some compelling reasons to look at OpenShift:
Usage of existing technology
Kubernetes and Docker are supported by big communities and are good selections to serve as central components upon which OpenShift is built. OpenShift "just" adds the functionality to make the whole platform production-ready. I also like the approach of Red Hat to completely refactor OpenShift V2 to V3, taking into account what they have learned from older versions and not just simply trying to improve the old code base on top of Kubernetes and Docker.
Development happens publically on GitHub: https://github.com/openshift/origin. OpenShift Origin is"the upstream open source version of Red Hat's distributed application system, OpenShift" per Red Hat.
Enterprise support available
Many enterprises want to or need to have support contracts available for the software which they run their business upon. This is completely possible using the OpenShift Enterprise subscription which gets you commercial support from Red Hat.
The documentation at https://docs.openshift.org/latest/welcome/index.html is very well structured, allowing for rapid identification of a topic youre seeking.
There are some functions which I like the most on OpenShift:
- Application templates: Define all components and variables to run your application and then instantiate it very quickly multiple times with different parameters.
- CLI: The CLI tool "oc" is very well structured and you get it very quickly how to work with it. It also has very good help instructions integrated, including some good examples.
- Scaling: Scaling an application just takes one command to start new instances and automatically add them to the load balancer.
So why not chose Cloud Foundry? At the end of the day, everyone has their favourite tool for their own reasons. I personally found the learning curve for Cloud Foundry to be too steep. I didn’t manage to get an installation up and running with success. Also I had lots of trouble to understand the things around BOSH, a Cloud Foundry-specific configuration management implementation.
There are a few different OpenShift releases depending on what you need. As of this writing, the OpenShift landscape looks like this:
It’s the upstream community project used in OpenShift Online, OpenShift dedicated and OpenShift container Platform. It’s build around Docker and Kubernetes cluster management. Origin is augmented by application lifecycle management functionality and DevOps tooling. Origin updates as often as open source developers contribute via Git. Sometimes as often as several times per week. Here you get the new feature the quickest but at the cost of stability.
Openshift Container Platform
Formerly known as OpenShift Enterprise. It’s the platform software to deploy and manage OpenShift on your own infrastructure of choice. It integrates with Red Hat Enterprise Linux 6 and is tested via Red Hat’s QA process in order to offer a stable, supportable product with may be important for enterprises.
OpenShift dedicated is the latest offering of OpenShift. It’s OpenShift 3 hosted on AWS and maintained by Red Hat but it is dedicated to you
OpenShift Online is managed by Red Hat’s OpenShift operations team, and quickstart templates enable developers to push code with one click, helping to avoid the intricacies of application provisioning. You can view it as OpenShift delivered as a SaaS (Software as a Service)
Quick insight to openshift 3- What does it look like?
OpenShift consists of these main components:
- Master The API and Kubernetes Master / Scheduler
- Nodes Runs pods, including the workload
- Registry Hosts docker images
- Services / Router Takes client requests and routes them to backend application containers. In a default configuration it’s a HAProxy load balancer, automatically managed by OpenShift.
For a deeper insight, consult the OpenShift Architecture
Figure: OpenShift Architecture.
To better understand OpenShift and its core-component Kubernetes, it’s important to understand some key terms:
- Pod "In Kubernetes, all containers run inside pods. A pod can host a single container, or multiple cooperating containers". Roughly translated, this means that containers share the same IP address, the same Docker volumes and will run always on the same host.
- Service A pod can offer services which can be consumed by other pods. Services are addressed by their name. This means for example a pod provides a HTTP service on the name "backend" on port 80. Another pod can now access this HTTP service by just addressing the namespace of “backend”. Services can be exposed externally from OpenShift using an OpenShift router.
- Replication Controller A replication controller takes care of starting up a pod and keeping it running in the event of a node failure or any other disruptive event which could take a pod down. It is also responsible for creating replication pods in an effort to horizontally scale the lone pod.
There is so much more to discuss and show about PaaS and OpenShift. I hope that with this post you got a nice introduction to OpenShift itself and some of the benefits it offers. This was the first blog of OpenShift A-Z series, we will go through a setup of complete pipeline with jenkins and OpenShift in next blog, so make sure to regularly check blog.crevise.com
May the PaaS be with you.