Not an issue: Interested in how you use yaml files to replace scripts and orchestration

[cwb124]

Interested in this project for moving away from SCCM OSD for Windows deployments. Curious the methodology and how you are using yaml files to replace Powershell scripts for some build orchestration. Replacing an OSD task sequence with Puppet seems like quite a task, and any guidance you have on that would be helpful. Thanks!

[rismoney]

First thing- thank you very much for finding this repo!

I use this repo exclusively to build 100s of servers for a financial services company. Essentially the servers PXE/TFTP boot to a specially formed .iso created by this project. That iso has an embedded copy of puppet and facter. You could probably test this on a vm and boot to the iso created. For it to work, you need to work out your winbuild module...

So PE launches and puppet is installed from source, (gems, facter, etc). That happens here: https://github.com/rismoney/puppet-baremetal-windows/blob/master/make_pe/runtime/Startnet.cmd

Then I call custom.ps1. This script initially normalizes some network adapter craziness (we have large numbers of multihomed servers) so we force everything to use adapter 1 while WinPE is up.

the script prompts for a branch name, as we use dynamic branches with puppet, and host-enforce.ps1 is called (a wrapper for running puppet agent). We don't run puppet against our whole repo, just 4 modules - the key one being winbuild.

the winbuild module, essentially queries hiera to build an unattend.xml file based on an erb template.

Finally after the puppet run, I apply the targetos using dism /apply image and specify xml file. https://github.com/rismoney/puppet-baremetal-windows/blob/master/puppet/modules/templates/post-puppet.ps1.erb

So how do we structure the hiera? We have a naming convention in place for our servers. Its not the best, worst but it is what we have. We classify everything based on names.

For instance we have a node named tc-ad01 This can be evaluated as test, site C, AD domain controller, instance 1. Obviously you can build a hiera topology however you want, but what we do is this-

Break down our hostname facter fact, into its logic parts. and then do something like this in hiera.yaml

:hierarchy:
  - mock_hostname/%{::mock_hostname}
  - mock_function/%{::mock_function}
  - mock_environment/%{::mock_environment}

this allows us to create mock_hostname/tc-ad01.yaml or mock_function/ad.yaml or mock_environment/c.yaml respectively.

We go a lot deeper, but you get the gist.

so if I want to create a win2012 ad domain controller, I could create ad.yaml

targetos: win2012

To learn about some more of the patterns my company does with puppet and windows, you can look here as my coworker presented these os.

https://github.com/jumanjiman/puppetcamp_nyc_2013/blob/master/patterns.md

[rismoney]

Now is it perfect, ideal, no. I did love it when I got it all working It has given us extraordinary build diversity capabilities, but what I have found is that it is overall slow. Say 45 min from baremetal 0 to all the apps installed, ip'd domain joined etc.

I waste a lot of time, installing puppet, and running puppet to get measly variables from hiera to build a yaml erb file. just to run some dism /apply or setup.exe. Plus its a pain to keep up with puppet, (we upgraded to 3.62 from 2.7 and I had to revise a ton of things).

What I am looking at doing is leveraging something like etcd, consul, and do some sort of service discovery.

I don't think you can install windows without PE. so that's minimum. But if you can quickly query something to get the variables you need (ou to put server in, domain name, etc) you can create your xml on the fly.

Say its 2 min to boot to PXE/TFTP to PE, query some services using curl, get back what you need, install windows for 5 or so minutes, a bunch of lengthy PNP/firstime reboots add another 5 , and then run a 10 minute host enforce and I got a 20 something minute, fully app loaded windows box. (we deploy 100s of apps)