In this post, I have shared some quick tips, including Q/A and useful links from the Day 4 live session of our current batch of OpenShift Certified Specialist Training.
OpenShift is a unique platform for building and shipping cloud-based applications. It opens opportunities for innovative products and services with faster delivery. An organization using Red Hat OpenShift can unleash many advantages and gain competitive benefits in business.
This series will help you better understand and make it easier for you to learn Openshift, clear Certifications & get a better-paid job.
On our Day 1, 2 & Day3 of the OpenShift Certified Specialist training program, we have gone through Kubernetes Vs Openshift, Openshift Architecture, Types of OpenShift Cluster, OpenShift Cluster Creation, Application Deployment, and Openshift Networking. Now on Day 4 of our training program, we covered these topics:
- Resource Types
- Application Deployment
- Deployment & Deployment config (dc)
- DeploymentConfig strategies
- Build & Build config (bc)
- Build Strategies (S2I)
↦ Before we begin, know everything about the OpenShift Certification
➪ OpenShift Resource Types
Kubernetes has six main resource types that can be created and configured using a YAML or a JSON file, using OpenShift management tools:
Pods (po): Pods represent a collection of containers that share resources, such as IP addresses and persistent storage volumes. It is the basic unit of work for Kubernetes.
Services (svc): Define a single IP/port combination that provides access to a pool of pods. By default, services connect clients to pods in a round-robin fashion.
Replication Controllers (rc): A Kubernetes resource that defines how pods are replicated (horizontally scaled) into different nodes. Replication controllers are a basic Kubernetes service provide high availability for pods and containers.
Deployment config (dc): Represents the set of containers included in a pod, and the deployment strategies to be used. A dc also provides a basic but extensible continuous delivery workflow.
Routes: Represent a DNS host name recognized by the OpenShift router as an ingress point for applications and microservices.
To obtain a list of all the resources available in a RHOCP cluster and their abbreviations, use the oc api resources or kubectl api-resources commands.
Q1: What are the resource types added by OCP to Kubernetes?
Ans: The main resource types added by OpenShift Container Platform to Kubernetes are:
Deployment config (dc): Represents the set of containers included in a pod, and the deployment strategies to be used. A dc also provides a basic but extensible continuous delivery workflow.
Build config (bc): Defines a process to be executed in the OpenShift project. Used by the OpenShift Sourceto-Image (S21) feature to build a container image from application source code stored in a Git repository. A bc works together with a de to provide a basic but extensible continuous integration and continuous delivery workflows.
Routes: Represent a DNS host name recognized by the OpenShift router as an ingress point for applications and microservices.
To obtain a list of all the resources available in a RHOCP cluster and their abbreviations, use the oc api resources or kubectl api-resources commands.
➪ Application Deployment
OCP is an on-premises platform as a service built around containers orchestrated and managed by Kubernetes on a foundation of Red Hat Enterprise Linux.
Deploying applications in Openshift is quite an interesting thing. There are four different types of Application deployments in Openshift (OCP):
- Source To Image (S2I)
- Image Streams (Docker Image)
- Database Image
- Deploy Application With Dockerfile
↦ Learn more about How To Deploy Application On OpenShift (OCP)
Q2:What are deployment strategies in OpenShift?
Ans: Deployment strategies are tools for changing or improving an application. Modifications do not require any downtime when using deployment strategies. The blue-green deployment strategy is the most commonly used.
Users follow this strategy by continuing to use the stable version denoted by green while changes are made in the new version denoted by blue. Users can switch to the blue version after testing and evaluating the new version in blue. If a problem arises, users can stick with the green version.
Q3: Define the OpenShift CLI.
Ans: OpenShift CLI is a command-line tool for managing OpenShift applications. The OpenShift CLI provides capabilities for managing the entire application lifecycle. It includes features for basic and advanced application configuration. It also includes management, deployment, and application addition features.
Q4: What is the Source-to-Image (S2I) strategy?
Ans: This strategy entails downloading and compiling the same container to generate source code images. The images are created using the same code, and rpm and jar are developed using a custom strategy.
➪ Deployment & Deployment config (dc)
Deployments and DeploymentConfigs are API objects in OpenShift Container Platform that provide two similar but distinct methods for fine-grained management of common user applications. They are made up of the following individual API objects:
- A DeploymentConfig or a Deployment, both of which describe the desired state of a specific application component as a Pod template.
- DeploymentConfigs include one or more ReplicationControllers, which contain a point-in-time record of a DeploymentConfig’s state as a Pod template. Deployments, too, involve one or more ReplicaSets, which are the successors to ReplicationControllers.
- One or more Pods, which represent an instance of a particular version of an application.
When you create a deployment configuration, a replication controller is created representing the deployment configuration’s pod template. If the deployment configuration changes, a new replication controller is created with the latest pod template, and a deployment process runs to
scale down the old replication controller and scale up the new replication controller.
↦ Learn more about Deployment.
Q4. What are the Building blocks of a deployment?
Ans. Deployments, as well as Deployment Configs, are enabled by using native Kubernetes API objects ReplicationControllers and ReplicaSets as building blocks.
Users are not required to interact with ReplicationControllers, ReplicaSets, or Pods that are owned by DeploymentConfigs or Deployments. The deployment system ensures that changes are propagated correctly.
➪ DeploymentConfig strategies
A deployment strategy is a way to change or upgrade an application. The aim is to make the change without downtime in a way that the user barely notices the improvements.
Rolling strategy:
A rolling deployment slowly replaces instances of the previous version of an application with instances of the new version of the application. The Rolling strategy is the default deployment strategy used if no strategy is specified on a DeploymentConfig.
Recreate strategy:
The Recreate strategy has basic rollout behavior and supports lifecycle hooks for injecting code into the deployment process.
Q5. What are the DeploymentConfig capabilities?
Ans. The DeploymentConfig deployment system provides the following capabilities:
- A DeploymentConfig, which is a running application template.
- Triggers that cause automated deployments as a result of events.
- Transition strategies from the previous version to the new version that are user-customizable. A strategy executes within a Pod, which is commonly referred to as the deployment process.
- A collection of hooks (lifecycle hooks) for executing custom behaviour at various points in a deployment’s lifecycle.
- Versioning your application to allow for manual or automatic rollbacks in the event of a deployment failure.
- Autoscaling and manual replication scaling.
➪ Build & Build config (bc)
A build in OpenShift Container Platform is the process of transforming input parameters into a resulting object. Most often, builds are used to transform source code into a runnable container image.
A build configuration specifies a single build definition as well as a set of triggers that are activated when a new build is created. A BuildConfig, which is a REST object that can be used in a POST to the API server to create a new instance, defines build configurations.
↦ Know more about Build config
➪ Build Strategies (S2I)
A build configuration, also known as a BuildConfig, is defined by a build strategy and one or more sources. The process is determined by the strategy, while the sources provide input. A BuildConfig is typically generated automatically for you if you use the web console or CLI to create your application using OpenShift Container Platform, and it can be edited at any time. Understanding the components of a BuildConfig and their available options can be useful if you decide to change your configuration manually later.
➪ Source-to-Image (S2I) build
S2I is a tool for creating reproducible, Docker-formatted container images. It generates ready-to-run images by injecting application source into a container image and then assembling a new image. The new image includes the base image (the builder) as well as the built source and is ready to use with the buildah run command. S2I supports incremental builds, which reuse previously downloaded dependencies, artefacts, and so on.
Q6. What are the build strategies in Openshift?
Ans. The build strategies are:
- Source-to-Image (S2I)
- Pipeline
- Docker
- Custom
Q4. What are the Advantages of S2I build?
Ans. The advantages of S2I include the following:
Image flexibility: Using the existing ecosystem, S2I scripts can be written to inject application code into almost any existing Docker-formatted container image.
Speed: The assemble process can perform a large number of complex operations with S2I without creating a new layer at each step, resulting in a quick process.
Patchability: S2I allows you to consistently rebuild the application if an underlying image requires a patch due to a security issue.
Operational efficiency: The PaaS operator can avoid accidental or intentional abuses of the build system by restricting build operations rather than allowing arbitrary actions, as a Dockerfile would allow.
Operational security: S2I limits the operations that can be performed as a root user and can run scripts as a non-root user.
User efficiency: During the application build, S2I prevents developers from performing arbitrary yum install type operations, which could slow down development iteration.
Ecosystem: S2I encourages a shared ecosystem of images where you can leverage best practices for your applications.
Reproducibility: Produced images can include all inputs including specific versions of build tools and dependencies. This ensures that the image can be reproduced precisely.
Quiz Time!
With our OpenShift Certified Specialist training program, we cover real exam questions to help you prepare for the OpenShift certification.
Check out one of the simple questions and see if you can crack this…
Q.Which of the following runs on each node and ensures containers are running in a pod?
A. Pod
B. Etcd
C. Kubelet
D. Scheduler
The right answer will be revealed in my next blog. So, stay tuned!
Here is the answer to the question shared last week.
Q. Which of the following servers runs Kubernetes API components?
A. Worker nodes
B. Nodes
C. Control plane nodes
Correct Answer: C
Feedback
We always work on improving and being the best version of ourselves from the previous session hence constantly ask feedback from our attendees.
Here’s the feedback that we received from our trainees who had attended the session… {2109 here represents a batch of September 2021}
Related/References
- Openshift vs Kubernetes: What is the Difference?
- Kubernetes for Beginners
- Red Hat OpenShift- What, Why, and How?
- OpenShift For Beginners: 30+ Hands-On labs You Must Perform | Step-by-Step
- Deploy Applications Using OpenShift: Step-by-Step
- Install Single Node OpenShift Cluster (OKD): Step By Step
- Install & Configure Multi-Node Openshift (OCP) Cluster Using User Provisioned Infrastructure: Step By Step
- [Q & A] Day 0: OpenShift [Docker Containers, K8s Architecture, & OpenShift Overview]
- [Recap] Day 1 & 2: K8s vs OpenShift, Openshift Architecture, Types of Cluster & Cluster creation in Openshift
- OpenShift Official Documentation
Next Task For You: Join Our FREE Class
Begin your journey towards becoming a Red Hat Certified Specialist in OpenShift Administrator and earning a lot more in 2021 by joining our Free Class.
Leave a Reply