The document discusses the problems with tightly coupling application configuration to the deployment process in traditional Puppet-driven deployments. It proposes using inline templates to decouple configuration from Puppet masters and version control systems. This would allow configuration values to be provided securely at deployment time rather than being exposed. The benefits are said to include embracing CI/CD processes, reducing complexity, opportunities for error, and meeting security and policy requirements by separating sensitive values.

1. Inline Template Puppet Type
Exploring the business case for inline
templates
By @monkee_magic

2. The problem I am trying to solve:
• Configuration of applications is tightly bound to the
deployment process
• The people deploying applications are not the people
writing the configuration
• Flexibility is reduced and complexity added by adding
more process
• Increased opportunities for error or misconfiguration
• Deployment environments are intrinsically not identical
• Sensitive configuration values are exposed in version
control and deployment systems

3. Real World Example:
Configuration of applications is tightly bound to the
deployment process
• In most puppet driven deployments the products of
development (packages) and their configuration are
stored in version control and local to the puppet
server.
• What? Do you mean that the configuration and files
are now in four different places across multiple data
security zones with their configuration exposed to
many people?

4. Real World Example:
The people deploying applications are not the people writing
the configuration
• In most puppet driven deployments the deployment
is controlled by specific automation engineers or BAU
• What? Do you mean that the configuration and files
are now controlled by people who are not intimately
familiar with them?
• Who? Who are these mysterious engineers?
• Why? Why do we need more people to get our
application to our customers?

5. Real World Example:
Flexibility is reduced and complexity added by adding more
process
• In most puppet driven deployments the deployment
manifests and files are hand edited then checked
into Version Control
• What? I thought we used a CI tool and no one was
ever going to hand edit a file again.
• Who? Is now responsible for the deployment and
testing of our application?

6. Puppet templates on the master:

7. Current puppet templating:
• The module manifests, configuration values and
templates stored on the puppet master
• Traditional methods of managing puppet manifests
like GIT contain artifacts from other systems like CI
environments
• Configuration is potentially exposed – violates PCI
requirements or company policy

8. Under the hood: File Type Module

9. Puppet templates on the node:

10. Node or inline templating:
Technical Solution Business Reward
Template is now detached from puppet
server
Embrace the CI/CD process
Don’t store artifacts in Version Control
Template is local to the application Embrace the CI process
Reduce complexity
Reduce opportunities for error
Encourage change for improvement
Reduce deployment friction
Add as a CI build task
Configuration values can be safely
separated from the code
Meet PCI & company policy
Respect business task separation
Values can be encrypted Meet PCI & company policy
Respect business task separation

11. Under the hood: Inline_template Type module

12. Where to from here ???
• Decouple the templating further so the source of the
configuration values are also detached from puppet
• Configuration values should be in a sensible format
like YAML or JSON
• Encrypt and securely store sensitive configuration
information

14. Future puppet templates on the node: