This is our second post in our “Introduction to Puppet tutorial” We already covered “What is a puppet” and other ad-hoc posts on Puppet earlier. In this post, we will try to understand basic terminology used in Puppet which will help us understand Puppet
This is our Puppet server which takes care of puppet clients which connect to it. It serves required data to clients and gets reports from clients once our configurations are done on them. This acts as a centralized machine for all your Puppet activity by default.
Puppet configuration management tool can be deployed in two ways. One is Client-server model and the other is an independent node model or a masterless setup. Depends on your requirement we can use one of these models. Many people may have a question how is it possible to configure Masterless-puppet. For those people, “puppet apply /path/to/my/site.pp” command is the answer. We can apply puppet catalogs if we have puppet manifests locally available using puppet apply command. We will see more about this command in future.
Running state of Puppet server is called as puppetmasterd
Running state of Puppet client software. This software is useful for
1) Gathering facts: Getting vast system details like OS type, version, RAM details, CPU details and much more using installed facter tool.
2) Send those details to master for getting required compiled configuration details(catalogs)
3) Getting compiled configuration details from puppet master
4) Executing those compiled configurations at a designated time.
5) Collecting and sending reports of this expected configuration on the client.
Puppet clients are called as nodes.
These are files/configs which can be used for changing settings at nodes.
Reporting tool at nodes, which reports about OS/HW/SW types etc to puppet master about the node where it is installed.
Clipped output of facter command:
architecture => amd64 blockdevices => sda,sdb boardmanufacturer => Hewlett-Packard fqdn => linuxnix gid => root hardwareisa => x86_64 hostname => linuxnix id => root interfaces => eth0,lo,virbr0,virbr0_nic,wlan0 ipaddress => 192.168.122.1 kernel => Linux kernelmajversion => 4.4 kernelrelease => 4.4.0-31-generic kernelversion => 4.4.0 memoryfree => 2.41 GB memorysize => 7.58 GB memorysize_mb => 7757.53
Attributes are used to specify the state desired for a given configuration resource. We will see more about this in our coming posts.
A file containing code written in the Puppet DSL language, and named with the .pp file extension. All manifests are stored in /etc/puppet/manifests or /etc/puppet/modules/<name-of-module>/manifests.
Compiled form of manifests.
Modules are a bigger form of manifests. Every manifest in a module should define a single class or defined type.
Physical files you can serve out to your agents through puppet. These are stored in /etc/puppet/files or /etc/puppet/modules/<name-of-module>/files.
Template files contain puppet code with variables which can populate variable values depending on node details.
Collections of resources
Composite collections of resources
Complete list at http://docs.puppetlabs.com/references/glossary.html. In our next post we will see how to install Puppet and configuring it with basic settings in Debian/Redhat based machines.
Latest posts by Surendra Anne (see all)
- Docker: How to copy files to/from docker container - June 30, 2020
- Anisble: ERROR! unexpected parameter type in action:
Fix- June 29, 2020
- FREE: JOIN OUR DEVOPS TELEGRAM GROUPS - August 2, 2019
- Review: Whizlabs Practice Tests for AWS Certified Solutions Architect Professional (CSAP) - August 27, 2018
- How to use ohai/chef-shell to get node attributes - July 19, 2018