Summary
In this chapter, you learned how modules allow you to group code and data, making it easier to share and reuse code. We discussed that modules should focus on a clear single-use responsibility. We examined the directory structure of a module and highlighted where specific Puppet code and data were stored. A good starter manifest structure was shown, highlighting the main manifest (init.pp
) that’s used as an entry point, with parameters acting like public APIs to allow the module to be flexible and include the other classes required. We also saw that the install.pp
, config.pp
, and service.pp
classes focused on installation, configuration, and services, respectively. In the case that the application becomes more complex than this, we discussed how a module can use classes and directories for different components.
Next, we looked at the PDK as a way to automate how modules are created and group common tooling to help us manage and test Puppet modules. We created a Ruby...