際際滷

際際滷Share a Scribd company logo

Inline Template Puppet Type

Download as PPTX, PDF
L
Lyndon Swan

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 of 14
Download to read offline
Inline Template Puppet Type Exploring the business case for inline templates By @monkee_magic
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
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?
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?
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?
Puppet templates on the master:
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
Under the hood: File Type Module
Puppet templates on the node:
Node or inline templating: Technical Solution Business Reward Template is now detached from puppet server Embrace the CI/CD process Dont 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
Under the hood: Inline_template Type module
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
Inline Template Puppet Type
Future puppet templates on the node:

More Related Content

Inline Template Puppet Type

  • 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
  • 10. Node or inline templating: Technical Solution Business Reward Template is now detached from puppet server Embrace the CI/CD process Dont 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: