Chef For Absolute Beginners
Chef For Absolute Beginners
Chef For Absolute Beginners
https://www.plutora.com/blog/configuration-management
What is chef?
https://www.edureka.co/blog/what-is-chef/
Servers spans across public and private cloud and virtual or local datacentre
environment using Puppet. With Puppet, you can provision VMs or instances on
public clouds like Amazon, Azure or GCP or private clouds like Open stack or
VMware. Ones provisioned, you can extend puppet functionality to deploy, configure
and orchestrate various applications on newly provisioned instances. Setup
networking configurations to enable communication between different public and
private clouds. There are a lot of built-in resource types available and puppet that
supports these kinds of operations.
This host is primarily responsible for maintaining configurations in the form of puppet
codes. The agents are the target machines managed by puppet with the puppet agent
software installed on them. These could be all of the different servers in our environment
that we wish to manage using Puppet. The agent nodes check in regularly after every
1800 seconds with the master node to see if anything needs to be updated in the agent.
Note that 1800 seconds is the default check in time for puppet agents.
If anything needs to be updated the agent pulls the necessary puppet codes from the
master and performs required actions. This is known as a pull based mechanism. As in
this case the agent is pulling for updates and pulling codes from the master node as
opposed to master pushing the codes to the agent's servers as seen in tools like Ansible
and Salt.
Remember the master node can only be Linux. You cannot have Windows OS as your
master node in Puppet. However, the agent can be configured on any supported OS
flavours such as Linux or Windows or Solaris or Mac OS. The other Puppet deployment
model is a puppet self-contained server which acts as both a master and agent on a
single host. The master-agent deployment model is used for production use case,
whereas the standalone mode is used for development test or proof of concept
purposes.
There are two deployment models for configuration management tools pull based and
push based. In a push based deployment model a master server pushes the
configurations and software’s to the individual servers. After verifying the inventory and
then establishing the secure connection the master runs commands remotely on the
client's, configuration push is initiated by master node. Some examples of such tools are
Ansible and Salt stack.
However, in a Pull based deployment model the individual servers contact a master
server, establish a connection after verifying the inventory specified in the master,
download their configurations and software’s and then configure themselves
accordingly. Configuration pull is initiated by agents at regular intervals Puppet and Chef
are the best examples of pull based models. Both of these models are well accepted in
the industry. They both have their own advantages and disadvantages that you should
consider while making a decision about the tool you want to use.
Puppet Master is a node having puppet master software installed and configured. This
machine is responsible for puppet code management and contains different
configurations in the environment. An administrator logs into the puppet master to create
or change puppet codes. We have multiple agents in our setup with the puppet agent
software installed on them. The communication between master and agent is
established through secure certificates. We will learn about puppet certification
management later in this course. The Puppet Master will allow a secure connection with
an agent on port 8140. Make sure to open port 8140 on your puppet master. The
communication between the master in the agent's server is a three step process.
Once the connectivity is established between the agent and the master the agent sends
the data about its state to the puppet master server. These are called Facts. This
information includes hostname, kernel details, IP address, file name details etc. Puppet
uses the Facts and compiles a list with the configuration to be applied to the agent. This
list of configuration to be performed on an agent is known as a catalog. This could be
changes such as package installation, upgrades or removals, File System creation, user
creation or deletion, server reboot, IP configuration changes, etc. The agent uses the
catalog to apply required configuration changes on the nodes if any. In case there are no
drifts in the configuration,
Agent does not perform any configuration changes and leaves the server to run with the
same configuration after receiving the catalog from the puppet master puppet agent
responds immediately to the changes by executing the configuration draft's.
Once done the node reports back to puppet master indicating that the configuration has
been applied and completed. Puppet provides the flexibility to integrate these reports
with third party tools using Puppet APIs. But that is something advanced and we will
cover that in an advanced course. The Puppet documentation is available at
puppet.com/docs.
FQDN: Fully Qualified Domain Name
Puppet master server must allow incoming connections on port 8140. An agent node
should be able to connect to the master via this port. Both Puppet master and agent
should have the correct time set up on them.
Any time difference could cause serious issues. We suggest using NTP for Puppet
environment.
Puppet Master is the server where we install the Puppet master software. On this server,
We use Puppet resources, Classes, Manifests, Modules Profiles, Roles, etc. to create
puppet codes.
Well it follows the basic installation mechanisms in operating systems such as
using package managers like yum or apt get etc...