Priya Vishwakarma
BE IT-2 64
Assignment 2
Q1. Give Detailed comparison between Puppet, Chef, Saltstack and Ansible
Ans:
Chef vs Puppet vs Ansible vs Saltstack based on following parameters-
Availability:
Chef – When there is a failure on the primary server i.e. chef server, it has a backup
server to take the place of the primary server.
Puppet – It has multi-master architecture, if the active master goes down, the other
master takes the active master place.
Ansible – It runs with a single active node, called the Primary instance. If primary goes
down, there is a Secondary instance to take its place.
Saltstack – It can have multiple masters configured. If one master is down, agents
connect with the other master in the list. Therefore it has multiple masters to configure
salt minions.
Ease of Setup:
Chef – Chef has a master-agent architecture. Chef server runs on the master machine
and Chef client runs as an agent on each client machine. Also, there is an extra
component called workstation, which contains all the configurations which are tested
and then pushed to central chef server. Therefore, it is not that easy.
Puppet – Puppet also has a master-agent architecture. Puppet server runs on the
master machine and Puppet clients runs as an agent on each client machine. After
that, there is also a certificate signing between the agent and the master. Therefore, it is
also not that easy.
Ansible – It has only master running on the server machine, but no agents running on
the client machine. It uses ssh connection to login to client systems or the nodes you
want to configure. Client machine VM requires no special setup, hence it is faster to
setup!
Saltstack – Here Server is called as salt master and clients are called as
salt minions which run as agents in the client machine.
Management:
Chef – You need to be a programmer to manage the configurations as it offers
configurations in Ruby DSL. Client pulls the configurations from the Server.
Puppet – Not very easy to manage the configurations as it uses its own language called
Puppet DSL(Domain Specific Language). Client pulls the configurations from the
Server. It is quite system-administrator oriented and there is non-immediate remote
execution.
Ansible – Easy to learn to manage the configurations as it uses YAML i.e. Yet Another
Markup Language which closely resembles English. Server pushes configurations to all
the nodes. Good for real-time application and there is immediate remote execution.
Saltstack – Easy to learn to manage the configurations as it uses YAML as well. Server
pushes configurations to all the clients. Immediate remote execution.
Scalability:
All the four tools are highly scalable. Suppose if you need to configure around 50 nodes
today, and tomorrow say 500. Not a problem with these tools. It can handle large
infrastructure, you just need to specify the IP address and the hostname of the nodes
that you want to configure and rest of the task will be handled by these tools. Therefore,
all these tools are highly scalable.
Configuration Language:
Chef – Chef uses Ruby Domain Specific Language (Ruby DSL). It has a steep Learning
Curve and its developer oriented.
Puppet – Puppet uses its own puppet Domain Specific Language (Puppet DSL). It is
not very easy to learn and its system administrator oriented.
Ansible – Ansible uses YAML i.e Yet Another Markup Language (Python). It is
quite easy to learn and its administrator oriented. Python is inbuilt into most Unix and
Linux deployments nowadays, so setting the tool up and running is quicker.
Saltstack – Salstack also uses YAML (Python). It is again easy to learn
and administrator oriented.
Interoperability:
In these tools, master or main server or you can also say control machine, has to be on
Linux/Unix but their slaves or the nodes that they have to configure can be on windows.
Chef – Chef Server works only on Linux/Unix but Chef Client and Workstation can be
on windows as well.
Puppet – Puppet Master works only on Linux/Unix but Puppet Agent also works on
windows.
Ansible – Ansible supports windows machines as well but the Ansible server has to be
on Linux/Unix machine.
Saltstack – Salt Master works only on Linux/Unix but Salt minions can work on
windows as well.
Pricing:
The enterprise cost for the configurations tools are as follows:
Chef – Chef Automate gives you everything you need to build, deploy in $137 node/
annual.
Puppet – Pricing for puppet ranges from $112 per node/year with a standard support
plan to $199 per node/year with the premium plan.
Ansible – The pricing for Ansible Tower for standard IT operations up to 100 nodes is
$10,000/year. This includes 8*5 support whereas premium offers 24*7 support for
$14000/ year.
Saltstack – The cost for Saltstack Enterprise per 100 nodes is $15,00/ year(approx).
You can contact the support for the current annual subscription price.
Q2. Why is continuous monitoring necessary? How does Nagios works? What is
NRPE in Nagios.
Ans:
Continuous monitoring -
Continuous monitoring refers to the process and technology required to
incorporate monitoring across each phase of your DevOps and IT operations
lifecycles.
It helps to continuously ensure the health, performance, and reliability of your
application and infrastructure as it moves from development to production
Continuous monitoring is important because the process is skeptical about
potential threats
. A good continuous monitoring program is the one that is flexible and features
highly reliable, relevant and effective controls to deal with the potential threats.
Nagios –
Nagios is used for Continuous monitoring of systems, applications, services, and business
processes etc in a DevOps culture. In the event of a failure, Nagios can alert technical staff of
the problem, allowing them to begin remediation processes before outages affect business
processes, end-users, or customers. With Nagios, you don’t have to explain why an unseen
infrastructure outage affect your organization’s bottom line.
How Nagios work:
Consider the diagram below:
Nagios runs on a server, usually as a daemon or a service.
It periodically runs plugins residing on the same server, they contact hosts or servers on your
network or on the internet. One can view the status information using the web interface. You
can also receive email or SMS notifications if something happens.
The Nagios daemon behaves like a scheduler that runs certain scripts at certain moments. It
stores the results of those scripts and will run other scripts if these results change.
Plugins: These are compiled executables or scripts (Perl scripts, shell scripts, etc.) that can be
run from a command line to check the status or a host or service. Nagios uses the results from
the plugins to determine the current status of the hosts and services on your network.
Nagios Architecture:
Nagios is built on a server/agents architecture.
Usually, on a network, a Nagios server is running on a host, and Plugins interact with
local and all the remote hosts that need to be monitored.
These plugins will send information to the Scheduler, which displays that in a GUI.
NRPE (Nagios Remote Plugin Executor) in Nagios :
The NRPE addon is designed to allow you to execute Nagios plugins on remote
Linux/Unix machines. The main reason for doing this is to allow Nagios to monitor
“local” resources (like CPU load, memory usage, etc.) on remote machines. Since these
public resources are not usually exposed to external machines, an agent like NRPE
must be installed on the remote Linux/Unix machines.
Consider the diagram below:
The check_nrpe plugin, resides on the local monitoring machine.
The NRPE daemon, runs on the remote Linux/Unix machine.
There is a SSL (Secure Socket Layer) connection between monitoring host and remote
host as shown in the diagram above.
