Installation and Configuration:
1. Overview of Puppet
Puppet is a declarative, model-driven configuration management tool that facilitates the automation of repetitive tasks associated with system administration. Developed in Ruby and released as an open-source project, Puppet enables IT teams to define the desired state of their infrastructure, ensuring consistency and reducing manual intervention.
Puppet aligns with the Infrastructure as Code (IaC) concept by treating infrastructure configurations as code, enabling administrators to manage and automate the deployment and configuration of their IT infrastructure. Here's how Puppet embodies the IaC concept.
What is Infrastructure as a code?
Infrastructure as Code (IaC) is a methodology that treats infrastructure configurations as code. It involves using scripts or configuration files to automate the provisioning and management of infrastructure elements, such as servers, networks, and storage.
Puppet uses the concept of Infrastructure as a code for managing configuration of devices that are connected to the network. The devices can be in the form of Servers, desktops, virtual machines on cloud or local infra, networking devices like firewall, routers, switches, etc.
In this, the concept of configuration management is the practice of handling changes systematically to maintain system integrity and control. It involves tracking and managing the configurations of software and hardware components in an organized manner.
2. Desired State management
Desired State Management is a configuration management approach aimed at defining and maintaining the desired state of a system. In the context of Puppet, Desired State Management involves declaring the configuration state in form of infrastructure code, that administrators want for their systems, and Puppet then ensures that the actual system configuration aligns with this declared state.
3. Puppet Architecture
Puppet uses the client – server architecture in which we have the infrastructure code (Puppet Code) stored on the Puppet server and all the nodes which we want to manage the configuration of are installed with Agent (client) application. Applying all configurational changes on the targeted nodes, is achieved using the puppet agents. It is the Puppet Agent application that’s running on the targeted node pulls the infrastructure code from the server and applies it on the node.
Puppet Server: The Puppet server is often referred as Puppet Master
Centralized Configuration Management: The Puppet Master server is the central component that manages and distributes configurations to nodes (machines) in the infrastructure.
Catalog Compilation: The Puppet Master compiles a catalog for each node, which contains the desired state specified in Puppet DSL. The catalog represents the configuration that needs to be applied to the node.
Certificate Authority (CA): Puppet uses a certificate-based authentication system. Nodes must request and obtain certificates from the Puppet CA before they can communicate with the Puppet Master.
Puppet Agent:
Node Agents: Puppet Agents run on individual nodes in the infrastructure. They are responsible for requesting configurations from the Puppet Master, applying the configurations locally, and reporting back to the master.
Regular Puppet Runs: Puppet Agents regularly (at set interval) contact the Puppet Master to check for updates and retrieve the latest configurations. This ensures that the nodes are continually enforcing the desired state.
Facter: Facter is a separate tool bundled with Puppet that gathers facts about a node, such as its operating system, IP address, and hardware details. These facts are used in Puppet DSL to make configuration decisions.
4. Catalog Compilation Process
Manifests: Puppet configurations are written in files called manifests. Manifests contain the code written in Puppet DSL that defines the desired state of the system.
Catalog Compilation: When a Puppet Agent contacts the Puppet Master, the master compiles a catalog for that specific node. The catalog is a compiled representation of the manifests and includes all the resources and configurations that need to be applied.
5. Modules
Modular Structure: Puppet configurations are organized into modules. Modules are directories that contain manifests, files, and other related resources needed to configure specific aspects of the infrastructure.
Code Reusability: Modules can be reused across different projects and environments, promoting code reusability and making it easier to manage complex configurations.
6. Key Components
Declarative Language: Puppet uses a declarative language to describe the desired state of a system. Users specify the end state they want, and Puppet handles the details of how to achieve that state.
Manifests: Puppet configurations are defined using manifests, which are written in a Puppet-specific language. Manifests describe the desired system state, specifying the resources and relationships between them.
Facts: Puppet gathers information about the target system through facts, which are key-value pairs containing details such as operating system, hardware, and network configuration. Facts help Puppet dynamically adapt configurations based on the system's characteristics.
Catalogs: Once Puppet compiles manifests and evaluates facts, it generates a catalog representing the desired state of the system. The catalog is then applied to the target nodes to enforce the specified configurations.
Resource Abstraction: Puppet abstracts system resources such as files, packages, and services into "resources." This abstraction allows users to define configurations without worrying about the underlying operating system.
Cross-Platform Support: Puppet supports a wide range of operating systems, including Linux, Unix, and Windows. This makes it a versatile solution for managing heterogeneous IT environments.
Idempotence: Puppet ensures idempotence, meaning that applying the same configuration multiple times yields the same result. This helps prevent unintended changes and ensures consistency in the desired system state.
Reporting and Auditing: Puppet provides reporting tools to track changes and audit configurations. This is crucial for maintaining a clear understanding of the state of the infrastructure and troubleshooting any issues that may arise.
Extensibility: Users can extend Puppet's functionality by developing custom facts, functions, and types. This extensibility allows organizations to tailor Puppet to their specific needs.
Active Community: As an open-source tool, Puppet benefits from a vibrant and active community. Users can access a wealth of documentation, forums, and modules contributed by the community, making it easier to troubleshoot problems and share best practices.
7. Puppet Open source - Installation of Puppet Open-Source tool
System requirements:
There are two components in the puppet ecosystem. The puppet server is fairly resource intensive and must be installed on a robust, dedicated server. The Agent however has few system requirements and thus can run on nearly anything. The Agent can run on variety of operating systems with hardware configuration of 1 core CPU, 0.5 to 1 GB memory. For the Server, resource requirements vary widely bet’n deployments. Number of agents served, how frequent agents checks-in, how many resources are being managed and the complexity of manifests (puppet code). The minimum requirements for the server to be installed should have minimum 4 GB memory, 2 core CPUs. Operating system: Linux, Architecture: ARM64, aarch64, x86_64.
Installation Steps:
Follow online documentation for installation of Puppet server and puppet agent at https://www.puppet.com/success/community/open-source/free-trial.
Or,
Follow below instructions to install puppet server and puppet agent on your machines.
Now, to install Puppet server, use below command, first to install Puppet server and Puppet agent package, we have to install OpenJDK version 11 or later.
For installing Puppet server and agent on enterprise Linux, browse to https://yum.puppetlabs.com/ and select the latest puppet release with related enterprise linux release version number. e.g., ‘el-9’ for ‘Enterprise Linux 9’.
$ yum repolist ## This will generate and display repository listing.
$ yum install puppet7-release-el-9.noarch.rpm
$ yum update
For installing on Ubuntu, browse to https://apt.puppetlabs.com/
Select the correct ubuntu release with latest puppet releases. for ubuntu 22.04,
Once the repository is updated, we can install the package using dpkg package installer.
$ sudo dpkg -i puppet7-release-jammy.deb
$ sudo apt-get update
$ sudo apt-get install puppetserver
Installing Puppet-server will also install Puppet Agent on the server machine. So, we do not need to install Puppet-Agent separately again.
To install Puppet-agent application on agent machine (node machine), use below command on Ubuntu and Enterprise Linux… first follow the apt repository update commands on the node.
On Ubuntu use,
$ sudo apt update
$ sudo apt install -y puppet-agent
On RHEL,
$ sudo yum update
$ sudo yum install puppet-agent
After installation, we can check the status of the server and agent service by running systemctl command.
$ sudo systemctl status puppetserver
$ sudo systemctl puppet
After successful installation of puppetserver and puppet agent, the services are in stopped as default. we have to start the server, but not the Agent.
By default, the Agent service is stopped and we will keep it stopped till we update the agent configuration files (puppet.conf) and server details in local network host file. On the node machine where we only have puppet agent installed, we have to update the /etc/hosts file so that the puppet agent when run will be able to resolve the hostname puppet to the ip address.
To allow the puppet command to run manually, we have to create a sym link to the puppet binaries. The puppet binaries are located at /opt/puppetlabs/bin/puppet
$ sudo ln -s /opt/puppetlabs/bin/puppet /usr/bin/puppet
$ sudo ln -s /opt/puppetlabs/bin/puppetserver /usr/bin/puppetserver
Puppet server and Puppet Agent configuration steps:
Once all steps of Puppet server installation are complete and we confirm the puppet-server service is running, we will have to configure the puppet server with basic configuration.
The server machine is also installed with puppet-agent which is bundled with the server package. The agent configuration file is located at $conf_dir/puppet.conf.
Let's navigate to /etc/puppetlabs/puppet/puppet.conf.
Update the file contents with below text.
[main]
certname = puppetserver01.example.com
server = puppet
runinterval = 1h
strict_variables = true
[server]
dns_alt_names = puppet,puppet.example.com
reports = puppetdb
storeconfigs_backend = puppetdb
storeconfigs = true
As this configuration is updated on the server machine, the same is to be updated on the Agent side well. On the node (Agent) the file contents have to be little different.
[main]
certname = agent01.example.com
server = puppet
runinterval = 1h
The puppet.conf file consists of one or more config sections, each of which can contain multiple number of settings.
The file can also include comment lines at any point.
Puppet uses four config sections that can be defined in the config file.
main is the global section used by all commands and services. It can be overridden by the other sections.
server is used by the primary Puppet server service and the Puppet Server ca command.
agent is used by the Puppet agent service.
user is used by the Puppet apply command, as well as many of the less common Puppet subcommands.
To know more about the options in puppet.conf file, visit the below link,
The puppet.conf file can also be modified using a Puppet command from command line.
$ sudo puppet config set <SETTING NAME> <VALUE> --section <CONFIG SECTION>
Here's an example of using above command,
$ sudo puppet config set reports puppetdb --section server
$ sudo puppet config set ordering manifest
Above command will set a parameter in the puppet.conf file as stated below.
[main]
ordering = manifest
[server]
reports = puppetdb
Once we set the puppet.conf file with required parameters, we can expect the puppet Agent to run as per settings. Make sure the server FQDN are resolved with the DNS entries. As per the set Run Interval we can expect the Puppet Agent to run and connect to the puppetserver by using the Puppet certificate authentication policy.
For the first time we can run the agent manually by using below command,
$ sudo puppet agent -t
Below image explains the series of actions performed after we run the puppet agent command.
Here the Puppet Agent generates a new certificate on the node side and sends the certificate signing request to the server.
On the Puppet server the certificate signing request is received. The same can be checked by using command.
$ sudo puppetserver ca list
The output of above command will show the certificate signing request received. We then, accept / sign the certificate manually or automatically.
We can sign the certificate using below command.
$ sudo puppetserver ca sign --certname <client_hostname>
Once the certificate is signed a copy of it saved on the server and the Agent now a trusted agent and is allowed to read the puppet code on the server using the environment entry point, site.pp or nodes.pp file.
Try running the puppet agent manually one more time using the command,
$ sudo puppet agent –test
The certificate file can be verified on the server at the file location, /etc/puppetlabs/puppet/ssl/certs or, ../ssl/certificate_signed
$ sudo puppetserver ca list -a
Comments