Puppet Environments Organized on Different Desktops

Puppet environments such as development, testing and production can be logically organized on different desktops to simplify system configuration management.

Environments provide a safe way to develop Puppet-controlled systems. I organize the Puppet development cycle into three such environments: development, testing and production. Application windows for each environment are organized onto separate desktops, using a desktop manager that I describe in another post.  This is illustrated in the figure below.

Puppet Environments and Desktops

Development Environment on the Development Desktop

The development environment runs on my local workstation. I use a virtualization tool, such as VMWare and VirtualBox, to create both a local Puppet Master as well as a development node. The Puppet Master runs Samba to share the /etc/puppet directory so that I can edit Puppet files using a text editor on my workstation.

A second virtual server emulates the target system that I am developing. The Puppet Agent running on this node connects to the local Puppet Master. For simplicity, security and safety, I connect the development node to a local Puppet Master instead of the one I use in production.

The windows for editing the text files, running Puppet, monitoring log files and file browser are spread across the multiple monitors, as described in another post.  These set of windows define my "Development Desktop".  As I develop the node, I constantly re-run Puppet Agent, check log messages and test locally.  After the completion of each development Story, I check the files into my Subversion code repository.

Testing Environment on the Testing Desktop

The Puppet files that were created in the Development Environment are now checked out to the Testing Environment.  Applications for the Testing Environment are organized on a new desktop, using my desktop manager.  These applications include various shell windows and browser windows such as selenium test suites run under the control of Jenkins.

The QA Server used in the Testing Environment is identical to the Production Server, except for some minor details such as IP addresses, host names and access permissions.  For example, the website you are using now (jaroker.com) was first tested using the QA Server running qa.jaroker.com.

A combination of Puppet and Jenkins is used to re-create the Testing Environment.  The database from the Production Environment is loaded into the Testing Environment (after making changes to such things as the hostname).

Selenium tests perform regression checks on the web application running on the QA Server.  For my SOFIns project, about 30 regression checks are run automatically.  This is in addition to manual testing.

After all checks pass, the Puppet configuration is applied to the Production Environment.

Production Environment on the Production Desktop

The Production Environment uses the same Puppet code that was previously tested in the identical Testing Environment.  Deployment to Production is fast and simple and without surprises because all testing and troubleshooting occurred in the two previous environments.

Desktop Switching

Switching between desktops allows me to switch between the different Puppet environments.  I can develop, test and push new configuration changes to production quickly.  A very complex configuration system is now organized and manageable.