Chef vs Puppet vs Ansible vs SaltStack | Configuration Management Tools Comparison | Edureka

Chef vs Puppet vs Ansible vs SaltStack | Configuration Management Tools Comparison | Edureka

Hello, everyone. This is Saurabh from Edureka. Today’s session will deal with a comparison between various
configuration management tools, namely Chef, Puppet, Ansible and Saltstack.
First thing first guys, let us have a look
at the agenda for today. So first we will understand
the devops life cycle that is various stages
in devops and the tools that are used in those stages. After that will understand
what is configuration management and deployment and why
is it that important? Finally we’ll compare
the for configuration management tools Chef puppet
ansible and saltstack. So are we clear
with the agenda guys? Kindly give me
a quick confirmation by writing down in the chat box. Bennett says yes,
Janice Rahul Arpan cool. Great. Let’s move forward and understand the
devops life cycle. There is a devops life cycle
as you can see. It is an infinite Loop. It is a never-ending process. It starts from plan
where you gather all the requirements
for your application. Then you start coding for it after that the continuous
integration servers, like Jenkins will pull that code
and prepare a build, After that, the build application is deployed onto the test
server for testing once testing is done. It is then deployed onto the
production server for release after the product is released. It is continuously monitored
by tools like nah device that provides relevant feedback
to the concern teams. This feedback can be anything
like the downtime or is there any defect in the product or
how is it doing in the market? So all those things are fed back
to the concern teams, and those teams takes
the necessary actions. So I hope you all are clear
with the devops life cycle. Let me add this thing guys. Let us make
this session interactive. You won’t even enjoy it
if it’s a one-way conversation. So any questions any doubt
at any point of time, you are free to ask me. So if you are clear, just just give me
a quick confirmation. Thank you. Thank you guys
for your confirmation now, I’ll move forward
and we look at various tools that are used in these stages. So for code we have get jira
Eclipse subversion for build. We have Maven Gradle
an ad for testing. We have selenium J unit
for continuous integration. We have Jenkins bamboo
for continuous monitoring. We have nog us
for configuration management and deployment we
have puppet chef and smell and salsa. So this particular slide is highlighting the for
configuration management tools that we will compare in today’s
session puppet chef ansible and saltstack but
before we move forward, we need to First understand the reason
for using these tools. So for that we will have a look
at various problems that industries were phasing before configuration management
and deployment was introduced or before these tools
came into the picture. So we’ll have a look
at those problems one by one. So the first problem
is a mass deployment. Let us understand this with an example suppose you
have opened a business and it is pretty small
in the beginning. So if you need to deploy
a particular application say on five vm’s it is a pretty easy
task you can do it manually, but what happens when your business becomes huge
it becomes like WhatsApp, then you need to deploy the same
application say on 500 GM’s so you cannot do
that task manually. Can you So why do we need here? We need some kind
of an automation or some kind of tool that can automate
at this task for us. Okay. So a Bennett has a question. He’s asking why can’t we deploy the application on 500 GM’s
manually when it first of all if you do it manually
there’s a higher risk of human error apart from that. It will take a lot of time. What if you have to finish
the task overnight tomorrow might be a big billion day sale
in your company or a mega sale in which
heavy traffic is expected. So you need some kind of a tool that can automate
this task for you. Are we clear? Thank you Bennet
for your confirmation. So let us move forward and have
a look at the second problem. Problem 2 migrating
from test to production as you can see that there is a construction guy
who is very worried because he has made
a blueprint for a house. He has planned
everything tested everything and when he has been he built
the house it is on fire. You can relate the same scenario with software delivery
life cycle as well. We’re developers
build application which works fine till testing but when it reaches production
due to the difference in the Computing environment
certain functions of that applications
are not working properly. This is a very common scenario
and I think a lot of you who are developers can relate
to this particular scenario. So what do we need here? We need a tool that can provide
a consistent environment throughout the software
delivery life cycle. Let us move forward and have
a look at the third scenario. It is about application failure. As you can see that there is a manager
who is very angry and frustrated who’s banging his desk and calling one
of his employee at 3 a.m. Because he has updated a particular software and
that is not working properly. There are certain glitches
in that software. Now the manager
wants to roll back to the previous stable version
of the software. But since there is
no accurate historical record of system State available
with the employee. He has no idea
how to roll back quickly. Obviously he can
do that manually, but it will take a lot of time. Now let us have a look at the case study which depicts
this particular scenario. It is about an online
travel booking website in UK called the train
there certain starts about it. There is one point two
billion pounds annual revenue and nine plus million
visits per month. So you can imagine a company
this big Vision rating 1.2 billion pounds
of annual revenue. What will happen if there is a downtime
in their website as you can see from the graph that their website
went down Thrice so you can imagine the loss
probably millions of dollars. So all these scenarios all
these three problems that we have discussed points down
to one single solution that we need some kind of tool that can automate
these tasks for us that can roll back to
a previous tail stable version that can provide us with
a constant Computing environment throughout the software
delivery life cycle and can automatically
scale up and scale down depending upon the traffic. So we need some kind
of an IT Automation and or you can say
we need configuration management and deployment tools
for it automation. But before we go ahead we
should first understand a very important concept called
infrastructure as code. So what is infrastructure
as code infrastructure as code simply means that you’re writing code
for your infrastructure? So you have provisioning your environment by writing
code rather than manual process or you can even term it
as programmable infrastructure as you can see from the slide that there is
one central location where code for the
infrastructure is present and it is being pushed onto
three different environments that is Dev test and product. Now, let us understand
infrastructure as code with an example suppose. You need to install
Apache Tomcat on five vm’s. So what you’ll do in one central location or in
one Central server, you’ll write the code
to install Apache tomcat and we’ll push that code
onto the five nodes. So what advantage
we get from here. What is the advantage
of doing that first of all, you don’t need to manually go and install in each
VM Apache Tomcat. You just need to write the configuration in one central
location and replicate that on the nodes. Apart from that you have
an accurate historical record of the system state. So whenever you have a so even if you have updated a software
that is not working fine. You can always roll back
to the previous table version. So I want I want an answer
from you all guys. Is there any other advantage that you can think
of infrastructure as code apart from the ones
which I told you? So Janice says that it increases
the release frequency. Definitely it does because you can provision
your environment within minutes or seconds which earlier
used to take probably hours or days or weeks. So definitely John is
this is one major advantage. Is there any other advantage
that you guys can think of? Okay, we have
a question from Quinn. He’s asking how infrastructure
is cord is addressing the previous problems that we discussed very
nice question Quinn. So if you can remember
the third problem where we discussed
application failure, so what happened there
there was a software which was updated and there were
certain glitches over there. So we they needed to roll back
to the previous table version but infrastructure
as code you have an accurate historical record of your system State president
one centralized location. So there is no problem in rolling back to the previous
version of the software if you have updated
with a flawed version Now let us recall the second problem
that we discussed that is the difference
in the Computing environment between testing and
production over there. If we apply
infrastructure as code and write the configurations that will provide
the same environment exactly the same environment
in the three different teams. Then that problem will easily
be solved those three teams can be Dev test and product. If you can recall
the second problem that we discussed
migrating from test to production over there. If we use
infrastructure as code. I’m provide the same Computing
environment in the two teams that is test and production. Then that problem
will easily be solved. So if we can recall
the first problem that was mass deployment over there if you have
infrastructure as code, so you just need to write
the specifications or you just need to specify the IP address
or the host name of the knows that you want to configure. So if you want to configure 50 notes today
and suppose tomorrow, you might not might need
to configure 500 notes. So you just need to specify
the IP address or the host name of the of the knows that you want to configure
in that Central. Nation, and that’s it. That’s that’s that’s it. That’s all you have to do. I hope this answers
your question Quinn. Thank you. Thank you for your reply. So we have one more question. That is from Rahul. He’s asking due to this
continuous read write operation. Will there be
data inconsistency? Absolutely. No Rahul. What happens is there is no read and write operation
either this push mechanism or pull mechanism
and pull mechanism. The nodes will actually
pull the configurations from the central location
or the central server or in push mechanism. The server will actually
push the configurations on to the nodes. So there is no read
and write concept over here. So any more questions guys, if you all are clear
with infrastructure as code, I’ll move forward. So let us move forward
and compare shell script with the configuration
management tools Crypt. There are three key Matrix
on which we will compare the shell script and cm2 script
first in shell script. You need to write the automation
scripts from scratch. But when we talk
about cm2 script 80% of things are already present
second of all in shell script, you need to Define workflows, but in cm to script
the workflows are already there for example in Chef we have run list similarly
for other tools as well. The third difference is that shell script
does not have a user interface where a cm2 script provides you
with a user interface. So any questions guys, just write it down
in your chat box. All right. So you have
understood the concept of infrastructure as code. Kindly give me a confirmation. Bennett says yes so dusk
when Rahul are open cool great. So now let us move forward with the most awaited topic
of today’s session. That is the comparison between puppet saltstack
ansible and chef but first let us have
a look at the Matrix or the factors on which we
will compare these tools. So the first Factor
will be scalability after that comes ease of setup
then availability Management on interoperability. So let us compare the tools
on the basis of scalability. All the four tools
are highly scalable. What does that mean suppose if you need to configure
around 50 notes today and tomorrow might be
a big day in your company and you need to configure
around 500 notes. Not a problem. When you have tools
like puppet chef ansible and saltstack you just need to specify the IP address
or the host name of the notes that you want to configure
in that central location. And rest of the task
will be handled by these tools. Let me tell you that these tools can handle
large infrastructure. It can be workstations
or any sort of infrastructure. So I hope I’m clear guys. Is there any doubt? So should I move forward just just give me
a confirmation guys? Thank you Bennet. All right. All right. Thank you Janice and let us move
forward and compare the tools on the basis of ease
of setup over here. I’ll add my personal
experience guys because when I was installing puppet chef and salts that I faced
quite a lot of issues, but when I
was installing answer, but it was just like a cakewalk. Let us focus on each tool one by one first is pop it pop it
has a master agent architecture. So in that puppet server, you need to install
the puppet master and in the clients, you need
to install puppet agent. After that you need to there is
a certificate signing between the agent and the master when we talk about Chef it also
has a master agent architecture and the master you need
to install Chef server and the agent you need
to install Chef client, but the major difference
between puppet and Chef is that Chef has an extra
component called workstation this workstation is
actually a machine that contains all
the configurations and these configurations
are tested on the workstation and then it is pushed
onto the central chefs over. Same goes for salt
stock as well here. The server is called as salt master and the clients
are termed as salt minions, but when we talk about ansible, I’ll tell you what you have to do to set up
ansible just install ansible on your master machine or your control machine and do an SSH connection
with the nodes. You want to configure. That’s it guys. That’s all you have
to do to set up ansible. I know it’s very very easy
and I myself have done it so I can I can tell you that it is the easiest tool
to install among the four. So are we clear here guys? Any any questions any doubt? All right, so no doubt. So let us move forward
and compare the tools and the basis of availability. All the tools are
highly available. Basically, what does that mean that there are multiple Masters
or multiple servers or multiple instances
that can be present. So if your main master
or main server goes down, there’s always a backup server
or the different machine or a different Master
to take its place. Let us have a look
at each tool one by one puppet has
a multi master architecture. That means there are
multiple Masters. So if your master
main Master goes down, then there is a definitely
a backup master who can take its place
in shape also the same case if your primary Chef
server goes down, then you always have secondary. Then you always have
a backup server to take its place same goes
for Saul stock as well. It has multiple Masters
to configure salt minions and when we talk about ansible, it has primary instance if it goes down then there’s
always a second instance to take its place. I hope I’m clear guys. It was a pretty easy concept, but still if you have
any doubts you are free to ask. Me so I’ll move forward and compare the tools
on the basis of management. So I would like
to add this thing that before I explain you. I’ll tell you pop it and Chef follows the pull
configuration and ansible and source that follows
the push configuration. All right. So we have
a question from arpan. He’s asking what is pull
and what is push configuration? Can you explain with an example? Sure, I can say you need to configure around 50 nodes
and there is one Central server. So what happens it puts configuration
all the configurations that are present in the central
server will be pushed by that server onto the nodes. All right. So there are certain commands that you need to execute
on that server in order to push those configurations
on the nodes. But when we talk about pole configurations
the notes constantly pose the central server
for configurations and it will automatically pull the configurations
from the server. You don’t need to execute any
command on the central server. So I hope you guys are clear
with the concept of push and pull configurations. Thank you. I’d wait for the confirmation. So pop it follows
pull configuration soda chef, but when we talk
about an surveillance or stack both of them follows
push configuration now pop, it is not easy to learn because it uses
its own language called puppet domain-specific language. And since it is a new language,
so it is tough to understand. It is quite system
administrator oriented. Now when we talk
about salt stock and ansible, both of them uses Yaman, which is basically
a common common English that we use in day to day life. For example, if I want to install some things
I’ll just try it installed and the name of the package
or the name of the software that I want to install. I hope I’m clear
any doubts guys. Any doubts, so if you actually
just give me a confirmation. Thank you. Thank you for
your confirmation guys. Let’s move forward
and compare the tools in the basis of interoperability
interoperability. All the four tools their main
master or their main server or their control machine
has to be online x / Unix but their slaves are
the nodes that they have to configure can be on Windows. Let us have a look
at each tool one by one for puppet puppet master
Works only on Linux or Unix but puppet agent
also works on Windows for Chef the chef server
works on Linux or Unix but the chef client and workstation can be
on Windows as well as Linux or Unix same goes for salts dark as well salt Master
can work on Linux or Unix and the salt minions can work
on Windows as well. And when we talk about ansible
the ansible control machine or the ansible server has to be
online X or Unix and the knows that it is configuring can be
on Windows as well. So any questions still
here guys any questions? Okay. So Janice has a question. She’s asking why always a master
or the server is on Linux or Unix Jan is there is
no proper explanation about this anywhere present but still I’ll add my experience and I’ll try
to answer this first is the security
that is the Linux or Unix is more secure
when compared to Windows. Second is line X is faster than Windows and third
can be it is open source. So I hope this answers
your question Janice. Thank you. Thank you for the confirmation. So I’ll move forward and I’ll show you
the final score card that I have prepared. So this scorecard I
have prepared with my experience and my observation and I’ve given equal weight age
to all the parameters that is scalability
setup availability management and interoperability. You can give the weight age
to these parameters the way you want. All right. So Raul is asking us according to your scorecard
ansible scores nine. Is it the best tool Rahul there’s nothing like best tool. I am providing you with factors
in Matrix to compare the tools. So there are all the tools have
their own pros and cons. So it depends totally on your organization’s need and
your organization’s environment what which tool will fit
in your organization that you are the best judge. So this is my observation and my experience that I’ve put
in to create the scorecard. I hope this
answers your question. All right. So have a look at the scorecard
when we talk about scalability pop it as All Star chef
and ansible all are scalable. So I’ve given them nine
but when we talk about set up a puppet Source tagging Chef
are not that easy to set up when compared to ants build
so ansible scores nine rest of the tools scores eight
and we talked about availability all the four tools
have multi master or multi server
architecture in which when the bait server goes down is always a backup server
to take its place. So all the tools scores nine over here and we talk
about management puppet and Chef a little
tough to understand when compared to solid stock
and ansible so salt stock and ansible scores
nine and puppet and shift scores eight interoperability. So as we have seen that all the four tools
their main master or server is present online x / Unix and their slaves
or notes can be on windows. So all of them scores
nine over so final score for puppet is 8.6 saltstack
is 8.8 Chef is 8.6 and ansible is 9.0. So I There any questions guys? No, so let us move
forward and see some of the more factors. So let us move forward
and we’ll see some more factors or more Matrix on which we
can compare these tools. So first is configuration
language second is GitHub activity then comes
into price cost popularity and success story. So let’s compare
the two the basis of configuration language. So as I’ve told you
earlier as well pop, it uses its own Papa
domain-specific language, which is not very
easy to understand and it is kind of system
administrator oriented language and we talk about Chef it uses
Ruby domain-specific language. So if you’re working with Chef, you need to have some kind
of Ruby knowledge in order to work with it when we come to ansible
and salt stack the uses yamen and trust me guys, and I say this it is very easy. It is just like common English as I’ve told you earlier the way
you communicate with people in your day-to-day life it is that simple suppose
if I’m installing engineering so I’ll just
write install nginx. So should we move forward? Are there any questions
from your side to side in your chat box? All right, so we’ll move forward and compare the tools
on the base of GitHub activity. So there are certain starts pop. It has 355 contributors
19,500 95 commits nine branches and 291 releases saltstack has
1041 contributors 49,000 193 commit 11 branches
and 82 releases when we talk about Chef
it has 369 contributors. 12,000. 89 come its branches are 177 and
231 releases for ansible. There are one thousand and three
contributors 13,500 27 commits 33 branches
and 57 releases. Okay. So Quinn is asking why
saltstack has 49,000 193 km, it’s more than any other tool. There are multiple
reasons for it. The two major reasons that
I can think of is they have a huge active community that is contributing
to saltstack apart from that there might be
many revisions are many changes done in that tool. So these are the two major
reasons reasons that I can think of for the amount of comments that you are seeing on
your screen that is 49,000 193, which is more
than any other tool. So any other doubts
or should we move forward? All right, fine guys
will move forward and compare the tools
on the basis of Enterprise cost. So Enterprise cost
four hundred nodes per year is as follows for puppet. It is $12,000 for saltstack. It is $15,000 for Chef. It is $7,200. And for ansible it is $10,000. Now, let us move forward and compare the tools
on the basis of popularity. This is the Google Trend graph
for past five years. Let me tell you guys that puppet and Chef are the old players
they are very mature and well stablished tools. Most of the industries across the globe recognize
both of these tools, but when we talk
about salts tagging ansible, they are new to the market
and as you can see that the green line
of ansible is trending it is growing day by day probably
because of ease of setup and easy to use these
are the two major reasons why ansible is becoming
so popular nowadays many giants like NASA are using ansible to provision
their environment on cloud. So let us move forward and compare the tools
in the basis of success stories. New York Stock Exchange
intercontinentalexchange is using puppet. They have increased from
three hundred servers per admin to 700 service per admin and today our provisioning
their Dev environment which used to take one or two
days in just 21 minutes. So isn’t that great. So they’re provisioning
their Dev environment with the help of puppet, which only used to take
one or two days. But with the help of Puppeteer
is just taking 21 minutes that is amazing. When we talk about salts dark LinkedIn is using
saltstack an earlier. They were using 5,000 salt
minions around for years ago. And now they’re using
70,000 salt minions. So Chef is a Gannett
is using chef and earlier 30% of garage technology
organization were using chef. But this year they have
converted that 30% 200 potion. Isn’t that amazing guys? When we talk about ansible fat map
is using ansible and they say that with the help of ansible. They are able to cut
down certain processes which used to take
17 hours to 3 minutes. That’s amazing. Any doubt still here guys any
doubts any queries destroy down? Cool, our grade
will move forward. So by now you must have selected
the tool on the basis of the or the basis
of your organization’s need and your
organization’s environment. I’m not saying that any of the tool is better
than the other tool. I have given you with factors
or Matrix that you can compare. The tools on the final
decision is yours. All the tools have
their own pros and cons. So with this I
will end the session and the today’s session. If you have
any questions or queries, just write it on the chat box, and I’ll be happy to help
you this recording will be available in your LMS so you can watch it and if you have any doubts
after watching this recording, you can connect
with our support team. We have a 24/7 support team that will be helping you out
with your queries, or you can bring your questions
in the next class. And kindly give us
your important feedback. This will help us to improve
the quality of Education that we provide. Thank you and have a great day. I hope you enjoyed
listening to this video. Please be kind enough to like it and you can comment any
of your doubts and queries and we will reply to them at the earliest do look out
for more videos in a playlist And subscribe to our Edureka channel to learn more. Happy learning.

74 thoughts on “Chef vs Puppet vs Ansible vs SaltStack | Configuration Management Tools Comparison | Edureka”

  1. Thanks a lot for publishing this overview. Although very interesting I do miss some information so hope you can elaborate on:
    Scalability: what if servers need to be deployed in datacenters across the world. Are there any differences between the tools? Is there a central master pushing packages to decentral servers?
    Management: Within this presentation the main focus is on the programming language. What about versioning of code, creating independent modules etc?

  2. Thanks mate, it was really helpful.
    can you please give a guide on How to install and use Ansible in Ubuntu network. Thank you.

  3. [11:18] If I understand correctly, the shell script example using passwords is meant to show an obsolete approach as most have gone to using SSH certificates. Right?

  4. is there is any limitation for all 4 software's regarding the max number of nodes each software can manage with only one master server ????

  5. my organization works on Ruby on rails application,so it better to go with Chef because is based on ruby, or ansible it good choose for me

  6. Scalability is not same for all 4, puppet + chef are less scalable than salt, ansible

    salt is most scalable by far, ansible is scalable by SSH thread limitation, puppet needs adidtional worker masters to crunch over 700 nodes

  7. Great overview and comparison. I'd just offer one correction in that Saltstack can push, pull or run masterless. We generally push but Consul and Consul-Template running on the minions regularly initiates pulls on-demand. Cheers

  8. Informative video thanks. I feel I should point out that the answer given to the question as to "why do all masters have to run on Linux/UNIX" is…. highly subjective, and should probably qualified. A more usable explanation is that a) they were developed there first, and this is because the model for basic server-client interaction is minimal (SSH to a shell, run commands – in Windows, the base model would at least need a custom agent for even the first designs, increasing the cost of development), b) the presence of package management accessible programmatically, coupled with the prevalence of UNIX-style servers on the web, drove that target first, further compounded with the remote-connectivity ease and c) (probably because) it's cheaper to deploy large clusters of Unix machines, and so more pressing to automate that which spreads faster. My 2c 🙂

  9. Thank you so much for the video. It's really nice and very useful. Can you provide me the ppt which you have used in the video ?

  10. Hello Sir,
    Do you teach courses, in class room. I've some students, who is interested in following theses courses. Please let me know if you have some time to schedule, to teach these courses.
    I'm in Toronto, my Phone # 4168358852, you could call me when you have some time or give me your contact details, I could call you.

  11. hey
    awesome lecture..
    just want to know.. should one know all of the configuration management tools or should gain expertise in one.. ?

  12. The content was good. Only thing was the sound quality. It would be nice to improve a bit on the sound quality, if not, doesn't make much difference.
    thanks! 🙂

  13. Presentation is good, but what this discusson like "Any dounts guys. thank you.. thank you.. give confirmation" kind of comments during the presentation. Please take out them then re upload presentation.

  14. I am interested in learning CM, and this provided a comprehensive and fair review of these 4 popular CM tools. I also appreciate the concise overviews of DevOps lifecycle and tools. Subscribed.

  15. Wow. What an amazing video…. You taught us lot of important topics about 4 different tools in just 26 minutes. One of the best videos i watched on this topic till now. Thanks for publishing this excellent video.

  16. very crisp, well-put and entertaining lecture – thanks Sorum(?) for the great and enlightening performance dude!

  17. Got a question on the topic? Please share it in the comment section below and our experts will answer it for you. For Edureka DevOps Training and Certification curriculum, Visit our Website: Use code "YOUTUBE20" to get Flat 20% off on this training.

  18. Great Job!!! I have Bird's Eye view on what are Config Management Tools are.. Thanks alot.. Keep it up…

  19. Thank you for easy explaining bcz i'm also confused between this tool now I'm clear of seeing this tutorial…than you so much

  20. Thank you very much for this wonderful video!!! could you please make a video where you compare Jenkins with other tools also.

  21. I work at a company that in 2 years grew very rapidly. 2 years later we are still working hard on implementing DevOps in the old projects. Compared to new projects that implement DevOps deployment is such a drag on the old projects, especially when errors occure on customer installations. In some of these old projects it's simply not even feasible to even implement DevOps.
    Soooo… listen to this guy! You willl hear about "scaling", "devops", and at the time other unfamiliar buzzwords during school. Try to practice devops consistently, and spend time playing with these tools asap. No fancy algorithms or math skills will save your sorry ass in the real world 🙂
    @edureka, good presentation.

Leave a Reply

Your email address will not be published. Required fields are marked *