In this article we will discuss about the terms called Projects and Deployments used in the OpenShift Container Orchestration Platform.

Projects

Projects helps you organize the resources in the cluster. They provide isolation from other projects, which means logically separated from others but with the ability to communicate with each other. The projects starting with openshift- and kube- are default projects. These default projects host cluster components that run as pods and other infrastructure components. Every resource in the cluster bound to the namespace, only nodes and the persistent storage volumes exsits outside of the projects.

Advantages of Projects

• Helps to manage the applications effectively
• Avoid conflicts in-case of multiple teams using the same cluster
• Sharing the services between the projects
• Providing access to the projects only to those who are contributing to the project
• Resources Limits at the projects level, so one application should not cosume the entire resource.

Limitations of Projects

• Cant access some of the resources from another projects

  eg: Configmaps, Secrets

Managing Projects

Creating Projects

We can create projects using two methods

Using CLI

oc new-project myproject --display-name 'My Project'

Using YAML file

apiVersion: project.openshift.io/v1
kind: Project
metadata:
  annotations:
      openshift.io/description: My Sample Project
      openshift.io/display-name: My Project
  labels:
    kubernetes.io/metadata.name: myproject
  name: myproject

oc create -f project.yaml

Switching the Project

oc project my-project

List the Projects

oc get projects

Deleting the Project

oc delete project my-project

Deployment

Deployment in OpenShift instruct how to create or update a pod which holds the containerized application. Deployment manages the replicas of pods with the help of replicaset, enable rollout in a controlled fashion or rollback to an earlier deployment if needed.

Benefits of using OpenShift Deployment

Deployment automates the repetative manual functions that are involved in deploying, scaling, and updating the containerized applications in production.

Deployment monitors the pods health and nodes, it can replace a failed pod to ensure the continuity of critical applications.

Deployment easing the launch of application pods and ensure they are running across all the nodes in the cluster. As the complete process is automated deployments will be faster with minimal errors.

Deployment Strategies

Deployment strategies are the ways to upgrade an application without downtime in a way the users barely notices the improvements.

There are various deployment strategy are available

• Rolling Strategy
• Canary Deployments
• Recreate Strategy
• Blue-Green Deployment
• A/B Deployment

Rolling Strategy

Rolling deployments are the default in the OpenShift. This strategy slowly replaces the older version of the application with the newer version. The rolling deployment waits for the new pod to become available via a readiness check before terminating the older pods. In case of an issue it will abort the rolling deployment

When to use rolling deployment.

• When you dont want any downtime during application upgrade
• When you want the older and newer version of the code running at the same time.
• This typically requires that your application handle N-1 compatibility.

Canary Deployment

All form of rolling deployment in OpenShift are canary deployment, a newer version of the code is deployed and tested before all of the older instances are terminated and replaced with newer version. The newer version of the application tested via a readiness check. if the readiness check never succeeds, the canary instance is removed and the deployment will be automatically rolled back.

When to use canary deployment.

• Good for testing new functionality on a small group of users.
• Easy roll back feature.
• Also to test how the new code will impact the overall operations of a system.

Recreate Strategy

Recreate strategy terminates the currently running pod instances and recreates with the newer version of the application. As a result, there is downtime involved with both shutdown of the old deployment and initialization of the instances of the new deployment.

When to use recreate.

• Where the user activity isn't an issue.
• Where minimal downtime is okay.
• When you do not support having new and old versions of your application code running at the same time.

Blue/Green Deployment

Blue-Green deployment running the two versions of an application at the same time and moving route from the in-production version to the newer version. Blue-Green uses two deployment configurations, with each deployment configurations exposes to a different services. Create a new route to test the newer version of the application. When the testing is completed change the service in the production route which points to the newer version of the application.

A/B Deployment

A/B deployment strategy lets you try a new version of the application in a limited way in the production environment. In this strategy production version get most of the user requests while part of the request goes to the newer version of the application. As testing progresses you can increase user requests to the newer version and ultimately stop using the previous version. As we increase the traffic to the newer version, the number of pods in each service needs to be scaled up.

Managing Deployments

Creating deployment using CLI

oc create deployment --image=nginx:1.17.0 --replicas=2 -n myproject

Creating deployment using YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  labels:
    app: cnl
  name: cnl
  namespace: myproject
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: cnl
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: cnl
    spec:
      containers:
      - image: nginx:1.17.0
        imagePullPolicy: IfNotPresent
        name: nginx
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

oc create -f deployment.yaml

List the deployments within namespace

oc get deployment -n myproject

Deployment data in YAML format

oc get deployment cnl -n myproject -o yaml

Deployment data in JSON format

oc get deployment cnl -n myproject -o json

Edit the deployment

oc edit deployment cnl -n myproject

Delete the deployment

oc delete deployment cnl -n myproject

Conclusion

Projects in OpenShift group the resources and provides isolation from other projects this enables multiple teams to share the same cluster and the resources. Deployments helps you to deploy application in the projects, though different deployment strategies are supported, the default deployment strategy is rolling deployment.

Community and Social Footprints :

• Manzoor Ahamed
• GitHub
• Twitter
• YouTube Cloud DevOps Free Trainings
• Linkedin Page
• Linkedin Group
• Discord Channel
• Dev