Puppet configuration management tool. Its purpose is to automate the process of configuring and maintaining computer systems. It achieves this by defining the desired state of a system and ensuring that the system remains in that state.
Puppet is agent-based.
Puppet uses a client-server architecture just like many other legitimate remote host management tools commonly used by DevOps engineers. Here are some additional examples:

Chef: Another popular open-source configuration management tool, Chef also utilizes a client-server architecture. It uses Ruby DSL for defining configurations, offering flexibility and customization.
SaltStack: This open-source configuration management tool uses a unique "minion-master" architecture. Unlike Puppet and Chef, SaltStack doesn't require an agent on the managed nodes. Instead, the master server pushes configuration information to the minions (managed nodes) and executes commands remotely.
AWS Systems Manager (SSM): A managed service by Amazon Web Services, SSM allows managing resources across your AWS infrastructure. It uses a client-server model where the SSM Agent installed on EC2 instances communicates with the SSM service to receive commands, configuration data, and perform actions.
Azure Automation: Similar to AWS SSM, Microsoft Azure Automation provides a service for managing resources in your Azure cloud environment. It uses a client-server model with an agent deployed on Azure VMs for remote configuration and execution.
Each tool offers its own strengths and weaknesses, and some DevOps engineers might utilize a combination of tools depending on the specific needs of their project.

As separate tool i would highlight the ** Ansible*: Ansible is indeed different from Puppet and Chef in its approach to **agentless* configuration management.
Ansible: Ansible takes a different approach. It leverages SSH for communication, eliminating the need for a pre-installed agent on managed nodes. Ansible "pushes" small programs called modules to the managed nodes, executes them, and then removes them. This agentless approach makes Ansible lightweight and easier to adopt in environments where installing agents might be challenging.

Here are some of the things that a DevOps engineer should know about Puppet:

Puppet is a declarative configuration management tool. This means that you define the desired state of a system, and Puppet takes care of making sure that the system is in that state.
Puppet uses a domain-specific language (DSL) to define configurations. This DSL is easy to learn and read, and it makes it easy to manage complex configurations.
Puppet is agent-based. This means that there is a Puppet agent installed on each node that you want to manage. The Puppet agent communicates with a Puppet master, which stores the configuration data.
Puppet is open source and free to use.

Sample task - get the desired state on the controlled Debian/Ubuntu machine.

Desired state - get the Node.js and Nginx been installed on the target.
On the Control Machine (Puppet Master):

Install Puppet Server:

Official Packages: Add the Puppet Laboratories repository and install the server package:

curl -sSL https://apt.puppetlabs.com/puppet-release-bionic.deb -o puppet-release-bionic.deb
sudo dpkg -i puppet-release-bionic.deb
sudo apt-get update
sudo apt-get install puppetserver

Package Manager: You might find Puppet server in your distribution's repositories (not recommended for production due to potential version lags). Use your package manager (e.g., apt-get install puppetserver for Debian/Ubuntu).

Configure Puppet Server:

Edit the /etc/puppet/puppet.conf file and configure server settings like port number, certificate management, etc. Refer to the official documentation for details: https://help.puppet.com/

Create a Node Class:

Create a file (e.g., nodes.pp) in the Puppet modules directory (usually /etc/puppet/manifests/site).
Define a class named nodejs_nginx that includes the required resources for Node.js and Nginx.

class nodejs_nginx {
  # Include required modules (assuming they are installed)
  include nodejs
  include nginx

  # Define resources for Node.js
  nodejs::package { 'nodejs' : ensure => installed }

  # Define resources for Nginx
  nginx::package { 'nginx' : ensure => installed }

  # Additional configuration for Nginx (replace with your desired configuration)
  nginx::resource { 'my_website' :
    location => '/',
    root => '/var/www/html/my_website',
    index => ['index.html index.htm'],
  }
}

Replace my_website with your actual website configuration details.

Assign the Node Class:

Edit the /etc/puppet/manifests/nodes.pp file.
Add a line defining a node (your Debian/Ubuntu machine) and assigning the nodejs_nginx class.

node 'your_debian_hostname' {
  class { 'nodejs_nginx' }
}

Replace your_debian_hostname with the actual hostname of your Debian/Ubuntu machine.

On the Client Machine (Debian/Ubuntu):

Install Puppet Agent:

wget https://downloads.puppetlabs.com/debian/puppetlabs-release-puppet6.gpg
sudo apt-key add puppetlabs-release-puppet6.gpg
sudo apt update

After adding the repository, install the Puppet Agent using the following command:

sudo apt install puppet-agent

Start and enable Puppet Agent service: Once installed, start the Puppet Agent service and enable it to start automatically at boot time

sudo systemctl start puppet
sudo systemctl enable puppet

Configure Puppet Agent: By default, Puppet Agent will attempt to connect to the Puppet Master using the default settings (puppetmaster:8140). If your Puppet Master is configured with a different hostname or port, you need to edit the Puppet Agent configuration file (/etc/puppetlabs/puppet/puppet.conf) to specify the correct settings. For example:

[main]
server = your_puppetmaster_hostname

Save the file and restart the Puppet Agent service for the changes to take effect:

sudo systemctl restart puppet

Start the Puppet Services:

On the Control Machine (on Server):

sudo systemctl start puppetserver

On the Client Machine:

sudo puppet agent --test

This will test the Puppet configuration without applying changes. If successful, run:

sudo puppet agent -t

This will apply the desired state (installing Node.js and Nginx) to your client machine.

Notes:

Puppet Modules: This example assumes you have the nodejs and nginx Puppet modules installed on the Puppet Master. You can find these modules on the Puppet Forge (https://forge.puppetlabs.com/).

By following these steps, you'll have a basic Puppet setup managing Node.js and Nginx installation and configuration on your Debian/Ubuntu machine. You can further customize the Puppet code to manage additional configurations for your specific needs.

Puppet uses a domain-specific language (DSL) to define configurations, allowing administrators to understand what changes are being made to their systems.

Puppet, while primarily focused on configuration management, can also be used for deployment to a certain extent. Here's a breakdown of how Puppet handles deployments:

Configuration Management vs. Deployment:

Configuration Management: Puppet ensures that your infrastructure and applications are in the desired state. It defines configurations for operating systems, software packages, and services, and makes sure they are installed, configured, and running as specified.
Deployment: Deployment involves the process of delivering new versions of software applications to your infrastructure. This often includes activities like copying application code, setting up environment variables, restarting services, and potentially rolling back deployments in case of issues.
Puppet and Deployment:

Indirect Deployment: Puppet itself doesn't directly handle all aspects of deployment like package management tools might. However, by managing the configuration of software packages and their dependencies, Puppet indirectly facilitates deployments.
Defining Node States: You can create Puppet classes like your nodejs_nginx example. This class can define the resources (packages, services, configuration files) needed for Node.js and Nginx. When applied to nodes, Puppet ensures these resources are installed and configured as defined in your class.
Module Capabilities: Some Puppet modules, especially those for specific applications, might include additional functionalities beyond configuration management. They might automate tasks like downloading application code, setting up environment variables, or restarting services, effectively contributing to the deployment process. However, this behavior depends on the specific module and how it's designed.
In essence:

Puppet excels at configuration management and indirectly facilitates deployments by ensuring the necessary software and configurations are in place.
Some Puppet modules might offer deployment automation features, but this functionality varies depending on the module.
Alternative Deployment Tools:

For comprehensive deployment orchestration, tools like Ansible, Chef, or dedicated CI/CD pipelines (e.g., Jenkins pipelines) are often used alongside Puppet for configuration management. These tools handle the complete deployment lifecycle, including tasks like managing application code, environment variables, and service restarts.

Here's an analogy:

Think of Puppet like a master architect who creates detailed blueprints (configurations) for your infrastructure.
Deployment tools are like construction crews that use those blueprints to actually build and deploy the infrastructure based on those specifications.
While Puppet creates the blueprint, it might not directly handle all aspects of the construction (deployment) itself. Often, additional tools are needed to complete the deployment process.