What is Noop in puppet?

Puppet noop mode mode allows us to review the changes that Puppet would do on the system without actually applying them. This is particularly useful when managing critical servers, as it allows to push to production Puppet code and data in a more controlled, safe and manageable way.

The benefits of going without a host

Detailed controls We pride ourselves on our ability to keep our site up to date. By using Puppet without a master, we have tight control over how configuration is applied to the server.
Parallelization With a centralized Puppet server, the server maintains a single canonical version of the Puppet configuration. This causes a conflict when multiple people try to make changes at the same time. Without a master, the version control repository maintains the canonical version, so people can easily work in parallel if they are not trying to use the same server.
No single point of failure Running a Puppet master is another service to maintain and ensure high availability. Having one less service to apply our typical HA rigor is a big win.

Nuts and bolts.

To simplify our wizardless setup, we wrote a little gem called supply_drop . This is a set of capsitrano tasks that allow you to supply servers with Puppet. It tries to be small, simple, and stay out of your way. There are two tasks that do the bulk of the work. capsitrano puppet: noop and capsitrano puppet Noop will show you the set of changes that will be applied. As you might have guessed, the application task makes these changes to the field. supply_drop uses rsync to transfer the current Puppet configuration from your device to the server, which makes it very fast.

We use a setup similar to the multi-step constraint to control the scope of the change. We dynamically create tasks for each server and environment that we have. Here’s an example of what that looks like

def tasks_for_datacenter(datacenter, servers)
task datacenter do
role :server, *servers
end
servers.each do |server|
task server do
role :server, server
end
end
end
tasks_for_datacenter :sandbox, %w(app1.sand db.sand)
tasks_for_datacenter :production, %w(app1.prod app2.prod db.prod)

These tasks allow us to apply changes to a single server or the entire datacenter. We can also use shell extensions to easily make changes to a subset of servers in a given environment. A few examples:

cap app1.prod puppet: noop shows changes to app1
cap the sandbox puppet: apply applies the current changes to the entire sandbox
cap app {1,2} .prod puppet: apply applies changes to app1.prod and app2.prod

Workflow

We are always looking for ways to improve our workflow, but overall we are happy with what we have now. Our goals:

Easily allow multiple people to make changes to the environment
Show clear progression from QA to Sandbox to Production
Keep all changes in source code management without making the logs too noisy

What is puppet agent?

Basic information

Puppet’s operating scheme is client-server, although a serverless version with limited functionality is also supported.

It uses a pull model: by default, once every half hour, clients ask the server for a configuration and apply it. If you work with Ansible, it uses a different, push model: the administrator initiates the process of applying the configuration, clients will not apply anything on their own.

Networking uses two-way TLS encryption: the server and the client have their private keys and corresponding certificates. Usually the server issues certificates to the clients, but in principle it is possible to use an external CA.

Getting to know the manifests

In Puppet terminology, nodes are connected to the Puppet server. The configuration for the nodes is written in manifests in a special programming language, Puppet DSL.

Puppet DSL is a declarative language. It describes the desired state of a node as a declaration of individual resources, for example:

A file exists, and it has certain contents.
The package is installed.
The service is running.

Resources can be interrelated:

There are dependencies; they affect the order in which resources are applied.
For example, “first install the package, then fix the configuration file, then start the service.
There are notifications – if a resource has changed, it sends notifications to the resources subscribed to it.
For example, if a configuration file changes, you can automatically restart the service.

In addition, Puppet DSL has functions and variables, as well as conditional statements and selectors. Various templating mechanisms such as EPP and ERB are also supported.

Puppet is written in Ruby, so many of the constructs and terms are taken from there. Ruby allows you to extend Puppet by adding complex logic, new resource types, and functions.

When Puppet is running, manifests for each specific node on the server are compiled into a directory. The catalog is a list of resources and their relationships after calculating the value of functions, variables, and exposing conditional statements.

Where are puppet agent logs?

/var/log/messages

Agent logs
On *nix nodes, the agent service logs its activity to the syslog service. Your syslog configuration dictates where these messages are saved, but the default location is /var/log/messages on Linux, /var/log/system.

Location of files on the pappetserver

For further explanation I will introduce the concept of “root directory”. The root directory is the directory where the Puppet configuration for a particular node resides.

The root directory varies depending on the version of Puppet and the use of environments. Environments are independent configuration sets that are stored in separate directories. Usually used in conjunction with a git, the environments are then created from git branches. Accordingly, each node is in one or the other environment. This is configured either on the node itself or in the ENC, which I will explain in the next article.

In version 3 (“old Puppet”) the base directory was /etc/puppet. The use of environments is optional – we, for example, do not use them with the old Puppet. If environments are used, they are usually stored in /etc/puppet/environments, the root directory will be the environment directory. If environments are not used, the root directory will be the base directory.
Since version 4 (“new Puppet”) the use of environments became mandatory, and the base directory was moved to /etc/puppetlabs/code. Accordingly, environments are stored in /etc/puppetlabs/code/environments, the root directory is the environment directory.

The root directory must contain a subdirectory manifests, where one or more manifests describing nodes are stored. In addition, there should be a subdirectory modules, which contains the modules. I will explain what modules are a little later. In addition, in the old Pappet there may also be a subdirectory files, which contains various files that we copy to the nodes. In the new Pappet, on the other hand, all the files are placed in modules.

Manifest files have the extension .pp.

A couple of examples

Description of a node and a resource on it

On node server1.testdomain we have to create file /etc/issue with content from Debian GNU/Linux \n \l. The file must belong to the user and group root and must have access rights of 644.

How do I restart puppet agent service?

Note: If you’re using Puppet Enterprise (PE), you can reload the server from the command line by running service pe-puppetserver reload . However if you need to change a setting, do so in console or with Heira, and then the agent will reload the server when it applies the change.

What ports does puppet use?

Ports. By default, Puppet’s HTTPS traffic uses port 8140. The OS and firewall must allow Puppet Server’s JVM process to accept incoming connections on this port. You can change the port in webserver.

What is Puppet master and agent?

The Puppet master is the system that manages important configuration information for all of the nodes that it controls by using manifests. See Puppet Manifests. The nodes that the master controls are those that have Puppet installed on them and are running the Puppet agent, which is a daemon.

What is Puppet node?

A node definition, also known as a node statement, is a block of Puppet code that is included only in matching nodes’ catalogs. This allows you to assign specific configurations to specific nodes. Put node definitions in the main manifest, which can be a single site. pp file, or a directory containing many files.

Where is Puppet Conf located?

$confdir/puppet.conf

The puppet. conf file is always located at $confdir/puppet. conf . Although its location is configurable with the config setting, it can be set only on the command line.

How often does puppet agent run?

every 30 minutes

Puppet automatically attempts to run on each of your nodes every 30 minutes. To trigger a Puppet run outside of the default 30-minute interval, you can manually run Puppet.