In this vast world of orchestration & automation tools and techniques, here is a quick one on how to get a puppet master to install Apache. Lets begin with a refresher on the differences between a Push Configuration vs a Pull Configuration. During a Push Configuration the Central Server pretty much pushes all the configuration details onto the client nodes.

A Pull Configuration works similarly to the push however during the pull configuration the nodes dynamically update themselves with the configurations present in the server.

When we observe other orchestration (automation) tools they typically fall into those two types of configuration scenario. Lets look at them all together and classify the types:

The lifecycle of an update begins from the client node sending normalized data about itself to the Puppet Master Server, known as FACTS, once these facts reach the Puppet Master Server it uses the facts to compile a catalog that specifies how the node should be configured. The client node pulls the update and acts upon the instructions that were included, finally the node reports back to Puppet Master Server indicating the configurations are completed which will be visible in the Puppet Dashboard.

Communication between the Client Node and the Puppet Master is established via a secure socket after a series of certificate exchanges are completed. The important take away here is that the communication between Client and Server are SSL, here is a quick diagram listing the steps from TOP to BOTTOM as to how that secure communication tunnel is established

Another important set of items to understand before we install Apache using Puppet Master is understanding the relationships between Classes and Resources > Manifest > Modules.

Programs are called manifests. Manifest are composed of Puppet Code and their filenames use the .pp extension. Whereas Modules is a collection of manifests and data (such as facts, files and templates), they have a specific directory structure . Modules are useful for organizing the Puppet Code because they allow you to split the code into multiple manifests.

Locate /etc/puppet/modules and create manifests/site.pp

And now with some basics under our belt lets install Apache using Puppet Master Server

class {'apache' : }
    apache :: vhost {'kewrunner.com' :
       port => '80' , 
       docroot => '/var/www/html'
  }
package{'httpd':
   ensure => installed, 
   }
service {'httpd':
    ensure => running, 
}

The manifest lines are self explanatory, try it out and test Apache on the Client Node, another thing to note if the service fails on the client node this could be another high availability solution for web services (outside of Kubernetes or Dockers of course). More specifically when there is a need to ensure a service is running on a particular node.

Try these out and see what they produce

#puppet module install puppetlabs-mysql --version 3.10.0
#puppet module install mayflower-php --version 4.0.1

Create a site.pp file with the following

include '::mysql::server'
include '::php'

On the agent 
#puppet agent -t

Now recheck the versions and observe they are now different

I wish I could use Puppet more often on a daily basis but the truth of the matter is that once you set these modules up there is little else to do beside clean error in syntax. My recommendation is to make a module for everything, and keep track of all the modules. If you are able to get your hands on Geppetto (its been removed by the developer community), but I find using that tool really makes for a great visual code editing for Puppet modules.