UNIT-V

Configuration Management
• ANSIBLE: Introduction to Ansible
• Ansible tasks
• Roles
• Jinja2 templating
• Vaults
• Deployments using Ansible
• Containerization using Kubernetes
• Introduction to Kubernetes
• Namespace & Resources
• CI/CD – on GCP
• Deploying Apps on Openshift Container Pods
What is Configuration Management

• Configuration management means that it maintains configuration

of the product performance by keeping a record and updating
detailed information which describes an enterprise’s hardware and
software.
• Such information typically includes the exact versions and updates
that have been applied to installed software packages and the
locations and network addresses of hardware devices.
• For e.g. If you want to install the new version of WebLogic /
WebSphere server on all of the machines present in your enterprise,
it is not feasible for you to manually go and update each and every
machine.
• You can install WebLogic/WebSphere in one go on all of your
machines with Ansible playbooks and inventory written in the most
simple way.
• All you have to do is list out the IP addresses of your nodes in the
inventory and write a playbook to install WebLogic/WebSphere.
• Run the playbook from your control machine & it will be installed
on all your nodes.
Introduction to Ansible
• Ansible is an IT automation tool.
• It can configure systems, deploy software, and orchestrate more
advanced IT tasks such as continuous deployments or zero
downtime rolling updates.
• Ansible is easy to deploy because it does not use any agents or
custom security infrastructure.
• Ansible uses playbook to describe automation jobs, and playbook
uses very simple language i.e. YAML (Yet Another Mark-up
Language)
How Ansible Works?
• Ansible works by connecting to your nodes and pushing out small
programs, called "Ansible modules" to them.
• Ansible then executes these modules (over SSH by default), and
removes them when finished.
• Your library of modules can reside on any machine, and there are
no servers, daemons, or databases required.
• The management node in the picture is the controlling node
(managing node) which controls the entire execution of the
playbook.
• It’s the node from which you are running the installation.
• The inventory file provides the list of hosts where the Ansible
modules needs to be run and the management node does a SSH
connection and executes the small modules on the hosts machine
and installs the product/software.
• Beauty of Ansible is that it removes the modules once those are
installed so effectively it connects to host machine , executes the
instructions.
• If it’s successfully installed removes the code which was copied on
the host machine which was executed.
Ansible Tasks

• Playbooks are the files where Ansible code is written. Playbooks

are written in YAML format.
• YAML stands for Yet Another Markup Language.
• Playbooks are one of the core features of Ansible and tell Ansible
what to execute.
• They are like a to-do list for Ansible that contains a list of tasks.
• Playbooks contain the steps which the user wants to execute on a
particular machine.
• Playbooks are run sequentially.
• Playbooks are the building blocks for all the use cases of Ansible.
Playbook Structure

• Each playbook is an aggregation of one or more plays in it.

• Playbooks are structured using Plays.
• There can be more than one play inside a playbook.
• The function of a play is to map a set of instructions defined against
a particular host.
• YAML is a strict typed language.
• Extra care needs to be taken while writing the YAML files.
• There are different YAML editors but we will prefer to use a simple
editor like notepad++.
• Just open notepad++ and change the language to YAML (Language
→ YAML) and you can write the YAML code.
Create a Playbook
• Let us start by writing a sample YAML file. We will walk through each
section written in a yaml file.

• The above is a sample Playbook where we are trying to cover the basic
syntax of a playbook. Save the above content in a file as [Link].
• A YAML syntax needs to follow the correct indentation and one needs to
be a little careful while writing the syntax.
The Different YAML Tags
The different YAML tags are described below
name :
• This tag specifies the name of the Ansible playbook. As in what this
playbook will be doing. Any logical name can be given to the playbook.
hosts :
• This tag specifies the lists of hosts or host group against which we want to
run the task. The hosts field/tag is mandatory. It tells Ansible on which
hosts to run the listed tasks. The tasks can be run on the same machine or
on a remote machine.
vars :
• Vars tag lets you define the variables which you can use in your playbook.
Usage is similar to variables in any programming language.
tasks :
• All playbooks should contain tasks or a list of tasks to be executed. Tasks
are a list of actions one needs to perform.
Ansible - Roles
• Roles provide a framework for fully independent, or interdependent
collections of variables, tasks, files, templates, and modules.
• In Ansible, the role is the primary mechanism for breaking a
playbook into multiple files.
• This simplifies writing complex playbooks, and it makes them
easier to reuse.
• The breaking of playbook allows you to logically break the
playbook into reusable components.
• Each role is basically limited to a particular functionality or desired
output, with all the necessary steps to provide that result either
within that role itself or in other roles listed as dependencies.
• Roles are not playbooks.
• Roles are small functionality which can be independently used but
have to be used within playbooks.
• There is no way to directly execute a role.
• Roles have no explicit setting for which host the role will apply to.
Creating a new Role
• To create an Ansible role, it's enough to make a directory following
the standard directory structure .
• First, create the roles directory and switch to it:

• Then, use the command ansible-galaxy to initialize the role:

• Now, verify the role directory structure:

• Switch into the newly created directory:

• Your Vim role does not require any dependencies.

• Here's an example of a working meta configuration file.
• Update it with your name, company name, and a suitable license, if
necessary:
Jinja2 template
• Jinja2 is a powerful and easy to use python-based templating engine
that comes in handy in an IT environment with multiple servers
where configurations vary every other time.
• Creating static configuration files for each of these nodes is tedious
and may not be a viable option since it will consume more time and
energy.
• And this is where templating comes in.
• Jinja2 templates are simple template files that store variables that
can change from time to time.
• When Playbooks are executed, these variables get replaced by
actual values defined in Ansible Playbooks.
• This way, templating offers an efficient and flexible solution to
create or alter configuration file with ease.
Template architecture
• A Jinja2 template file is a text file that contains variables that get
evaluated and replaced by actual values upon runtime or code
execution.
• In a Jinja2 template file, you will find the following tags:

• In most cases, Jinja2 template files are used for creating files or
replacing configuration files on servers.
• Template files bear the .j2 extension, implying that Jinja2
templating is in use.
• Creating template files
• Here’s an example of a Jinja2 template file example_template.j2
which we shall use to create a new file with the variables shown.

• These variables are defined in a playbook and will be replaced by

actual values in the playbook YAML file [Link] below.

• When the playbook is executed, the variables in the template file

get replaced by the actual values and a new file is either created or
replaces an already existing [Link] in the destination path.
Jinja2 template with Conditionals
• Jinja2 templating can also be used with conditional statements such
as for loops to iterate over a list of items.
• Consider the Playbook [Link] as shown in the pictorial
below:
• We are going to create a template that will iterate over the list of car
models called ‘cars’ and print the result in the [Link] destination
file.

• The for loop in the Jinja2 template file – example2_template.j2 –

is as shown
• When the playbook is executed, the loop iterates over the car list,
and prints out the car models in the destination file.
• You can use the cat command to examine the output and verify
where the models exist in the file.
Ansible Vault
• Ansible Vault is an Ansible feature that helps you encrypt
confidential information without compromising security.
• While working with Ansible, you can create various playbooks,
inventory files, variable files, etc.
• Some of the files contain sensitive and important data like
usernames and passwords.
• Ansible provides a feature named Ansible Vault that prevents this
data from being exposed.
• It keeps passwords and other sensitive data in an encrypted file
rather than in plain text files.
• It provides password-based authentication.
Ansible Vault performs various operations
• Encrypt a file
• Decrypt a file
• View an encrypted file without breaking the
encryption
• Edit an encrypted file
• Create an encrypted file
• Generate or reset the encrypted key
Create an encrypted file

• The ansible-vault create command is used to create the encrypted

file.
• After typing this command, it will ask for a password.
• To check that the file has been encrypted, use the cat command.

• The following command is used to create encrypted files with --

vault id.
• Editing the encrypted file
If the file is encrypted and changes are required, use the edit
command.
• Decrypting a file
The ansible-vault decrypt command is used to decrypt the encrypted
file.
• Decrypt a running playbook
To decrypt the playbook while it is running, you usually ask for its
password.
• Reset the file password
Use the ansible-vault rekey command to reset the encrypted file
password. # ansible-vault rekey [Link]
Deployments using Ansible

• Ansible is the simplest way to deploy your applications.

• It gives you the power to deploy multi-tier applications reliably and
consistently, all from one common framework.
• You can configure needed services as well as push application
artifacts from one common system.
• Rather than writing custom code to automate your systems
• Your team writes simple task descriptions that even the newest team
member can understand on first read - saving not only up-front
costs, but making it easier to react to change over time.
Power of the playbooks
• REPEATABLE & RELIABLE
• Ansible allows you to write 'Playbooks' that are descriptions of the
desired state of your systems, which are usually kept in source
control.
• Ansible then does the hard work of getting your systems to that
state no matter what state they are currently in.
• Playbooks make your installations, upgrades and day-to-day
manage
• SIMPLE TO WRITE & MAINTAIN
• Playbooks are simple to write and maintain.
• Most users become productive with Ansible after only a few hours.
• Ansible uses the same tools you likely already use on a daily basis
and playbooks are written in a natural language so they are very
easy to evolve and edit.
• NO AGENT = MORE SECURE, MORE PERFORMANCE,
LESS EFFORT
• Thanks to its agentless design, Ansible can be introduced into your
environment without any bootstrapping of remote systems or
opening up additional ports.
• Not only does this eliminate "managing the management," but
system resource utilization is also dramatically improved.
• Zero downtime
• As alluded in the previous diagram, Ansible can orchestrate zero
downtime rolling updates trivially, ensuring you can update your
applications in production without users noticing.
• Super flexible
• Downloading artifacts from servers and configuring the OS are just
the basics.
• Talk to REST APIs, update a team chat server with a heads up, or
send an email - Ansible can drive all kinds of workflows.
• Cloud ready
• Included modules manage not just the local computer system, but
can interact with cloud services including Amazon AWS, Microsoft
Azure, and more.
• And since all cloud APIs allow you to trivially inject SSH keys, you
can start managing any cloud instance or network software without
modifying the base image.
Containerization using Kubernetes
• Containerization has become a major trend in software development as an
alternative or companion to virtualization.

• It involves encapsulating or packaging up software code and all its

dependencies so that it can run uniformly and consistently on any
infrastructure.

• The technology is quickly maturing, resulting in measurable benefits for

developers and operations teams as well as overall software infrastructure.

• Containerization allows developers to create and deploy applications

faster and more securely.

• With traditional methods, code is developed in a specific computing

environment which, when transferred to a new location, often results in
bugs and errors.
• For example, when a developer transfers code from a desktop computer to
a virtual machine (VM) or from a Linux to a Windows operating system.

• Containerization eliminates this problem by bundling the application code

together with the related configuration files, libraries, and dependencies
required for it to run.

• This single package of software or “container” is abstracted away from

the host operating system

• Hence, it stands alone and becomes portable—able to run across any

platform or cloud, free of issues.

• Containers are often referred to as “lightweight,” meaning they share the

machine’s operating system kernel and do not require the overhead of
associating an operating system within each application.

• Containerization allows applications to be “written once and run

anywhere.”
Benefits of Containerization
• Containerization offers significant benefits to developers and
development teams.
• Portability: A container creates an executable package of software
that is abstracted away from (not tied to or dependent upon) the host
operating system, and hence, is portable and able to run uniformly
and consistently across any platform or cloud.
• Agility: The open source Docker Engine for running containers
started the industry standard for containers with simple developer
tools and a universal packaging approach that works on both Linux
and Windows operating systems.
• Speed: Containers are often referred to as “lightweight,” meaning
they share the machine’s operating system (OS) kernel and are not
bogged down with this extra overhead.
• Fault isolation: Each containerized application is isolated and
operates independently of others. The failure of one container does
not affect the continued operation of any other containers.
Development teams can identify and correct any technical issues
within one container without any downtime in other containers.
• Efficiency: Software running in containerized environments shares
the machine’s OS kernel, and application layers within a container
can be shared across containers.
• Ease of management: A container orchestration platform
automates the installation, scaling, and management of
containerized workloads and services.
• Container orchestration platforms can ease management tasks such
as scaling containerized apps, rolling out new versions of apps, and
providing monitoring, logging and debugging, among other
functions.
Kubernetes

• Kubernetes is an open source orchestration tool developed by

Google for managing microservices or containerized applications
across a distributed cluster of nodes.
• Kubernetes — also known as “k8s” or “kube” — is a container
orchestration platform for scheduling and automating the
deployment, management, and scaling of containerized
applications.
• Kubernetes provides highly resilient infrastructure with zero
downtime deployment capabilities, automatic rollback, scaling, and
self-healing of containers (which consists of auto-placement, auto-
restart, auto-replication , and scaling of containers on the basis of
CPU usage).
• It groups containers that make up an application into logical units
for easy management and discovery.
• The main objective of Kubernetes is to hide the complexity of
managing a fleet of containers by providing REST APIs for the
required functionalities.
• Kubernetes is portable in nature, meaning it can run on various
public or private cloud platforms such as AWS, Azure, OpenStack,
or Apache Mesos.
• It can also run on bare metal machines.
Kubernetes Components and Architecture
• Kubernetes follows a client-server architecture.
• It’s possible to have a multi-master setup (for high availability), but
by default there is a single master server which acts as a controlling
node and point of contact.
• The master server consists of various components including a kube-
apiserver, an etcd storage, a kube-controller-manager, a cloud-
controller-manager, a kube-scheduler, and a DNS server for
Kubernetes services.
• Node components include kubelet and kube-proxy on top
of Docker.
Kubernetes Architecture
Master Components
• etcd cluster – a simple, distributed key value storage which is used
to store the Kubernetes cluster data (such as number of pods, their
state, namespace, etc), API objects and service discovery details. It
is only accessible from the API server for security reasons.
• kube-apiserver– Kubernetes API server is the central management
entity that receives all REST requests for modifications (to pods,
services, replication sets/controllers and others), serving as frontend
to the cluster.
• kube-controller-manager – runs a number of distinct controller
processes in the background (for example, replication controller
controls number of replicas in a pod, endpoints controller populates
endpoint objects like services and pods, and others) to regulate the
shared state of the cluster and perform routine tasks.
• cloud-controller-manager – is responsible for managing controller
processes with dependencies on the underlying cloud provider (if
applicable).
• For example, when a controller needs to check if a node was
terminated or set up routes, load balancers or volumes in the cloud
infrastructure, all that is handled by the cloud-controller-manager.

• kube-scheduler – helps schedule the pods (a co-located group of

containers inside which our application processes are running) on
the various nodes based on resource utilization.
• It reads the service’s operational requirements and schedules it on
the best fit node.
Node (worker) components

Kubectl
kubectl command is a line tool that interacts with kube-apiserver
and send commands to the master node. Each command is
converted into an API call.
Kubernetes Design Principles
• Scalability – Kubernetes provides horizontal scaling of pods on the basis
of CPU utilization.
• The threshold for CPU usage is configurable and Kubernetes will
automatically start new pods if the threshold is reached.
• For example, if the threshold is 70% for CPU but the application is
actually growing up to 220%, then eventually 3 more pods will be
deployed so that the average CPU utilization is back under 70%.

• High Availability – Kubernetes addresses highly availability both at

application and infrastructure level.
• Replica sets ensure that the desired (minimum) number of replicas of a
stateless pod for a given application are running.
• Stateful sets perform the same role for stateful pods.
• At the infrastructure level, Kubernetes supports various distributed
storage backends like AWS EBS, Azure Disk, Google Persistent Disk,
NFS, and more.
• Security – Kubernetes addresses security at multiple levels: cluster,
application and network.
• The API endpoints are secured through transport layer security
(TLS).
• Only authenticated users (either service accounts or regular users)
can execute operations on the cluster (via API requests).
• At the application level, Kubernetes secrets can store sensitive
information (such as passwords or tokens) per cluster (a virtual
cluster if using namespaces, physical otherwise).
• Note that secrets are accessible from any pod in the same cluster.
• Portability – Kubernetes portability manifests in terms of operating
system choices (a cluster can run on any mainstream Linux
distribution), processor architectures (either virtual machines or
bare metal), cloud providers (AWS, Azure or Google Cloud
Platform), and new container runtimes, besides Docker, can also be
added.
Namespace & Resources
• In Kubernetes, namespaces provides a mechanism for isolating
groups of resources within a single cluster.
• Names of resources need to be unique within a namespace, but not
across namespaces.
• Namespace-based scoping is applicable only for namespaced
objects (e.g. Deployments, Services, etc) and not for cluster-wide
objects (e.g. StorageClass, Nodes, PersistentVolumes, etc).
• Namespaces are a way to divide cluster resources between multiple
users.
• You can list the current namespaces in a cluster using:
> kubectl get namespace
• Kubernetes starts with four initial namespaces:
• default The default namespace for objects with no other namespace
• kube-system The namespace for objects created by the Kubernetes
system
• kube-public This namespace is created automatically and is
readable by all users
• kube-node-lease This namespace holds Lease objects associated
with each node.
What are resources?
• A resource is an endpoint in the Kubernetes API that stores a collection
of API objects of a certain kind
• For example, the built-in pods resource contains a collection of Pod
objects.
• A custom resource is an extension of the Kubernetes API that is not
necessarily available in a default Kubernetes installation.

• It represents a customization of a particular Kubernetes installation.

• However, many core Kubernetes functions are now built using custom
resources, making Kubernetes more modular.

• Custom resources can appear and disappear in a running cluster through

dynamic registration, and cluster admins can update custom resources
independently of the cluster itself.

• Once a custom resource is installed, users can create and access its objects
using kubectl, just as they do for built-in resources like Pods
CI/CD on GCP
• Google Cloud Platform(GCP) is one of the leading cloud providers
in the public cloud market.
• It provides a host of managed services, and if you are running
exclusively on Google Cloud, it makes sense to use the managed
CI/CD tools that Google Cloud provides.
• A typical Continuous Integration & Deployment setup on Google
Cloud Platform looks like the below.
• Developer checks in the source code to a Version Control system
such as GitHub
• GitHub triggers a post-commit hook to Cloud Build.
• Cloud Build builds the container image and pushes to Container
Registry.
• Cloud Build then notifies Cloud Run to redeploy
• Cloud Run pulls the latest image from the Container Registry and
runs it.
• We will use Google Cloud Build to build a simple java application,
store the docker image in Google Container Registry, and deploy it
to Google Cloud Run.
The Dockerfile:

• Builds a tomcat 8.5 instance from scratch

• Clones the source code of a sample web application (You can
substitute that with your git repo)
• Builds the application using maven
• Copies the built war file to the webapps directory as [Link]
• Runs [Link] as the entry point script
Contains configuration to use the Google Cloud Build service that
• Builds the docker image in Google Cloud Platform
• Pushes the container image into the Google Cloud Registry
• Deploys the image to Google Cloud Run
Deploying Apps on Openshift Container Pods

• OpenShift Container Platform deployments provide fine-grained

management over common user applications.
• They are described using three separate API objects:
• A deployment configuration, which describes the desired state of a
particular component of the application as a pod template.
• One or more replication controllers, which contain a point-in-time
record of the state of a deployment configuration as a pod template.
• 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.
• Instances of your application are automatically added and removed
from both service load balancers and routers as they are created.
• As long as your application supports graceful shutdown when it
receives the TERM signal, you can ensure that running user
connections are given a chance to complete normally.
Features provided by the deployment system:
• A deployment configuration, which is a template for running
applications.
• Triggers that drive automated deployments in response to events.
• User-customizable strategies to transition from the previous version
to the new version. A strategy runs inside a pod commonly referred
as the deployment process.
• A set of hooks for executing custom behavior in different points
during the lifecycle of a deployment.
• Versioning of your application in order to support rollbacks either
manually or automatically in case of deployment failure.
• Manual replication scaling and autoscaling.