Hello! In this article I want to share with you my impressions of the Puppet configuration for configuring Windows servers.

In general, the task was as follows: to organize the process of automatic delivery and installation of patches for updating remote servers. We chose from well-known configuration managers, the main requirement for which is high-level Windows support. I’ll say right away that they decided to give up Puppet because of the high threshold of entry, the pull approach and the need for knowledge of Ruby. But I really want to share what happened.

Introduction

Puppet has a master agent communication model (architecture), and the master's operating system cannot be Windows. To manage Windows agents, the target machines must have software installed, which is an .msi installer.

Puppet operates with hostnames and the interaction between the master and the agents is carried out via the HTTPS protocol, from which it follows that there are dependencies such as the Apache web server (for the master), and the interaction with the certificates and their settings cannot be avoided.

Test infrastructure

• Ubuntu 16.04 LTS virtual machine for installing the Puppet wizard.
• Target Windows machines that you actually need to manage.

Installation

The installation consists of two parts, according to the number of architectural components.

Master

Installation wizard is described here . The only thing that didn't happen during the installation was that after the SSL certificates were regenerated, Apache stopped running.

After referring to the event log, it becomes clear what the problem is - there is no certificate with the same name as in the /etc/apache2/sites-enabled/puppetmaster.conf configuration file. Go, correct the name (in my case just puppet), ready. By the way, you can look at the master certificate here - / var / lib / puppet / ssl / certs.

Agents

When installing Windows agents, it is likely that something will go wrong. The most important rule - the version of the Puppet wizard must always be comparable (or more) to the version of the Puppet agent .
At the very beginning of the installation process, you can see what the installer includes.

More specifically, many of these components can be found in the documentation . Further we specify the address of the master and it is ready.

How can you see if everything is a success? Go to the Event Viewer and look at the messages, where the source is Puppet. An example of the previously mentioned incompatibility issue of the wizard and agent versions is given below.

If everything went well, the final step is to sign the agent certificate on the master.

puppet cert list --all cert sign <agent-hostname> 

Sample Puppet Manifest

 #          #    ,    #     ,     #     class action::windows { file { 'c:\\Temp\\foo.txt': ensure => present, content => 'This is some text in my file' } } #     ,  Windows class action::default { notify{ "Operating system $::operatingsystem not supported": } } #   osfamily #         case $::osfamily { 'windows': { include action::windows } default: { include action::default } } 

To apply manifests on the wizard: puppet apply <manifest-name> .
On agents: puppet agent --test .

Conclusion

As I wrote earlier, Puppet was not chosen for the task, mainly because it uses a pull management approach, but my opinion is that the stability and age of the system is more important in many situations. In addition, for the push approach, there is mcollective .

Useful sources

1. ssl background
2. puppet agent / master communications
3. puppet architecture overview
4. puppet official modules
5. installation
6. tutorial presentation
7. mcollective