run custom chef cookbook

[rjhornsby]

Sorry if this is obvious and I'm just being dumb. This project is extremely comprehensive and well written. There are, however, many layers of abstraction making it hard to wrap my mind about how it works. I'm trying to use this to build a custom vagrant box that uses chef (chef-solo/local mode is fine) to install a bunch of stuff (iis, coldfusion, etc) on win2019 using a custom cookbook. The cookbook itself works fine on its own (via kitchen, in production, etc), but I'm not sure how to insert/plug it into the process of building a box that I can hand to the application developers with all the stuff they need.

I see the "workstation" examples in the other repo, but am having a hard time connecting the layers of abstraction there back to what needs to be done.

In the README section "Chaining builds further" it talks about how you can add iis to the configuration name. That made me think adding a super simple cookbook to /src ie /src/hello would let me chain that in a similar way. However, when I look at the target list --target=info I don't see for example, IIS with Windows 2019 boxes - only win2022. So naturally, I don't see anything 'hello' showing up in the list.

How does this chaining work in terms of what dotnet cake --target=info decides is possible? More to the point, what's the process for injecting an arbitrary cookbook to be run during the build process so that the end result has/contains the results of having executed the cookbook?

[gusztavvargadr]

@rjhornsby thanks for reaching out and sorry if the layer of abstractions make it hard to extend the project. First of all, there are no dumb questions, so thanks for asking for clarification. Also, I did not document a lot of concepts, so it is perfectly valid not to grasp it as it is, I often get lost myself when extending this code when trying to understand what I've been thinking when writing it years ago :)

As per you actual questions, configurations and chains are not discovered dynamicall,y but statically defined in code in the repo root's build.cake file. For example, here is the exact location where the IIS setup is configured for Windows Server 2022. All the other commands (info, restore, build, etc.) use these as their configurations. Under the hood the logic is that it is being used to find the components that get merged to create a final Packer template, and then that is being worked on with the regular Packer commands.

I indeed would suggest creating a wrapper cookbook that contains all the references to the other components you want to include. First, you could add to the root build.cake something similar to define your configuration called hello:

var ws2019s_hello = PackerTemplates_CreateWindows(
  "ws2019s_hello",
  "hello-windows-server-2019-standard",
  $"1809.0.{version}",
  ws2019s
);

After this, dotnet cake --target=info should already list your configuration. To make the build work, you indeed need a folder under src, like under src/hello, that contains the Packer-specific configuration for that image, including provisioning with Chef. My suggestion is to copy e.g. the iis one, and update the files per your requirements, they should be self-explanatory, For the provisioning, the main thing is to have a cookbook with the name hello in it with the proper metadata and Polcyfile, and then it will be used during the build.

I hope this helps make this work, if not, feel free to invite me to your fork and I can help setting up a hello world example there.

FYI, I am aware of all the complications above, so I am now trying to simplify things a lot in this PR. The main motivation for this setup years ago was that it was hard to prevent a lot of duplication with the Packer JSON templates, but with the HCL-based configuration system it is much more simpler. Also, the workstation repo was built before the policyfiles concept in Chef, so that's why it's also a lot more complicated than it should be now. I will try to rework that as well once this Packer update is done.

[rjhornsby]

I had a longer reply written out and somehow trying to deal with some other nonsense I closed the window and lost it. Appreciate your help and explanation. The intent behind the layers of abstraction makes sense. The overall design makes sense because it's highly modular. Sometimes I just have a hard time wrapping my brain around things, especially when those things are windows.

After some trial and error your suggestion is working properly. It's key to get the name exactly correct in the places it matters in Policyfile.rb and template.json. It also must match up exactly the way the builder expects it in the build.cake entry so that the chaining happens correctly.

When getting something wrong, the failure mode isn't always obvious, so it's really important to watch the first part of the builder output to make sure the runlist is what you expect it to be.