Notes puppet best practices 2018
Minimal rephrasing. If one wants to get things done one has to lower the
resistance. Rephrasing a book is exhausting. Selecting parts is less exhausting and still
helpful although one doesn't have to copy everything otherwise one can just read the book.
And reading the book is always better. The selected parts are useful "triggers" to remember
useful information but not all information.

+++ Preface
- A best practice is the best-known way to use something for positive value while minimizing unnecessary
  risk. This isn’t defined by the manufacturer, rather by practical experience of users in the field.
- Best practices don’t tell you how to operate your business or provide your product.
  That function is provided by the regulatory, legal, and competitive environment in which the 
  business operates.
  A best practice does not tell you why to use a tool, it informs you how to use the tool 
  safely and effectively.
- There isn’t always an objectively correct best practice for every conceivable tool or use case.
  Worse yet, there can be conflicting best practices that apply to a given usage.
- Best practices are formed after lots of errors and learning experiences.

- After you’ve read through it entirely, it is our sincere hope that you will return to individual 
  sections when needed to address a difficult problem, to refresh your knowledge, or to pick 
  up strategies that you might have overlooked on the first read.
  (very true)

+++ Chapter 1
- Puppet can be somewhat alien to technologists who have a background in shell scripting.
  Observation: Nope, if people are ready to learn a declarative paradigm. It is not rocket science.
  Do not be frustrated and try over and over.
- goes explaining the declarative approach. very neat.
- The vast majority of the bad Puppet code I’ve seen has been the result of trying to write
  procedural code in Puppet rather than adapting existing procedures to a declarative approach. 
  Attempting to force Puppet to use a procedural or imperative process ... produces fragile code.
- Declarative languages don’t implement the declared state with magic. (Ah my professor at the uni
  could learn a thing or two from the way things are expressed)
  Declaring that you want a red two-story house with four bedrooms won’t accomplish anything 
  if a construction engineer (the provider) isn’t available to implement it.
- Resource providers are backends that implement support for a specific implementation 
  of a given resource type.
- proceeds to give a nice example declarative vs procedural with one user management.
  Nice warning though! This was a simplified example. Compliance needs usually require 
  disabling accounts rather than removing them to avoid user identifier (UID) 
  reuse and preserve audit history.
- explaining idempotence. Nice. Even with nice small but meaningful examples.
- With an eventually convergent model, the configuration management tool is invoked over and over: 
  each time the tool is invoked, the system approaches a converged state in which all changes defined 
  in the configuration language have been applied, and no more changes take place. 
  For a Puppet codebase to be idempotent, it must reach a convergent state in a single application, 
  and remain in the same state for any subsequent applications.
  The idempotent examples are safe to run as many times as you like. 
  This is a huge benefit in large environments; 
- However, because the exec resource knows only whether or not a command succeeded—not the resulting 
  configuration created—it will report a state change with every Puppet run. 
  This will make monitoring convergence reports for unexpected changes more difficult.
- eventually convergent infrastructures can take a very long time to reach a converged state.
- As a general rule, the Puppet DSL is deterministic, meaning that a given set of inputs 
  (manifests, facts, exported resources, etc.) will always produce the same output with no variance.
  Nondeterministic code can pop up in strange places with Puppet. A common cause of nondeterministic
  code pops-ups is when our code is dependent on a transient or changeable value.
- Bucketing your files is useful for keeping backups, auditing, reporting, and disaster recovery.
- Puppet’s stateless model has several major advantages over a stateful model:
  The node’s catalog is built from scratch every time the node requests a catalog.
  Lack of state allows Puppet servers to scale horizontally.
  Catalogs can be compared.
  Catalogs can be cached locally to reduce server load.
- Be aware that exported resources introduce a source of state into your infrastructure.

+++ Chapter 2
- A codebase is the complete body of source code for a software program or application. 
  For our purposes, it is the total body of code used to build Puppet catalogs.
- I like that the authors say "the best we could provide to you". Thus they don't dream to
  achieve an ideal best, but the best they can perform. Really nice.
- Categories for code and data. To then map to puppet or ideas.
  . Application logic
  . Business logic
  . Site-specific data
  . Service-specific data
  . Node-specific data

  . The logic to configure and deploy a single application fits within a Puppet module
  . Businness logic for app configuration in: Hiera (static data) or Role/Profiles.
  . Site-specific is static, thus hiera or similar.
  . Service specific: static data or databases (puppetDB)
  . Node specific: Facts in puppet, static data, infrastructure data from node classification.

  Although these categories have different sources and needs, 
  a good structure for the code and data will allow a single Puppet module to provide 
  the complete logic to manage a single application, service, or subsystem, regardless 
  of the diversity of data sources just outlined.
- Taking time to evaluate which type of logic is being implemented might seem strange, 
  but this provides essential knowledge. 
  Take the time now, or you’ll spend the time plus significant interest later.
- Application logic is the logic to manage a single application or component and optionally its dependencies
  It contains also data to manage the application, although not necessarily specific data.
- Site-specific data is the data needed to configure your application to serve the
  needs of your site. 
  A site is a collection of systems that offer services to a customer or a team, a group or
  solve a need. Example: the project the systems in the site belong to.
- node data is the data regarding one single system. Example the ip address.
- service data is the data consumed by specific services and can be valid
  across nodes or across sites (if sites are similarly configured)
- business logic. Logic at this level isn’t concerned with package names or the platform-specific 
  implementation details of services. For example, it would define a web server instance 
  without specifying whether to use a specific implementation of a web server.
- example:
  . application logic ensures that the application is installed, configured and running.
  . the service logic/data would configure part of the application to let the service be available.
    (a vhost in a webserver for example)
  . The site specific data can specify additional resources for the application in the site,
    for example backend databases.
  . A load balancer can use node data to specify which nodes are available for balancing.
  . The business logic can describe FQDN to reach the services, user policies and general constraints.
    A server nowadays is quite poiwerful, so there can be overlap but 
    __it is worth indentifying in which category the data or logic applies to make this more manageable__
- How does the data/logic categories apply to Puppet?
  Puppet modules should manage application logic using business and site specific data.
  A well-designed module will usually manage a single service and accept enough 
  input parameters to be used in multiple ways.
  The prerequisites and dependencies of the service can be managed by other modules, 
  and multiple modules can be used together to create technology stacks.
- Business logic antipattern if a module does too much instead of focusing on
  a smaller scope.
  The module conflicts with another module that has a different functional goal.
  The module includes a dependency outside the scope of the module itself.
  The module implements a subsystem that is complicated enough to warrant another module.
  The module implements a feature that was implemented already by another module focused on that feature.
  If that happens, the module should be actually split in different modules.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License