Redhat Openshift — 4.2
Openshift software is govern by Redhat and it is a core product of Redhat. Openshift is the revolutionary tool in DevOps World. Before starting with openshift let understand the containerization technology, management tool, monitoring tool in detail which will give us complete workflow of Openshift .
- Containerization technology: docker, podman, CRI-O
- Management Tool: Kubernetes
- Monitoring Tool: Prometheus
- Containerization technology :
As most of company is moving from virtualization technology to containerization technology. Why? Because containerization technology is very fast in launching the operating system (container) and deploying the application. Docker, Podman, CRI-O are the most powerful product of containerization technology. The duty of all this product is just to manage the container. Concept wise docker, podman and CRI-O all are same.
What we need to run any application ?
We need operating system to use any application (Ex. Firefox, Ms-office, Python, etc). If you want to use application we need operating system and for operating system to start we require physical storage (RAM, CPU, HD, etc.). Also to run any application we require kernel which helps to run the services of application (Example: If you want to start a vlc player, kernel will help to run the services of vlc player). Kernel provide all the module and driver to run the services.
- Docker :
Let’s take a real use case:
On top of your hardware you have installed Redhat Linux OS. On top of OS you have installed docker. So docker get the storage from base OS hardware and they use the kernel of the base OS Redhat Linux (kernel is a core of any OS, kernel provide driver’s to run services of any application/process). We can say it is a sharing of resources and kernel with docker. Docker Container Engine is the layer between base operating system and docker. Docker creator (Solemon Hykes) created this layer of container engine so that it contact runc (run time environment for container is a driver of kernel) which can manage the container. Docker is just a manager program, his power is coming from runc. For every operating system we have 1-kernel and for every kernel we have 1 runc. on top of runc we run container.
Container layer use docker services or daemon to contact the runc. If by any chance docker daemon is stoped then docker can’t connect to the runc and your docker command will not work until you start docker daemon ( i.e. systemctl start docker). We can say that docker is highly depend on docker services/daemon (here service is equal to daemon).
How docker work ?
Docker have their own private repository called docker hub, where they store all the images. If you want to use any services like MYSQL for database, python, httpd for web server, etc. you can use the image that have services. Image is nothing but a complete whole environment / OS with service.
Let’s take an example that you want to use httpd service for your web server so that client can access your web page. First step is to download the image that contain httpd service. Now you launch the container with this image and in container you write a code/ download a code from GitHub and save the code file (myweb.html) in httpd server folder i.e. /var/www/html. Now it is a good practice to create an image of this container using dockerfile or by commit command. After you create now you launch the container and start your httpd service. Now client can access your web page. For future use you can push your customize image on docker hub.
One of the interesting thing that docker launch the container within a second. It is so fast that you can launch and terminate the entire container/os within a second. Now you can image why industry is moving towards from virtualization technology to containerization technology.
- Podman:
In docker the container engine is a hurdle between docker and runc. Which increase the some msec run time process of docker. Docker is a single point of failure. If daemon stop docker can’t run any command.
Architecture of podman and docker is same but the only major difference is that podman don’t use any container engine between the base os and podman. Podman directly contact the runc. Podman doesn’t rely on daemon and here there is no service so now container security is better than docker. There is no way to shut down the podman, if podman service fail it won’t impact podman. Podman is specialized in contacting runc to launch the container. Docker manage 2 thing i.e. container and management of storage, networking, etc. Podman manage just just container.
Podman never goes down because there is no daemon they directly contact to runc, so podman is faster then docker in some msec. Docker and podman command is exactly same. Image of docker and podman are compatible (you can use docker image in podman and podman image in docker).
- CRI-O:
Architecture and concept wise CRI-O is same as podman but Linux, Windows & Mac all have different runc drive (run time environment for container). So we need a standard container tool which can support in all the environment/OS. So CRI-O is tool which can manage the container in all the environment of base OS. CRI-O follow open container initiative and can run in all the environement with there runc.
Example : We have a sim-card which support in all mobile devices whether it is of Android, IOS, Windows.
2. Management Tool :
In real world there might be a posibility if any environment / webserver fail what to do ? Yes you can launch the environment again by command # docker run -dit –name container_name image_name. So because it is manual it takes time to launch the environment and start the services for client, here it might be possibility that client face downtime on your webserver which is not good for any business.
So we want a tool that can monitor the container, as soon as any service/container goes down internally behind the scene it should launch the container. If lots clients visiting at your server so we want a tool that keep on monitor how many clients request coming on particular server. As soon as container bandwidth (RAM, CPU, HD, etc) is getting full it should automatically internally launch the container behind the scene, if request goes down it should automatically terminate the container/ environment this concept of auto scaling we call load balancer. The tool which satisfy all the requirement of managing a container is Kubernetes.
Kubernetes is a management (orchestration) tool of container. Kubernetes doesn’t launch the container, it ask/contact the docker/podman/cri-o behind the scene to launch the container if requirement comes. Kubernetes is meant for only one thing to manage the container.
We use kubernetes in CLI or in UI. For CLI we use kubectl software which contact the kubernetes API server for any services that user requested. Kubernetes main role is to manage the pod (inside the pod container reside). In one pod you can launch as many as container. Node is where containerization tool and pod reside. You can say node is equal to complete environement/OS. Kubernetes need is to manage the container so for managing container K8s wrap all the containers in a box called POD. One of the issue of node/vm is limitation of RAM/CPU/HD because of this node may fail/crash anytime. So we have to use multiple node for getting rid of this problem. In future if complete entire node fails K8s go to another node and connect the client to that node.
In kubectl you can write a command either in terminal or you can use manifestfile (YAML and JSON). It is better to write command in manifest file because some of the command cli don’t support.
Whaterver we create in K8s is called resources (Pod,Expose, deployment,replica, template, etc) and the keyword we use to call resources is Kind. But all the resources can’t be created by Command line so we use Manifest file.
Controller are the brain of K8s. Some of are Replication Controller, Replication Set, Deployment. Controller main duty is to manage the Pods.
Replication Controller :- Replication controller have 3 duty i.e.
1) To monitor Pod, launch or terminate the Pod according to the requirements (Scale out and Scale in)
2) To create replica of Pod.
3) To set Desire for Pod. Replication controller use Equality based Filtering/Selector.(==, = , !=) Replication Controller don’t use Podname for monitoring because it change every time when it get terminated/fail by any reason. So RC use labels/Tag for monitoring the pods. In real world we don’t use Replication Controller because it is old/absoluted. We use newer Controller called Replication Set.
API version is use to communicate between to 2-program(in our case we are using kubectl and minicube). Replication controller use apiversion :V1.
Replica Set:- Replica Set duty is same as Replication Controller, the only main difference Replica Set uses Set/Rule based Selector/filter. Replica Set uses new Apiversion called Apiversion :apps/V1. Logic wise Replication controller and Replica Set are same. Managing wise they are different.
Deployment : Deployment use rolling strategy for website to get zero downtime for clients. If developer had done some changes in code of website then he upload new version code on SCM (source code management) tool GitHub. From GitHub integration tool like Jenkins/Openshift we can use to push that code in registry. Now kubernetes download the image from registry and ask the docker to launch the container in pod. Now deployment come in picture it automatically behind the scene terminate the container which is not in use by any client and launch the container with new image version. If client is using older container then deployment will wait till all client goes then behind the scene it terminate this older container and launch the new one. Deployment behind the scene using rolling strategy for downtime and also it use replica set for managing the pods.
PVC (Persistence Volume Claim) :
Kubernetes have very beautiful resource which can store the data permanently. Kubernetes use PVC (persistence volume claim) for storing data permanently, where In docker,podman, cri-o by default storage is empheral in nature (means as soon as container fail all data you lose) . For using pvc we have to mount the pvc with pod. Now if any container/pod fails when they launch new container, they can retrieve all the older data from pvc folder.
Secure :
Secure is a resource in kubernetes which we use to guard our data. If company have some confidential data it can use the environmental variable where they can mention the username and password. Now without username and password no can access the companies confidential data.
Route / Proxy Server :
If sudden peak came on application we need to manage the thing in such a way that client won’t face single second of downtime, So for this we can use the route resource of kubernetes which can launch the pods horizontally as per the requirement, this we call horizontal pod auto scalar which come under round robin.
Here we can give the threshold per cpu usage. Example: If 1 POD CPU usage fill upto 80% dynamically internally kubernetes will create another POD behind the route. If threshold come down from 80% it will terminate that POD. This we do the load balancing.
3. Monitoring Tool:
We need a tool which can give information why container/OS failed?
Reason can be:
- Shortage of RAM, CPU, Hard disk, etc.
- Some line of code is taking more time to run.
- Website take time to load a webpage.
- Bug in a code.
- Huge memory consume by statement/program.
K8s not check why container fail. K8s just launch the POD if it fails, K8s don’t know the reason of failure. So the tool which we use to gather the information (metrics) of container is Prometheus. In monitoring world metrics is a way to collect the information of the resources/component in real time. Without the monitoring no one knows what is happening, if you don’t know what is happening you can’t make any decision.
Prometheus is a tool which collect the metrics. Prometheus is just a metrics collection tool. We can do monitoring in Prometheus but it is not that interactive. So for monitoring we can use Grafana, Kibana, they collect the metrics from Prometheus in real time and give a beautiful interactive graphs and plots.
Prometheus is very good in storing a data in real time. Prometheus contact the exporter program to pull the data of container resources and store in Prometheus database. In the database Prometheus stores 3 things Time, metrics (key and value) and label. For every target metrics Prometheus give different label. (target can be node, container, MySQL, etc). This type of data storage is known as time series database (TSDB).
Prometheus duty is to download/push data. Prometheus don’t know what is node, docker, MYSQL, etc. Exporter help to Prometheus to fetch/pull data in different platform. Without the exporter Prometheus can’t fetch/pull the data from anywhere.
Openshift :
Hope you get detail knowledge of every tool that work behind the Openshift. Let’s come to the main topic which we have started. Openshift is a tool which work on top of kuberntes. Kubernetes work on top of node and pod. CRI-O work on top of runc to launch the container. Openshift use CRI-O for container management. For monitoring, openshift use Prometheus to collect the metrics and show the visual in their own visual format.
It might come in mind that we already have Jenkins as open source tool why we would use Openshift which is licence tool. Let’s understand what is the purpose of making openshift ?
Openshift have the capability to go the Github download the developer code. After download they have the capability to compile the code. After compiling they have capability to go to testing environment to test the code. After testing they finally deploy on the webserver. Openshift have the compability to keep on monitoring (RAM, CPU, HD, etc.) of the container. What the report/metrics they send to the developer.
Even Jenkins can do the same thing. But Jenkins have to use plugins in it. Without plugins Jenkins won’t work. For Jenkins to work first we install all the tool in machine which require for monitoring, managing pod, launch container then Jenkins contact the machine/OS to do CI/CD. So operational guy have to do all thing manually which is time consuming where in Openshift everything come in one package.
One more challenge in Jenkins that if developer wrote a code in php version 4 then operation guy check manually that this version is require to run the code. So according to that he write command in Jenkins to pull the Image from dockerhub registry (you can take any registry). This make operational guy work manual and slow. Where in Openshift as soon as developer code come on GitHub it download and automatically download a compatible image which require to run code. Openshift work only on container platform where Jenkins work in all platform, but for CI/CD Openshift is a best. Now everyone want 5G technology to run in a container, they choose Openshift for this technology.
Openshift is a unified solution for container management, monitoring, metrics collection, security. Openshift is a complete container platform with CI/CD support. Actual name of Openshift is Redhat Openshift Container Platform (RHOCP). Openshift have their own registry like docker have, here we call it catalog. If your requirement is to create your own customize image you can do in Openshift. Builder image mean’s in catalog they have provided an image to use.
Challenge in way-1 is they have to download the code from GitHub & if any container fail Openshift will launch the caontainer behind the scene but again they have to download the complete code from GitHub this takes lot of time. If client is connected with webserver and container fail then there would be some time of down time client may face. So real challenge is how quick we launch container with all the services for client.
In way-2 we they download the code from GitHub, launch the container and copy the code in it then create image of that container. Then they launch a container of new image with code and finally give IP of that container to client, now client won’t face any down time. The complete process in way 2 till creating new image with code is known as build / S2I (Source to image). From new image to launch container is called deployment.
Build — Behind the scene openshift create a file where they store everything. This file is a build configuration file (bc file).
Deployment — Behind the scene Openshift create a file they store POD Detail, resource details, which container is running, which image they are using, etc. This file is as deployment configuration file (dc file).
Practical :
I have done the practical in openshift tool, where I created application using nodejs language and store data in Database (PostgresSQL) using secure.
Thank-you for reading.
If this article is helpful, it would be appreciable if you could give 1 clap for it.
