DevOps

Git hooks are the instruction scripts that gets triggered before(pre) or post(after) certain actions or events such as a git command run.

• Git hooks can be implemented on both client(local machine) and server(remote) repositories.
• Hooks objects are stored under .git/hooks directory. Hooks scripts are written in shell script and made executable.
• --Code snippet of a ‘pre-commit’ script that stops the commit if a file has been deleted from the project:

#!/bin/sh
#Library includes:
. .git/hooks/hooks_library.lib
# An example hook script to verify what is about to be committed.
# Called by "git commit" with no arguments.  The hook should
# exit with non-zero status after issuing an appropriate message if
# it wants to stop the commit.
#Aim:Check for any Deleted file in the staging area, if any it stops you from commiting this snapshot.
set_variables 1 $0
if [ "$(git status --short | grep '^D')" ];then
        echo "WARNING!!! Aborting the commit. Found Deleted files in the Staging area.\n" | tee -a $LOGFILE
        echo "`git status --short | grep '^D' | awk -F' ' '{print $2}'`\n" | tee -a $LOGFILE
        exit 1;
else
        echo "[OK]: No deleted files, proceed to commit." | tee -a $LOGFILE
        exit 0;
fi

Scenario how I implemented the hooks scripts to enforce certain pre-commit and post-commit test cases:

Step 1: Running .git/hooks/pre-commit script.

[OK]: No deleted files, proceed to commit.
Thu Feb  7 12:10:02 CET 2019
--------------------------------------------

Step 2: Running .git/hooks/prepare-commit-msg script.

Get hooks scripts while cloning the repo. 
ISSUE#7092
Enter your commit message here.
README
code/install_hooks.sh
code/runTests.sh
database.log
hooksScripts/commit-msg
hooksScripts/hooks_library.lib
hooksScripts/post-commit
hooksScripts/pre-commit
hooksScripts/pre-rebase
hooksScripts/prepare-commit-msg
newFile
Thu Feb  7 12:10:02 CET 2019
--------------------------------------------

Step 3: Running .git/hooks/commit-msg script.

[OK]: Commit message has an ISSUE number
Thu Feb  7 12:10:02 CET 2019
--------------------------------------------

Step 4: Running .git/hooks/post-commit script.

New commit made:

1c705d3 Get hooks scripts while cloning the repo.
ISSUE#7092

• A ‘pre-rebase’ script to stop the rebase on a ‘master’ branch:
• Rebase ‘topic’ branch on ‘master’ branch

hooksProj [dev] $git rebase master topic
WARNING!!! upstream branch is master.
You are not allowed to rebase on master
The pre-rebase hook refused to rebase.

A code snippet demonstrating the use of a ‘pre-receive’ hook that is triggered just before a ‘push’ request on the Server, can be written to reject or allow the push operation.

localRepo [dev] $git push
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (2/2), 272 bytes | 272.00 KiB/s, done.
Total 2 (delta 0), reused 0 (delta 0)
remote: pre-recieve hook script
remote: hooks/pre-receive: [NOK]- Abort the push command
remote:
To /Users/Divya1/OneDrive/gitRepos/remoteRepo/
! [remote rejected] dev -> dev (pre-receive hook declined)
error: failed to push some refs to '/Users/Divya1/OneDrive/gitRepos/remoteRepo/'

Install a new package in a container

docker run -it ubuntu
root@851edd8fd83a:/# which yum
--returns nothing
root@851edd8fd83a:/# apt-get update
root@851edd8fd83a:/# apt-get install -y yum
root@851edd8fd83a:/# which yum
/usr/bin/yum
--Get the latest container id
CONTAINER ID        IMAGE  COMMAND   CREATED STATUS                        PORTS NAMES
851edd8fd83a        ubuntu  "/bin/bash"   6 minutes ago Exited (127) 3 minutes ago                        
--base image changed
docker diff 851edd8fd83a

Commit the changes in the container to create a new image.

Divya1@Divya:~ $docker commit 851edd8fd83a mydocker/ubuntu_yum
sha256:630004da00cf8f0b8b074942caa0437034b0b6764d537a3a20dd87c5d7b25179

--List if the new image is listed

Divya1@Divya:~ $docker images
REPOSITORY            TAG IMAGE ID            CREATED SIZE
mydocker/ubuntu_yum   latest 630004da00cf        20 seconds ago 256MB

• mkdir dockerFiles
• vi dockerfile

FROM divyabhushan/myrepo:latest
COPY hello.sh /home/hello.sh
CMD ["bash", "/home/hello.sh"]
CMD ["echo", "Dockerfile demo"]
RUN echo "dockerfile demo" >> logfile

--Build an image from the dockerfile, tag the image name as ‘mydocker’

docker build -t mydocker dockerFiles/
docker build --tag <containerName> <dockerfile location>
Divya1@Divya:~ $docker images
REPOSITORY            TAG IMAGE ID            CREATED SIZE
mydocker              latest aacc2e8eb26a        20 seconds ago 88.1MB
Divya1@Divya:~ $docker run mydocker
/home/divya
Hello Divya
Bye Divya

• View the images:
• docker image
• docker image --all
• docker run -it ubuntu (imageName)
• -i = interactive
• -t = Allocate a sudo-tty (i.e, provide a terminal for the remote container image)

Write instructions in a dockerfile.

• build the dockerfile and create an image in the registry

docker build -t learn_docker dockerFiles/

• Create a container by running this image

docker run -it learn_docker

• Push the container to the docker hub.

--Tag the local image as:

<hub-user>/<repo-name>:[:<tag>]

Examples:

docker tag learn_docker divyabhushan/learn_docker:dev
docker tag learn_docker divyabhushan/learn_docker:testing

--list the images for this container:

Divya1@Divya:~ $docker images
REPOSITORY                  TAG IMAGE ID            CREATED SIZE
divyabhushan/learn_docker   develop 944b0a5d82a9        About a minute ago 88.1MB
learn_docker                dev1.1 944b0a5d82a9        About a minute ago 88.1MB
divyabhushan/learn_docker   dev d3e93b033af2        16 minutes ago 88.1MB
divyabhushan/learn_docker   testing d3e93b033af2        16 minutes ago 88.1MB
Push the docker images to docker hub
docker push divyabhushan/learn_docker:dev
docker push divyabhushan/learn_docker:develop
docker push divyabhushan/learn_docker:testing
The push refers to repository [docker.io/divyabhushan/ learn_docker]
53ea43c3bcf4: Pushed
4b7d93055d87: Pushed
663e8522d78b: Pushed
283fb404ea94: Pushed
bebe7ce6215a: Pushed
latest: digest: sha256:ba05e9e13111b0f85858f9a3f2d3dc0d6b743db78880270524e799142664ffc6 size: 1362

• Image: Screenshot from the Docker hub.
• Docker hub repository: learn_docker has different variations of images. Image names are tagged.
• We can pull the tags from this repository as per the need.

Summarize:

Develop your application code and all other dependencies like the binaries, library files, downloadables required to run the application in the test environment. Bundle it all in a directory.

• Edit the dockerfile to Run the downloadables and replicate the desired production environment as test env.
• Copy the entire application bundle to the test env in the docker container.
• Build the dockerfile and create new docker image and tag it.
• Push this docker image to the docker hub, which is now downloaded by other users to test.

NOTE: This docker image has your application bundle = application code + dependencies + test run time environment exactly similar to your machine. Your application bundle is highly portable with no hassles.

A must-know for anyone looking for top DevOps coding interview questions, this is one of the frequently asked CI CD interview questions.

Docker provides a system prune command to remove stopped containers and dangling images.Dangling images are the ones which are not attached to any container.

Run the prune command as below:

docker system prune

WARNING! This will remove:

• all stopped containers
• all networks not used by at least one container
• all dangling images
• all dangling build cache

Are you sure you want to continue? [y/N]

There is also a better and controlled way of removing containers and images using the command:

Step 1: Stop the containers

docker stop <container_id>

Step 2: Remove the stopped container

docker rm container_id
docker rm 6174664de09d

Step 3: Remove the images, first stop the container using those images and then

docker rmi <image_name>:[<tag>]

--give image name and tag

docker rmi ubuntu:1.0

--give the image id

docker rmi 4431b2a715f3

As the number of docker machines increases, there needs to be a system to manage them all. Docker Orchestration is a virtual docker manager and allows us to start, stop, pause, unpause or kill the docker nodes(machines).

Docker has an in-built utility called “docker swarm”.

Kubernetes is another popular and versatile docker orchestration system used. A cluster of dockers is called a ‘swarm’. Swarm turns a collection of docker engines into a single virtual docker engine.

In a swarm orchestration arrangement, one machine acts as a swarm manager that controls all the other machines connected to the cluster that acts as swarm nodes.

This is how I created a swarm of dockers and managed them on my machine:

We need docker services and docker machines to run these services on.Finally, we need a docker swarm to manage the docker nodes/machines

• Commands we need:
• docker service
• docker-machine
• docker swarm
• Task
• Create docker machines(nodes) and services.

Create a docker swarm and manage the services on different nodes and port numbers.

• Step 1: Create docker machines as ‘manager’ and ‘worker’: manager, node1, node2, node3, node4
• Step 2: Create a docker swarm
• Step 3: Add the nodes as workers(or another manager) to the swarm
• Step 4: From the manager create docker services
• Step 5: list the docker services created also use -ps flag to view the node machines these services are running on.
• Step 6: Open the <ip_address>:<port_number> in the browser and confirm the services running.

Step 1: Create docker machines: manager, node1, node2, node3, node4

docker-machine create --driver virtualbox manager

docker-machine create --driver virtualbox node1
docker-machine create --driver virtualbox node2
docker-machine create --driver virtualbox node3
docker-machine create --driver virtualbox node4
--Every node is started as a virtualbox machine.
--set docker machine ‘manager’ as active
eval $(docker-machine env manager)
--List the docker machines

Step 2: Create a docker swarm

--Initialize a swarm and add ‘manager’ to the swarm cluster using its ip address: 192.168.99.100

Step 3: Add the nodes as workers(or another manager) to the swarm

--Connect to each node and run the above swarm join command

There can be more than one ‘manager’ node in a swarm

--connect to node1 and join node1 to the swarm as a worker

docker-machine ssh node1

--List the nodes connected in the swarm

connect to manager node:

$docker-machine ssh manager

Step 4: From the ‘manager’ node create new docker services

docker-machine ssh manager

--Create service replicating them on more than 1 nodes and expose them on the mentioned port.

This command pulls the docker image from docker hub.

Step 5: list the docker services created also use -ps flag to view the node machines these services are running on.

--List the services that will be shared among different swarm nodes

Swarm randomly assigns nodes to the running services when we replicate the services.

--service ‘httpd’ running on 3 nodes: node1, node2 and node3

--service ‘couchbase’ is running on 2 nodes: node1 and manager at port: 8091

--’couchbase’ service can be accessed via ‘node1’ (ip: 192.168.99.101) and ‘manager’ (ip: 192.168.99.100) at port : 8091 as show below

• http://192.168.99.101:8091/
• http://192.168.99.100:8091
• --’httpd’ service
• http://192.168.99.101:80
• http://192.168.99.102:80
• http://192.168.99.103:80
• --’my_nginx’ service
• http://192.168.99.100:8080
• http://192.168.99.104:8080

Screenshots of the running services:

‘manager’ node can create/inspect/list/scale or remove a service.

Refer

docker service --help

Conclusion:

A number of services are balanced over different nodes(machines) in a swarm cluster.A node declared as a ‘manager’ controls the other nodes.Basic ‘docker commands’ works from within a ‘manager’ node.

The above failure happens when the ‘manager’ docker machine is not active; as a result, the new node machine will not be able to join the swarm cluster.

To fix this:

• Step 1: Check for the active machine hosts as:

• Step 2: Activate the ‘manager’ machine as:

• Step 3: Get the swarm join token as worker

• Step 4: Connect to the worker machine say: worker2 [ To create docker node machines as worker: join node as a worker ]

Divya1@Divya:~ $docker-machine ssh worker2

• Step 5: Run the swarm join token command; it will be successful

System resources are the key elements of a Puppet code that defines the architecture and manages the configuration of a system infrastructure.

• Puppet has its own DML (Declarative Modelling Language) to write code.
• The main unit of code is called a resource.
• Puppet uses various types of resources to define the different definitions and parameters of a system.

Here is how a resource is written:

resource_type { ‘resource_name’:
attribute => value,
attribute => value,
…
}

• Each resource has 3 items: Resource_type, resource_name and the attributes.

Example:

user { ‘Jack’:
ensure => present,
owner => ‘root',
group => ‘home’,
mode => 0644,
shell => ‘/bin/bash’
}

This code evaluates as:
Resource type ‘user’ with the resource parameter ‘Jack’ have the attributes: ‘ensure’, ‘owner’, ‘group’, ‘mode’ and ‘shell’.

These attributes have the respective values.

We can get a list of all the available resource types with the command:

• puppet describe --list

Some of the common resource types are:

• user
• package
• exec
• file
• service

Example of resource_type: ‘service’. This resource ensures that the service: ‘network’ is running service 

{‘network’ :
ensure => running
}
This resource checks the ‘package’: ‘apache’ is running and its pre-requisite requires ‘apt-update’ command to be executed.
package { ‘apache’ :
require => Exec[‘apt-update’],
ensure => running
}

• Step 1: Run the Docker container with puppet server installed.
• Step 2: Write a basic manifest file:

vi /etc/puppet/manifests/lamp.pp

• Step 3: Add the resources to install Apache, MySQL and PHP server

exec { ‘apt-update’ :
 command => '/usr/bin/apt-get update'  
}
# install apache2 package
package { 'apache2':
 require => exec['apt-update'],        
 ensure => installed,
}
# ensure apache2 service is running
service { 'apache2':
 ensure => running,
}
# install mysql-server package
package { 'mysql-server':
 require => exec['apt-update'],        
 ensure => installed,
}
# ensure mysql service is running
service { 'mysql':
 ensure => running,
}
# install php5 package
package { 'php5':
 require => exec['apt-update'],        
 ensure => installed,
}
# ensure info.php file exists
file { '/var/www/html/info.php':
 ensure => file,
 content => '<?php  phpinfo(); ?>', # phpinfo code
 require => package['apache2'],        
}

Save and exit.

• Step 4: Apply manifest

puppet apply --test

This, along with other DevOps practical interview questions for freshers, is a regular feature in DevOps interviews. Be ready to tackle it with the approach mentioned above.

Jenkins stores the metadata of every project under $WORKSPACE path.

Two projects:

• myProject and project_next can be chained to each other and they can share the same data.
• On successful build of ‘myProject’, build of ‘project_next’ is triggered.

Below code screenshot is for project_next

This access the myProject/logs/db.log file and read it for a pattern :’prod’

Jenkins auto-builds the source code from Git(any VCS) at every check-in; tests the source code and deploy the code in a tomcat environment via docker. Webapp source code is then deployed by tomcat server on a production environment.

Pre-requisite:

• Jenkins plugin: “Deploy to container” and “git plugin”
• Edit the ‘post-build’ actions to include the tomcat details.
• Under the SCM section add your git project repository url.

Git project structure:

Divya1@Divya:myWeb [master] $
Dockerfile
   webapp/
       WEB-INF/
         classes/
         lib/
         web.xml
    index.jsp
--Dockerfile content:
vi Dockerfile
FROM tomcat:9.0.1-jre8-alpine
ADD ./webapp /usr/local/tomcat/webapps/webapp
CMD ["catalina.sh","run"]

Add a new project in Jenkins and track your git project url under SCM section.Have a dockerfile with the instruction to connect to the tomcat docker and deploy the webapp folder.

--Add the build section to ‘execute shell’ as below:

#!/bin/sh
echo "Build started..."
docker build -t webapp .
echo "Deploying webapp to tomcat"
docker run -p 8888:8080 webapp
echo http://localhost:8888/webapp
--Build the project from Jenkins:

Below is the screenshot of the output:

--Click on the link: http://localhost:8888/webapp

This is one of the common yet tricky DevOps interview questions and answers for experienced professionals, so do not miss this one.

• Pipelines artifacts
• Jenkins has built-in artifacts to record and capture the failures for analysis and investigation.
• This needs to be mentioned in the jenkinsfile pipeline:

Sample code:

Pipeline {
agent any
stages {
stage(‘Build’) {
steps {
sh ‘./test_suite1 build’
}
}
Stage(‘Test’) {
Steps {
sh ‘./test_suite1 test’
}
}
}
post {
always {
archiveArtifacts ‘build/libs/**/*.jar’
}
}
}

This gives the artifacts path and the filename

Backup of Jenkins is needed in case of disaster recovery, retrieving old configuration and for auditing.

$JENKINS_HOME folder keeps all the Jenkins metadata.

That includes: build logs, job configs, plugins, plugin configurations etc.

Install the ‘think backup’ plugin in Jenkins and enable the backup from settings tab.We have to specify the backup directory and what we want to backup.

Backup directory: $JENKINS_HOME/backup

Backup files generated with the timestamp in the filenames will be stored under the path we specified.

divya@jenkins backup]$ pwd
/var/lib/Jenkins/backup
uat@jenkins backup]$ls

FULL-2019-02-4_07-14 FULL-2019-02-11_13-07

It is a good practice to version control (using Git) this back-up and move it to cloud.

Restoring:

Backup files are in the tar+zip format.

Copy these over to another server; unzip and un-tar it on the server.

cd $JENKINS_HOME
tar xvfz /backups/Jenkins/backup-project_1.01.tar.gz
config.xml
jobs/myjob/config.xml
…

A staple in DevOps technical interview questions and answers, be prepared to answer this using your hands-on experience.