Puppet Best Practices. Design Patterns for Maintainable Code - Helion
ISBN: 978-14-919-2304-7
stron: 308, Format: ebook
Data wydania: 2018-08-24
Księgarnia: Helion
Cena książki: 160,65 zł (poprzednio: 186,80 zł)
Oszczędzasz: 14% (-26,15 zł)
If you maintain or plan to build Puppet infrastructure, this practical guide will take you a critical step further with best practices for managing the task successfully. Authors Chris Barbour and Jo Rhett present best-in-class design patterns for deploying Puppet environments and discuss the impact of each. The conceptual designs and implementation patterns in this book will help you create solutions that are easy to extend, maintain, and support.
Essential for companies upgrading their Puppet deployments, this book teaches you powerful new features and implementation models that weren’t available in the older versions. DevOps engineers will learn how best to deploy Puppet with long-term maintenance and future growth in mind.
- Explore Puppet’s design philosophy and data structures
- Get best practices for using Puppet’s declarative language
- Examine Puppet resources in depth—the building blocks of state management
- Learn to model and describe business and site-specific logic in Puppet
- See best-in-class models for multitiered data management with Hiera
- Explore available options and community experience for node classification
- Utilize r10k to simplify and accelerate Puppet change management
- Review the cost benefits of creating your own extensions to Puppet
- Get detailed advice for extending Puppet in a maintainable manner
Osoby które kupowały "Puppet Best Practices. Design Patterns for Maintainable Code", wybierały także:
- Hands-On Kubernetes, Service Mesh and Zero-Trust 88,72 zł, (67,43 zł -24%)
- Microservices for Machine Learning 88,72 zł, (67,43 zł -24%)
- Generative AI for Enterprises 88,72 zł, (67,43 zł -24%)
- Oracle Cloud Infrastructure 88,72 zł, (67,43 zł -24%)
- Mastering DevOps in Kubernetes 84,60 zł, (71,91 zł -15%)
Spis treści
Puppet Best Practices. Design Patterns for Maintainable Code eBook -- spis treści
- Preface
- What Is a Best Practice?
- Who Should Read This Book
- Why We Wrote This Book
- A Word on Puppet Today
- Navigating This Book
- Online Resources
- Conventions Used in This Book
- Using Code Examples
- OReilly Safari
- How to Contact Us
- Acknowledgments
- 1. The Puppet Design Philosophy
- Declarative Code
- What Is Declarative Code, Anyway?
- Resource Types and Providers
- Procedural Example
- Imperitive/procedural code
- Declarative replacement
- Gain by replacing procedural code
- Nondeclarative Code with Puppet
- Idempotency
- Side Effects
- Resource-Level Idempotence
- Run-Level Idempotence
- Nondeterministic Code
- Stateless
- Benefits of Stateless Design
- Sources of State Information
- Filebuckets
- Exported resources
- Hiera
- Inventory and reporting
- Custom facts
- Summary
- Declarative Code
- 2. High-Level Code and Data Design
- Code and Data Organization
- Code and Data Categories
- Types of Code Logic
- Application logic
- Site-specific data
- Node data
- Service data
- Business logic
- Examples of Logic Types
- Mapping Data Types to Puppet Use Cases
- Application Logic and Puppet Modules
- Example component module
- Identifying business logic in Puppet modules
- Identifying site-specific data in Puppet modules
- Business Logic Should Not Be Written into Component Modules
- Less is more
- Small components are flexible building blocks
- Distinct components avoid conflicts
- Small components are easily testable
- Business Logic with Roles and Profiles
- Roles describe business logic and site-specific configurations
- Profiles implement technology stacks
- Roles and profiles versus node classifiers
- Business, Service, Site, Node, and Application Data
- Global layer: business data
- Environment layer: site, service, and node-specific data
- Module layer: application defaults
- Hiera Data Sources
- Static data in Hiera
- Service discovery from Hiera
- Accessing third-party external data sources in Hiera
- Node Classification
- ENCs
- Hiera as a node classifier
- Appropriate uses of node data
- Application Logic and Puppet Modules
- Summary
- Code and Data Organization
- 3. Coding Practices
- The Style Guide
- Coding Principles
- KISS: Keep It Simple
- The Single Responsibility Principle
- Separation of Concerns
- Interface-Driven Design
- DRY: Dont Repeat Yourself
- Dont Reinvent the Wheel
- YAGNI: You Aint Gonna Need It (or Youre Not Google)
- Code Practices
- Balance of Resources Versus Logic
- Balance of Code Versus Data
- Conditional Logic
- Iteration
- Iteration with resources
- Iteration with functions
- Generating Lists
- Variables
- Variable Naming
- Referencing Variables
- Variable should be fully qualified
- Other Variable Use Cases
- Avoid anonymous regular expressions
- Prefer named regular expressions
- Trusted Variables
- Order of Assignment for Top-Level Variables
- Assignment with Selectors
- Attribute Values Chosen by Conditional Evaluation
- Variable Inheritance
- Strict Variables
- Function Calls
- Always Use Parentheses
- Functions for Logging and Debugging
- String Manipulation Functions
- Path Manipulation
- Input Validation Functions
- Data validation functions
- Data type comparison
- Value existence comparison
- Catalog Tests
- Data Transformation
- Templates
- ERB Templates
- EPP Templates
- EPP Versus ERB
- Other Language Features
- Summary
- 4. Puppet Module Design
- The Puppet Development Kit
- Installing the Puppet Agent
- Using the Ruby that Comes Bundled with Puppet
- Installing the Puppet Development Kit
- Favor Editors or IDEs with Puppet Plugins
- Using Vendor-Provided or Community Modules
- Picking Good Modules
- Module Checklist
- Module Applicability to Your Needs
- Contributing Modules
- Designing Modules Well
- Make Use of Module Structure
- Keep the Module Focused
- Design Modules for Public Consumption
- Planning and Scoping Your Module
- Basic Module Layout
- The Modules Main Class
- An example main class
- Module Parameters
- Parameter defaults
- Parameter default complexity
- Parameter default limitations
- Parameter naming conventions
- Parameter defaults
- Input Validation
- Data in the Module
- The params.pp Pattern
- Hiera Data in Modules
- Modularizing Classes
- Dependencies
- Class Relationships
- Class Containment
- Containment
- Anchors
- Intentionally uncontained classes
- Interfacing with Classes
- Passing data via parameterized class declarations
- Passing data via fully qualified variable references
- Passing data via class inheritence
- Reusing Defined Types
- Providing Clean Service Interfaces with Defined Types
- Simplify Complex Operations with a Defined Type
- Interacting with Other Resouces in the Module
- Creating relationships with resources in the module
- Including other classes
- Creating Useful Documentation
- README, REFERENCE, and Other Markdown
- Usage examples
- Dependencies
- License information
- REFERENCE Markdown
- Parameter documentation
- Inline documentation
- README, REFERENCE, and Other Markdown
- Summary
- The Puppet Development Kit
- 5. Resources
- Using Resources to Implement Change
- Resource Types Abstract Implementation Details
- Use the Most Specific Resource Type
- Examining a Naked Resource
- Exploring Resources with Tools
- puppet describe
- puppet-strings
- puppet resource
- Displaying a resource in Puppet language
- Displaying all instances of a resource
- Declare a resource on the command line
- puppet apply
- Resource Declaration
- Ensure states
- Use Variables for Data-Driven Declaration
- Static declaration
- Interpolation
- Use Arrays for Similar Resources
- Using Automatic Resource Relationships for Clean Code
- Avoid complex structures in resource declarations
- Resource Declaration by Functions
- The create_resources() function
- The ensure_ functions
- Resources Metatypes
- Resource Metaparameters
- alias
- audit
- Ordering metaparameters: before and require
- Notification metaparameters: notify and subscribe
- Avoid tight relationships whenever possible
- noop
- schedule
- stage
- tag
- Avoid Parse-Order Problems by Using Virtual Resources
- Dangling relationships to unrealized resources causes breakage
- Exporting Resources
- Comparing virtual and exported resources
- Safely using exported resource
- Overriding and Modifying Declared Resources
- Resource Default Statements
- Per-expression defaults provide a solution
- Per-expression defaults provide a way to avoid surprises
- Resource Chaining
- Resource Collectors
- Resource Default Statements
- Resource Best Practices
- Custom Resource Types
- The ACL type
- The anchor type
- Augeas providers
- The datacat types
- The file_line resource type
- The match attribute
- The after attribute
- The gnupg_key type
- The ini_setting and ini_subsetting resource types
- The registry type
- The reboot type
- The vcs_repo type
- The windows_env native type and provider
- Useful Defined Types
- The concat defined type
- The account defined type
- Custom Resource Types
- Summary
- Using Resources to Implement Change
- 6. Hiera Data
- Separating Code and Data
- Global, Environment, and Module Data
- Hiera Backends
- Designing the Hiera Hierarchy
- Variable Interpolation
- Node-provided facts
- Use the facts hash to retrieve variables
- Viewing a nodes facts
- Use trusted facts when available
- Remove environment interpolation
- Label node classifier-provided data
- Avoid using Puppet variables
- Use explain to debug lookup interpolation
- Node-provided facts
- Design Guidelines
- Most specific to generaltop to bottom
- Avoid unnecessary deep hierarchies
- Deep hierarchies should contain data relevant to the top level
- Useful Hierarchy Levels
- The accounts hierarchies
- Packages hierarchy level
- Team hierarchy level
- Eliminating Data
- Hierarchy design
- Package management
- User management
- Service discovery
- Variable Interpolation
- Accessing Hiera
- Automatic Parameter Lookups
- Defined types
- Hiera Function Calls
- Key naming conventions
- Hash and array data merges
- Data-driven class assignment
- Converting Serialized Hiera Data into Resource Declarations
- Interpolation in Your Data
- Automatic Parameter Lookups
- The Built-In Backends
- YAML
- JSON
- HOCON
- eYAML
- Custom Hiera Backends
- Database and NoSQL Engines
- Service Discovery Backends
- Encrypted Key/Value Storage
- Encrypted Hiera is not filesystem security
- Summary
- Separating Code and Data
- 7. Roles and Profiles
- Roles
- Creating Readable Roles
- Role classes
- Hiera-defined roles
- Design Roles for a Singular Use Case
- Provide the Role for Use in Data Lookups
- Identifying node roles in the ENC
- Identifying node roles using node facts
- Creating Readable Roles
- Profiles
- A Sample Service Profile
- Providing Actionable Data in Profile Parameters
- Shared Hiera data
- Implementing Business Logic in Profiles
- Defining Module Relationships in Profiles
- Creating Metaprofiles to Group Configurations
- Avoid creating a base profile
- Encapsulate one-off configurations in new profiles
- Designing an Appropriate Profile Structure
- Implement the smallest usable component
- Handling multiple instances
- A profile for each service instance
- Creating instances from a data example
- Testing Roles and Profiles
- Validating Profiles by Using Unit Tests
- Confirming Profile Implementation with Acceptance Tests
- Summary
- Roles
- 8. Node Classification
- What Data Should the Node Classifier Provide?
- Roles and Profiles
- Node-Specific Data
- Node Statements
- Node Statement Matching
- Default node statement
- Regular expression node statements
- Partial node match
- Replacing Node Inheritance
- Node classification with inheritance
- Node classification using roles and profiles
- Node Parameters Within Node Blocks
- Node Statement Matching
- Fact-Based Classification
- Fact-Based Role Assignment
- Security and Fact-Selected Roles or Profiles
- Mitigating the risk by using trusted facts
- Fact-Based Hiera Classification
- Customizing Hiera hierarchy using facts
- Listing classes in Hiera data
- Declaring classes from Hiera data
- Node Parameters with Hiera Classification
- Avoiding Node Data in Manifests
- Serverless Classification
- ENCs
- What Data Can an ENC Provide?
- Class list (node role)
- Node parameters
- Puppet environment
- Puppet Management Consoles
- Puppet Enterprise console
- Puppet Dashboard
- Inventory and Infrastructure Management ENCs
- Foreman
- Cobbler
- Build your own ENC
- What Data Can an ENC Provide?
- Summary
- What Data Should the Node Classifier Provide?
- 9. Release Engineering and r10k
- Puppet Environments in Depth
- Puppet Directory Environments
- Selectable Blocks for Catalog Building
- Environment Configuration
- Environment Independence and Isolation
- Deploying with r10k
- What Does r10k Actually Do?
- The Control Repository
- Control Repository Branch Contents
- Files expected by Puppet
- Files used by r10k
- Alternative file and directory conventions
- r10k Configuration File
- Puppetfile
- Modules
- Hiera data
- r10k Deployment Walkthrough
- Installing r10k
- Creating a test branch
- Deploying with r10k
- Uses for r10k
- Build Development Environments
- Simplifying Acceptance Testing
- Implement Continuous Integration, Delivery, and Deployment
- Deploy Production Environments
- Build and Package
- A hybrid approach
- Release Management Strategies with r10k
- Stage/Production Branches
- Single Branch (GitHub Flow)
- GitFlow
- Invoking r10k
- Puppet Prerun Command
- Deploying on Receipt of a WebHook
- Puppet Enterprise: Code Manager WebHook
- Orchestrating Deployments with MCollective/Choria
- Invoking r10k in Testing Frameworks
- Combining Multiple Invocation Methods
- Concurrency
- Migrating to r10k
- Repository-per-Module Benefits
- Configuring an Environment in the Control Repository
- Enabling Monolithic and Per-module Hybrid Deployment
- Adding r10k deployment of monolithic repo
- Modulepath adjustment
- Adding r10k to existing deployments
- Moving Modules to their Own Repositories
- Moving public modules
- Moving dependency modules
- Moving dependent modules
- Placing Roles and Profiles in the site/ Module Directory
- Remove Fully Qualified Paths
- Moving Shared Tools to Their Own Repository
- Implementing Test Cases
- Best Practices for Puppet Deployments
- Using Repository Access Control to Enforce Deployment Policy
- Security of the control repository
- Hiera data in the control repository
- Enabling Multiteam Coordination
- Deployments for multiple team modules
- Multiple control repositories providing Puppet environments
- Multiple module directories within a single Puppet environment
- Pinning Module Versions
- Isolating Puppet Extensions
- Utilizing Standard Environment Configuration Practices
- Keeping Hiera configuration within the environment
- Global modules
- Environment manifests
- The modules directory
- Test tools, rake tasks, and other utilities
- Environment documentation
- Git Best Practices
- Deployment Practices
- Concurrency protection
- Dont go cowboy on shared infrastructure
- Using Repository Access Control to Enforce Deployment Policy
- Summary
- Puppet Environments in Depth
- 10. Extending Puppet
- The Cost of Extending Puppet
- Minimizing Development Costs
- Reducing Upgrade Costs
- Testing
- Static Code Analysis
- Puppet metadata
- Puppet code lint
- Ruby code cop
- Unit Testing
- Dependencies
- Input testing with rspec
- Resource validation
- Testing input validation
- Acceptance Testing
- Use containers or virtualization for acceptance testing
- Resource validation
- Static Code Analysis
- Creating Facts
- Distributing Facts in Modules
- Custom facts
- External facts
- Facts Puppet Cant Know
- Structured Facts
- Abusing Facts
- Trusted Certificate Attributes
- Distributing Facts in Modules
- Custom Types and Providers
- Avoiding Creation of Duplicate Types
- PowerShell DSC
- PowerShell DSC-lite
- inifile
- XML
- The archive resource
- PowerShell DSC
- Creating a New Resource Type
- Describing state with a type
- Defining the types interface
- Custom Resource Providers
- Adding providers to a resource
- Inheriting an existing provider
- Creating a resource provider
- Retrieving existing resource instances
- Reuse Existing Frameworks
- Text frameworks
- JSON, YAML, XML, and other well-known formats
- Windows Management Interface and object linking and embedding
- Avoiding Creation of Duplicate Types
- Creating Custom Hiera Backends
- Choose the Appropriate Backend Type
- Creating a High-Performance Backend
- Using Puppets Public Classes and Method Calls
- Puppet Faces
- Indirection
- Deploying Extensions
- pluginsync
- Deploying Gem Dependencies
- Deploying Ruby Gem Extensions on Puppet Server
- Summary
- The Cost of Extending Puppet
- Index