UNIT-V

CONFIGURATION MANAGEMENT-ANSIBLE:

Introduction to ansible:
Ansible is an open-source IT automation engine that automates provisioning, configuration
management, application deployment, orchestration, and many other IT processes. Unlike other
management tools, Ansible is agentless meaning it installs no software or agents on the remote
systems it manages.
It uses YAML (Yet Another Markup Language), a simple English-like language, to describe
automation jobs in files called Playbooks.

Key Concepts & Features:

 Agentless: Doesn't require installing software on the target machines, connecting via existing
SSH or WinRM.

 Playbooks: Written in YAML (a human-readable format) to define automation tasks and desired
system states.
 Modules: Small programs Ansible pushes to nodes to perform tasks (e.g., installing packages,
starting services).

 Idempotency: Ensures tasks run only if needed, preventing unintended side effects (e.g., won't
restart a service already running).

 Declarative: You describe what you want the end state to be, and Ansible figures out how to get
there.

 Control Node: A single server where Ansible runs and manages other systems (managed
nodes).

Common Uses:

 Provisioning: Setting up new servers and infrastructure.

 Configuration Management: Keeping systems configured consistently.

 Application Deployment: Deploying software across many servers simultaneously.

 Orchestration: Coordinating complex, multi-tier application workflows.

Ansible Architecture:

The Ansible architecture is straightforward. It consists of a Control Node (where Ansible is

installed) and Managed Nodes (the servers you are automating).
1. Control Node:

The machine where Ansible is installed and from which you run the playbooks. It can be your
laptop or a central server. (Note: Windows is not currently supported as a Control Node).

2. Managed Nodes (Hosts)

These are the network devices (servers, switches, cloud instances) that you want to manage.
Ansible creates a connection to these nodes via SSH or WinRM to execute tasks.

3. Inventory

The Inventory is a file (usually located at /etc/ansible/hosts) that lists all the Managed Nodes.
 Static Inventory: A simple text file listing IP addresses or hostnames.
 Dynamic Inventory: Scripts that dynamically query cloud providers (AWS, Azure, GCP) to
fetch the list of currently running instances.

4. Modules

Modules are the "tools" in the Ansible toolkit. They are small programs that Ansible pushes to
the managed nodes to perform specific tasks (e.g., yum, apt, service, copy, user).
 Core Modules: Maintained by the Ansible team.
 Custom Modules: Written by users for specific tasks.

5. Playbooks

Playbooks are the blueprint of automation. Written in YAML, they define a list of tasks to be
executed across a set of hosts.

6. Plugins

Plugins extend Ansible’s core functionality. Common examples include:

 Connection Plugins: Handle communication (SSH, WinRM, Docker).

 Callback Plugins: Handle logging and display of output.

How Ansible Works:

Ansible works by connecting to your nodes and pushing out small programs, called
"Ansible Modules," to them.
The Workflow:
1. Create Inventory: Define the IP addresses of the hosts you want to manage.
2. Write Playbook: Define the desired state of those hosts in a YAML file.
3. Execute: Run the playbook using the ansible-playbook command.
4. Connect & Push: Ansible connects to the target nodes (via SSH/WinRM).
5. Fact Gathering: Ansible gathers system details (IP, OS version, CPU) from the target;
these are called "Facts."
6. Execute Modules: Ansible executes the modules defined in the playbook on the remote
node.
7. Clean Up: Ansible removes the modules after execution and reports the status (Changed,
Failed, or OK).

Use Cases of Ansible:

Ansible is a powerful automation tool widely adopted across various industries to
streamline IT operations, enhance efficiency, and reduce human error.
Here are some real-world use cases explaining how organizations uses Ansible:

1. Cloud Infrastructure Provisioning

Organizations utilize Ansible to automate the provisioning of cloud resources across platforms
like AWS, Azure, and Google Cloud. For instance, a company can use Ansible playbooks to
launch EC2 instances, configure networking, and deploy applications consistently across
multiple environments.

2. Network Device Automation

Network engineers employ Ansible to automate the configuration of network devices such
as routers, switches, and firewalls. This includes tasks like setting up VLANs, applying security
policies, and ensuring compliance with network standards, leading to consistent and error-free
network configurations.
3. Security and Compliance Enforcement
Ansible assists in automating security configurations and compliance checks across IT
infrastructures. Organizations use Ansible playbooks to enforce security policies, manage user
permissions, and apply patches, ensuring systems are secure and compliant with industry
standards.

4. Disaster Recovery Automation

In disaster recovery scenarios, Ansible automates the restoration of services by executing
predefined playbooks that restore configurations, reinstall software, and reapply settings,
minimizing downtime and ensuring business continuity.
5. Application Deployment and CI/CD Integration
Development teams integrate Ansible into their CI/CD pipelines to automate the deployment of
applications. Ansible playbooks can automate tasks like pulling the latest code, running tests, and
deploying applications to various environments, facilitating continuous integration and delivery.

Ansible Playbook With Example

These are the ordered list of tasks that are saved so you can run those tasks in that order
repeatedly. Playbooks are written in YAML and are easy to read, write, share and understand.
Ansible playbooks can perform wide variety of tasks as mentioned below
1. Deploying and configuring applications
2. Managing system configurations
3. Orchestrating complex workflows
Example
The language used to write Ansible playbooks is YAML, which is human-readable. The
following sections will cover the structure and examples of Ansible playbooks.
---
- name: Setup Apache Web Server
hosts: webservers # Target group defined in Inventory
become: true # Execute commands with sudo/root privileges

tasks:
- name: Install apache2 package
apt:
name: apache2
state: present
update_cache: yes

- name: Start and enable Apache service

service:
name: apache2
state: started
enabled: yes

- name: Create a custom [Link]

copy:
dest: /var/www/html/[Link]
content: "<h1>Welcome to Ansible Automation!</h1>"

Ansible tasks and roles:

In Ansible, tasks are the individual actions to be executed, while roles are a structural way to group
tasks and related content (variables, files, templates, and handlers) into reusable and organized
components.
 Ansible Tasks
A task is the basic unit of execution in Ansible, essentially a call to an Ansible module with specific
arguments.

 Definition: Tasks are defined in playbooks (or within a role's tasks/[Link] file) using YAML
syntax.

 Execution: Tasks run in the order they are listed within a play, on the target hosts specified in the
inventory.

 Purpose: They perform concrete operations, such as installing a package, copying a file, starting a
service, or running a command.

 Idempotency: Best practice is to ensure tasks are idempotent, meaning they can be run multiple
times without causing unintended side effects (e.g., a package installation task will only install if the
package isn't already present).

Ansible Roles
Roles provide a framework for breaking large, complex playbooks into smaller, manageable, and
shareable parts. They enforce a standard directory structure that makes the project easier to
understand and maintain.
 Modularity: Roles allow developers to focus on a single piece of functionality (e.g.,
a webserver role, a database role).

 Reusability: A role can be written once and used across many different projects and playbooks,
often shared via Ansible Galaxy.

 Structure: Ansible looks for specific files within a predefined directory structure when a role is used.
This structure automatically loads the associated variables, tasks, handlers, and files.

Standard Role Directory Structure

When you create a role (often using ansible-galaxy init), it generates a specific directory
structure:

 tasks/: Contains the main list of tasks (in [Link]) to be executed by the role.

 handlers/: Contains handlers (in [Link]), which are special tasks triggered only when a change
is made by another task (e.g., restarting a service after a configuration file update).

 defaults/: Stores low-priority variables (in [Link]) that can be easily overridden by other variable
definitions in the playbook.

 vars/: Stores high-priority variables (in [Link]) meant for internal use by the role's logic.

 files/: Contains static files that are copied to managed hosts without modification.

 templates/: Contains Jinja2 templates that are dynamically rendered with variables before being
copied to managed hosts.

 meta/: Contains metadata about the role, including author information and role dependencies.

Summary of Differences

Feature Task Role

Scope A single action within a playbook A container for organizing multiple tasks and
or role. related content.

Structure Defined inline within a YAML Uses a standard, predefined directory structure to
playbook file or task file. separate concerns.

Reusability Less reusable on its own; specific Highly reusable across different playbooks and
to a workflow. projects.

Complexity Simple, focused on one action. Manages complexity by breaking down a large
configuration into logical parts.
 Jinja templating:
Jinja is a fast, expressive, and extensible templating engine for the Python programming
language. It allows developers to generate dynamic content, such as HTML pages, configuration
files, or emails, by embedding Python-like logic and placeholders within a static text file (the
template).

Key Concepts
 Template: A text file that contains the structure of the final document, with special placeholders for
dynamic content.

 Rendering: The process of combining a template with actual data (a "context" dictionary) to produce
the final output document.

 Separation of Concerns: Jinja helps separate the application's logic (backend Python code) from
its presentation (the template structure), making code more maintainable.

 Template Inheritance: A powerful feature that allows you to build a base "skeleton" template that
child templates can extend and override specific blocks of content, reducing code duplication.

Core Syntax
Jinja uses specific delimiters to embed logic and expressions within a template:

 {{ ... }}: Used for expressions to print variables or the results of expressions to the final output.

o Example: Hello, {{ name }}!

 {% ... %}: Used for statements and control flow logic, such as if conditions, for loops, and
variable assignments using set.

o Example (Condition): {% if user %} ... {% endif %}

o Example (Loop): {% for item in list %} ... {% endfor %}

 {# ... #}: Used for comments that are not included in the final rendered output.

Features
 Filters: Modify variables and data before they are displayed, similar to Python's string methods.
They are applied using a pipe (|) symbol.

o Example: {{ variable|upper }} would convert the variable's value to uppercase.

 Macros: Reusable pieces of code, similar to functions in Python, to add functionality to templates.

 Automatic HTML Escaping: Helps prevent cross-site scripting (XSS) attacks by automatically
escaping untrusted input in HTML templates.

Common Use Cases

Jinja is widely used in the Python ecosystem and beyond:

 Web Frameworks: The default template engine for Flask and is supported by Django.

 Configuration Management: Used by tools like Ansible and Salt to manage and deploy
configuration files dynamically.

 Data Generation: Can be used to generate various text formats, including SQL macros for dbt,
emails, and reports.

For more in-depth learning, you can refer to the official Jinja Documentation or various online
tutorials from sources like Real Python.

What is Jinja?
Jinja is a text rendering engine for Python programming language. It has first-class
support among popular Python frameworks like Django and Flask and is used extensively.
It is popular for its easy and straightforward syntax and variety of features including (but
not limited to) -
 Variable access.
 Control structures (Conditionals, loops).
 Macros (similar to functions in programming languages).
 Filters
 Inheritance, etc.
Its syntax is heavily influenced by Django and Python which is good for anyone already
familiar with Python.
Basic technical overview of Jinja
One can render any text or text file using Jinja like HTML, XML, LaTeX, plain text, etc. as
long as it is pure text. We need a template and data. We provide these to the Jinja
rendering engine as input which combines them and outputs the text or text file as shown
in the figure below

A template is simply a text file defining the structure of a document (that will be
rendered/output) with Jinja syntax at places where we want to work with data. The
rendering engine takes the data and inserts it into the template as defined in it to produce
the output text. The templates need not have any specific extension or any extension at
all. But it is recommended to use ".jinja" extension as this would be helpful to recognize
the files and if you are using IDEs (Integrated development Environments) this may help
them recognize that it is a Jinja file. In special cases, like working with web Frameworks
like Flask or Django, we can use ".html" extension which provides additional benefits in
that environment like html escaping.
Installating Jinja
We will work with Python3 to render Jinja templates. So, one needs to have Python3 and
Jinja2 installed in order to work out the examples in this article. Once Python3 is installed,
any python package manager can be used to install Jinja2. Here is the command to install
using pip package manager -
On Windows -
py -m pip install jinja2
On Linux -
python3 -m pip install jinja2
Setting up the Project
In order to work with jinja any further, we need a small folder setup like this -
jinjaTests/
|_ templates/
|_ renders/
All our python files to render the templates will be put directly under the jinjaTests folder
and the jinja templates would be put under templates folder. We will run the python
programs from the jinjaTests folder as the current working directory/folder and any files
rendered will be saved in renders folder.
Though we can use any extension name or no extension at all for the jinja templates, it is
recommended to use the ".jinja" extension and we will follow this convention throughout
this article.
Rendering text from Jinja Template using Python
Rendering a jinja template always results in some text (obviously, since this is what jinja is
all about as stated earlier). Rendering a template using a python file involves the following
steps -
 Step 1: Import the necessary libraries and components (objects, functions, etc.) from
libraries.
 Step 2: Create a jinja rendering environment and store it in a variable. This
environment will be used in further steps.
 Step 3: Load the template in a variable.
 Step 4: Render the template using <template-object>.render() function to obtain text.
 Step 5: Print the rendered text to the screen or a file as suitable.
Following is an example to demonstrate the above process.
Printing "Hello World" with Jinja
Create a jinja template named "[Link]" and save it in templates folder. Here
are the contents of this file -
Hello World!
Create a python file named "[Link]" and save it directly under
the jinjaTests folder. This file will render the "[Link]" template. Here are the
contents of this file.
After importing the necessary components from "jinja2" module we load the environment
using the "Environment()" function citing the templates folder as the folder for keeping
templates. While loading jinja templates, the environment will search for the templates
relative to this folder. Next, we load the template using "<environment-
object>.get_template(<path to the template>)" function where the path to the template is
relative to the templates folder as stated and store it in variable named "template". Next
we render the template using "<template-object>.render()" function which outputs the
rendered text (string). We store the output string in the variable output. Finally, we print
the string stored in output on the screen.
from jinja2 import Environment, FileSystemLoader
env = Environment(loader = FileSystemLoader('templates'))
template = env.get_template('[Link]')
output = [Link]()
print(output)
Output
Hello World!
Saving the output of rendering a Jinja template to a file
To save the output to a file, we just need to write the output string to a file instead of the
screen in last example. One way to do this is by replacing the print line (last line) with the
following code in [Link] -
with open("renders/[Link]", 'w') as f:
print(output, file = f)
Running the "[Link]" with this code will create a file
named "[Link]" in the renders folder (or any other location you specify).
Passing data to the Jinja template
We can pass data to the jinja template from the rendering python program by passing
keyword argument(s) to the "<template-object>.render()" function. The keys of these
arguments can be used to access the respective values in the expression delimiters (i.e.,
{{ }}) inside the template. Here is an example to print hello to a name passed to the
template by the rendering python program -
Example
Save a template named "[Link]" in the templates folder with the following
content -
Hello {{name}}!
Next save the rendering python program named "[Link]" in the jinjaTests folder
with the following content -
from jinja2 import Environment, FileSystemLoader

# loading the environment

env = Environment(loader = FileSystemLoader('templates'))

# loading the template

template = env.get_template('[Link]')

# rendering the template and storing the resultant text in variable output
output = [Link](name = 'Geeks')

# printing the output on screen

print(output)
Running this file produces the following text output on the screen -
Hello Geeks!
Note that we passed the "name" argument to the render function which is accessed in the
template inside the expression delimiters. More on delimiters in syntax section.

vaults in ansible:
 Ansible Vault is a feature in Ansible that encrypts sensitive data, like passwords and API keys, within
files (e.g., YAML, entire playbooks) using AES256 encryption, preventing plain-text exposure in code
repositories, and can be managed with the ansible-vault command
for encrypt, decrypt, edit, and view operations, requiring a password for access during
runtime. It secures secrets without hindering automation, allowing them to be transparently used in
playbooks once decrypted.

How it works
 Encryption:
Encrypts files or specific variables using a password, turning readable text into unreadable
ciphertext.
 Decryption:
Decrypts data at runtime when the correct password is provided, either interactively or via a
password file.
 Granularity:
Encrypts entire files (like vars/[Link]) or individual variables within them.

 Key:
Uses a single password (symmetric) for both encryption and decryption, making it simple to
manage.
Common ansible-vault commands
 ansible-vault create [Link]: Creates a new encrypted file.

 ansible-vault encrypt [Link]: Encrypts an existing file.

 ansible-vault decrypt [Link]: Decrypts a file (outputs to stdout or specified file).

 ansible-vault edit [Link]: Opens the encrypted file in a default editor for secure editing.

 ansible-vault view [Link]: Displays the decrypted content in a pager without saving.

 ansible-vault rekey [Link]: Changes the password for an encrypted file.

Key benefits
 Security:
Protects secrets (passwords, tokens) in version control systems (like Git).
 Usability:
Integrates seamlessly with ansible and ansible-playbook commands, prompting for passwords
or using specified password files.
 Simplicity:
Uses AES256, a strong encryption standard, with a straightforward password mechanism.
 Deployments using ansible:

Ansible is a powerful, agentless IT automation engine that automates application deployment,

configuration management, and cloud provisioning using human-readable YAML playbooks. It works
by connecting to managed nodes via SSH (for Linux) or WinRM (for Windows) to push out small
modules that enforce the desired state.

Core Concepts for Deployments

 Control Node: The machine where Ansible is installed and from which you run playbooks and
commands.

 Managed Nodes: The remote servers or devices that Ansible manages and configures.

 Inventory: A file (INI or YAML format) that lists the managed nodes and organizes them into groups
for targeted automation.

 Playbooks: YAML files that define the automation workflows, written in a simple language that
describes the desired state of the systems. Playbooks orchestrate multi-step processes across
multiple machines in a defined order.

 Modules: Reusable scripts that Ansible executes on the managed nodes to perform specific tasks,
such as installing packages, managing files, or restarting services.

 Roles: A way to organize playbooks and related files (variables, templates, handlers) into a
predefined directory structure, making the automation content reusable and shareable.

 Ansible Vault: Used to encrypt sensitive data like passwords, API keys, or private keys within your
playbooks and variable files, ensuring security.

Steps for a Typical Deployment

1. Set up the Control Node: Install Ansible on your local machine or a dedicated server.

2. Define Inventory: Create an inventory file (e.g., [Link]) listing your target servers and
grouping them.

ini
[webservers]
[Link]
[Link]

[database]
[Link]

3. Configure Connectivity: Ensure SSH connectivity from the control node to all managed nodes,
ideally using SSH keys to avoid password prompts.
4. Create a Playbook: Write a YAML playbook (e.g., [Link]) to define the deployment tasks.

yaml
---
- name: Deploy application
hosts: webservers
become: yes # Run tasks with elevated privileges
tasks:
- name: Update apt cache (example for Debian/Ubuntu)
apt:
update_cache: yes

- name: Install Nginx

apt:
name: nginx
state: present

- name: Copy application files

copy:
src: ./myapp_source/
dest: /var/www/html/myapp/
owner: www-data
group: www-data

- name: Ensure Nginx is running and enabled at boot

service:
name: nginx
state: started
enabled: yes

5. Run the Playbook: Execute the playbook from the control node using the ansible-
playbook command, specifying your inventory file.

bash
ansible-playbook -i [Link] [Link]

Advanced Deployment Scenarios

 Continuous Deployment (CD): Ansible integrates seamlessly with CI/CD tools like Jenkins, GitLab
CI, and GitHub Actions to automate the entire application lifecycle, from code checkout and building
to testing and production deployment.

 Multi-tier Deployments: Playbooks can coordinate actions across different server tiers (web
servers, database servers, load balancers) in a specific order.
 Rolling Upgrades: Ansible can perform zero-downtime rolling updates by updating a specified
number of servers at a time, taking them out of a load balancer pool temporarily and then adding
them back in.

 Cloud Provisioning: Ansible includes modules for major cloud providers (AWS, Azure, Google
Cloud) to provision infrastructure resources like virtual machines and network configurations before
deploying applications onto them.

CONTAINERIZATION USING KUBERNETES(OPENSHIFT):

INTRODUCTION TO KUBERNATES NAMESPACE & RESOURCES:

Kubernetes Namespaces provide a mechanism for isolating and organizing groups of resources
within a single cluster, while Ansible automates their management through declarative playbooks
using the [Link].k8s module.

Understanding Kubernetes Namespaces & Resources

 Namespaces: Function as "virtual clusters" inside a physical cluster, allowing multiple teams or
projects to share the same infrastructure without resource conflicts. They provide logical separation,
improved organization, enhanced access control (via RBAC), and facilitate resource management
through quotas and limits.

o Default Namespaces: A new Kubernetes cluster comes with three default

namespaces: default, kube-system (for system components), and kube-public (for publicly
readable resources).

 Resources (Objects): These are persistent entities in the Kubernetes system that represent the
desired state of your cluster. Common namespaced resources include Pods, Deployments,
Services, ConfigMaps, and Secrets. Cluster-wide resources like Nodes and Persistent Volumes exist
outside of any specific namespace.

Managing Kubernetes with Ansible

Ansible manages Kubernetes resources using the officially supported [Link].k8s module,
which interacts with the Kubernetes API server.

Prerequisites

To use Ansible for Kubernetes management, you need to install the necessary Python libraries and
the collection on your control machine:

 Ansible (version 2.15+ recommended)

 Python Kubernetes client package: pip install kubernetes

 Kubernetes collection: ansible-galaxy collection install [Link]

 Key Ansible Concepts for Kubernetes

 Idempotency: Ansible playbooks are idempotent, meaning they can be run multiple times without
causing unintended changes. If a resource already exists in the desired state, Ansible will not
attempt to recreate it.

 YAML Definitions: You define the desired state of your Kubernetes resources using standard
YAML manifest files, which can be referenced directly within your Ansible playbooks or provided
inline.

 State Management: The state parameter in the k8s module is used to specify the desired outcome:

o present: Ensures the resource exists (creation or update).

o absent: Ensures the resource does not exist (deletion).

Example: Creating a Namespace with Ansible

The following playbook demonstrates how to create a new namespace named dev-team using
the [Link].k8s module:

yaml
---
- name: Manage Kubernetes Namespaces and Resources
hosts: localhost
connection: local
tasks:
- name: Ensure the 'dev-team' namespace is present
[Link].k8s:
api_version: v1
kind: Namespace
name: dev-team
state: present

Example: Deploying a Resource to a Specific Namespace

To deploy a resource (e.g., a ConfigMap) to a specific namespace, you can specify

the namespace parameter in the task, or define it in the YAML manifest. This example uses an inline
YAML definition:

yaml
- name: Create a ConfigMap in the 'dev-team' namespace
[Link].k8s:
state: present
definition:
apiVersion: v1
kind: ConfigMap
metadata:
 name: app-config
namespace: dev-team # Explicitly specify the namespace
data:
key1: value1
key2: value2

Ansible simplifies Kubernetes management by leveraging its automation principles to declaratively

define and manage namespaces and resources across your cluster infrastructure. You can find
more detailed examples and documentation on the Ansible documentation site.

CI/CD- on ocp,bc,dc & configmaps:

In Red Hat OpenShift Container Platform (OCP) for 2026, CI/CD workflows leverage specific native
objects to automate the transition from source code to running applications.

Core CI/CD Components in OCP

 OCP (OpenShift Container Platform): The foundational enterprise Kubernetes platform that
integrates CI/CD tools like OpenShift Pipelines (based on Tekton) and OpenShift GitOps (based
on Argo CD).

 BC (BuildConfig): Represents the CI (Continuous Integration) phase. It defines the build strategy
(Source-to-Image, Docker, or Pipeline) and triggers (like a Git webhook) to create a new container
image from source code.

 DC (DeploymentConfig): Represents the CD (Continuous Deployment) phase. It defines the

deployment strategy, number of replicas, and triggers (such as an image change) to automatically
update the running application when a new image version is built.

 ConfigMaps: Used to separate configuration from code. In a CI/CD pipeline, ConfigMaps allow
you to inject environment-specific settings (like database URLs or feature flags) into your pods
without rebuilding the container image.

Automated CI/CD Workflow

1. Trigger: A developer pushes code to a Git repository, triggering the BuildConfig (BC) via a
webhook.

2. Build (CI): The BC pulls the source code and builds a new container image, pushing it to the internal
OpenShift Image Registry.

3. Deploy (CD): The DeploymentConfig (DC) detects the new image version in the registry and
automatically triggers a rolling update.

4. Inject Config: During the rollout, the DC mounts ConfigMaps into the new pods as environment
variables or volume files to ensure the application starts with the correct configuration.
 In a Continuous Integration/Continuous Deployment (CI/CD) context, BuildConfig
(BC), DeploymentConfig (DC), and ConfigMaps are key components within the OpenShift
Container Platform (OCP) ecosystem, used to automate the building, deployment, and
configuration of applications.

BuildConfig (BC)
A BuildConfig is an OpenShift API object that defines the process for turning source code (from a
Git repository, for example) into a runnable container image.

 Role in CI/CD: The CI pipeline uses the BuildConfig to automate the integration phase. When
source code is updated (e.g., a commit to Git), a trigger can start a new build process.

 Key Functionality: It uses various strategies (like Docker builds or Source-to-Image (S2I)) to fetch
the source, compile it, run tests, and push the resulting container image to an internal registry.

DeploymentConfig (DC)
A DeploymentConfig is an OpenShift object used to manage the lifecycle of an application's
deployment, including how new versions are rolled out, scaled, and managed. While standard
Kubernetes uses Deployments and ReplicaSets, OpenShift has traditionally offered enhanced
features through DeploymentConfigs for managing complex deployment strategies like "blue-green"
or "canary" deployments.

 Role in CI/CD: The CD pipeline uses the DeploymentConfig. Once a new, tested container image is
available from the build process, the DeploymentConfig is updated to use the new image tag. This
automatically triggers a new rollout of the application, ensuring the latest version is deployed to the
target environment.

 Key Functionality: It defines the desired state of the application (e.g., how many pods should be
running) and manages the transition between application versions with controlled rollout strategies.

ConfigMaps
A ConfigMap is a Kubernetes API object used to store non-confidential data in key-value pairs. This
allows you to decouple environment-specific configuration data (like application settings, feature
flags, or environment variables) from the container image itself.

 Role in CI/CD: In a CI/CD pipeline, ConfigMaps are created and managed separately from the
application image. The application's DeploymentConfig can then reference these ConfigMaps,
injecting the configuration data into the running pods as environment variables or mounted
configuration files in a volume.
 Key Functionality: This separation enables the same container image to be deployed across
different environments (dev, test, prod) with different configurations, without needing to rebuild the
image for each environment, thus increasing portability and flexibility.

Summary of Interaction
In a typical OpenShift CI/CD workflow:

1. CI: The BuildConfig automates the build of a new container image from source code.

2. CD: The DeploymentConfig orchestrates the deployment of that new image.

3. Configuration: Both the build (e.g., build arguments) and deployment (e.g., runtime environment
variables) processes can leverage ConfigMaps to manage configuration data dynamically and
securely (for non-sensitive data).

Deploying apps on openshift container pods:

Deploying applications to OpenShift container pods can be done using the OpenShift CLI (oc) or
the web console, typically via Deployment or DeploymentConfig objects which manage the
underlying pods. OpenShift, being an enterprise-grade Kubernetes platform, offers several methods
for deployment.

Methods for Deployment

You can deploy applications using the following primary methods:

 From a pre-existing container image: This is the simplest method if you already have an image in
a registry (like Docker Hub or OpenShift's internal registry).

 From source code using Source-to-Image (S2I) or a Dockerfile: OpenShift can automatically
build a container image from your source code in a Git repository.

 Using YAML manifest files: You can define Kubernetes Deployment, Service, and Route resources
declaratively in YAML files and apply them.

 Using Helm charts or Operators: For more complex applications, Helm charts or the Operator
Lifecycle Manager can automate the deployment and management process.

Step-by-Step Guide (CLI Method)

The following steps use the OpenShift CLI (oc) to deploy an application using an existing image, a
common and straightforward method.

Prerequisites

 Access to an OpenShift cluster.

 The oc command-line tool installed and configured with login credentials.

Deployment Steps

1. Log in to your OpenShift cluster:

bash
oc login --server=<your-openshift-server-url> --token=<your-token>
# or with username/password
oc login -u=<username> -p=<password> --server=<your-openshift-server-url>

2. Create a new project (namespace): Projects in OpenShift provide a mechanism to organize and
manage content in isolation.

bash
oc new-project my-app-project --display-name="My Application Project"

(The CLI output will confirm you are now using the new project).
3. Deploy your application from a container image: Use the oc new-app command, which
automatically creates the necessary Deployment (or DeploymentConfig) and Service objects. This
example uses a sample Nginx image.

bash
oc new-app nginx:1.17.0 --name=nginx-app

OpenShift pulls the image from the specified registry (e.g., Docker Hub by default), creates a
deployment to manage the pods, and a service to expose the pods internally.
4. Verify the deployment and check pod status:

bash
oc get pods
oc status

You should see your application's pod in a Running state.

5. Expose the application externally using a Route: By default, the application is only accessible
within the cluster network. A Route is needed to expose it to external traffic.

bash
oc expose service/nginx-app

6. Retrieve the application URL:

bash
oc get route nginx-app
 The output will provide a HOST/PORT that you can access in your web browser to view the running
application.

Introduction to puppet master and chef:

In the context of IT and DevOps, Puppet Master and Chef are key components of industry-leading
configuration management tools used to automate the deployment and management of server
infrastructure.

Puppet and Puppet Master

Puppet is a model-driven, declarative configuration management tool designed to ensure systems

remain in a "desired state".

 Puppet Master: This is the central server in Puppet's master-agent architecture. It stores all the
configuration definitions—known as manifests—and is responsible for compiling them
into catalogs for each managed node.

 Workflow:

1. Puppet Agents (installed on managed servers) send their current state data (facts) to the Puppet
Master.

2. The Puppet Master uses these facts to create a customized catalog (a JSON document) of how that
specific server should be configured.

3. The agent pulls this catalog and applies only the necessary changes to reach the desired state,
reporting back any successes or failures to the Master.

 Key Feature: It uses its own Puppet DSL (Domain Specific Language), which is designed to be
accessible for system administrators without extensive programming backgrounds.

Chef

Chef is a code-driven, procedural configuration management tool that treats infrastructure as code
(IaC), allowing for high flexibility and control.

 Components:

o Chef Server: The central hub where configurations (called cookbooks and recipes) are stored and
managed.

o Chef Workstation: A unique component where users author and test their code (recipes) before
uploading it to the Chef Server.

o Chef Client: Installed on managed nodes, it periodically polls the Chef Server to pull and execute
the latest configurations.
 Key Feature: It uses a Ruby-based DSL, making it highly popular among developers who are
already familiar with the Ruby programming language.

Comparison Table: 2026 Overview

Feature Puppet Chef

Primary Philosophy Declarative (Define "what" state) Procedural (Define "how" to get there)

Language Puppet DSL (proprietary) Ruby-based DSL

Configuration Files Manifests (grouped in Modules) Recipes (grouped in Cookbooks)

Architecture Master-Agent Client-Server + Workstation

Ease of Use Better for SysAdmins Better for Developers