Puppet Architecture

Hello Readers!!

Hope you all know what is Puppet and where it is used, if not don’t worry go through Puppet–An object or a software posted in POC Farm.
In this blog I’m going to talk about the Architecture of Puppet.

Puppet has been built with two modes in mind: An agent/master mode with a central server and agents running on separate hosts, or a server less mode where a single process does all of the work. To ensure consistency between these modes, Puppet has always had network transparency internally, so that the two modes used the same code paths whether they went over the network or not.

Terminology

 Catalog

A catalog is a document that describes the desired system state for one specific computer. It lists all of the resources that need to be managed, as well as any dependencies between those resources.

Puppet Apply

It is an application that compiles and manages configurations on nodes.

The Agent/Master Architecture

Puppet usually runs in an agent/master architecture, where a Puppet master server controls important configuration info and managed agent nodes request only their own configuration catalogs.

Agent

In this architecture, managed nodes run the Puppet agent application, usually as a background service. One or more servers run the Puppet master application, usually in the form of Puppet Server.
Periodically, Puppet agent will send facts to the Puppet master and request a catalog. The master will compile and return that node’s catalog, using several sources of information it has access to.
Once it receives a catalog, Puppet agent will apply it by checking each resource the catalog describes. If it finds any resources that are not in their desired state, it will make any changes necessary to correct them. (Or, in no-op mode, it will report on what changes would have been needed.)After applying the catalog, the agent will submit a report to the Puppet master.
Thus, the agent has access to its own system information, its configuration, and each report it generates. The server has copies of all of this data, plus access to all of the Puppet modules, and any back-end databases and services that might be needed to compile the configuration.

Puppet Agent/Master Communication

Puppet agent nodes and Puppet masters communicate via HTTPS with client-verification. The Puppet master provides an HTTP interface, with various endpoints available. When requesting or submitting anything to the master, the agent will make an HTTPS request to one of those endpoints.
In Client-verified HTTPS each master or agent must have an identifying SSL certificate, and will examine their counterpart’s certificate to decide whether to allow an exchange of information.
Puppet includes a built-in certificate authority (CA) for managing certificates. Agents can automatically request certificates via the master’s HTTP API, users can use the puppet cert command to inspect requests and sign new certificates, and agents can then download the signed certificates.

The Stand-Alone Architecture

Puppet can run in a stand-alone architecture, where each managed server has its own complete copy of your configuration info and compiles its own catalog.

In this architecture, managed nodes run the Puppet apply application, usually as a scheduled task or cron job. Like the Puppet master application, Puppet apply needs access to several sources of configuration data, which it uses to compile a catalog for the node it is managing.
After Puppet apply compiles the catalog, it immediately applies it by checking each resource the catalog describes. If it finds any resources that are not in their desired state, it will make any changes necessary to correct them. (Or, in no-op mode, it will report on what changes would have been needed.)
After applying the catalog, Puppet apply will store a report on disk. It can also be configured to send reports to a central service.
Unlike Puppet agent, Puppet apply never runs as a daemon or service. It always runs as a single task in the foreground, which compiles a catalog, applies it, files a report, and exits.

Standalone architecture

Conclusion

Puppet automates every step of the software delivery process, from provisioning of physical and virtual machines to orchestration and reporting; from early-stage code development through testing, production release and updates.

Puppet usually uses Agent/Master architecture. The master is connected to several nodes and communicates via client certification. The puppet master has copies of all the data and can access all puppet modules. It also has back-end databases and services that might be needed to compile the configuration.

Thank you for Reading.  

Keep Learning!!!!

 

References

https://docs.puppet.com/puppet/4.4/reference/architecture.html

http://www.aosabook.org/en/puppet.html

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s