The document discusses strategies for implementing Puppet in legacy environments, emphasizing the challenges faced by older organizations with outdated systems like CRM and ERP. It highlights the importance of automation and configuration management while addressing fears and compliance hurdles that slow down modernization efforts. It also provides practical advice on using Puppet and its features to reverse engineer the current state of systems and manage configurations effectively.

2. Automation Architect - Instruct
Miguel Di Ciurcio Filho - miguel@instruct.com.br
No server left behind: How to
successfully rollout Puppet on legacy
environments

3. What is hot today is the legacy of tomorrow

4. Renewal Cycles
• Older and larger organizations have a lot of business processes and requirements.
• Usually if the organization operates on a regulated sector, everything is much more
conservative.
• Big ships are very slow to turn.

5. What type systems usually are left behind
• What these types of systems have in common?
• CRM
• ERP
• BPM
• Very old and predominant vendors: SAP, SAS, IBM, Microsoft, Oracle, and many
others.
• Vertical scaling.
• Takes weeks and dozens of people to install and configure everything.

6. What type systems usually are left behind
• Servers and environments of the these types of workloads follow a “do not touch
culture”.
• Maybe after 6 months and with a very detailed plan it might be possible to upgrade
the OS and the application itself.
• And the plan is usually a lot of manual changes, VM snapshots, cloning, etc.

7. Reality check
• There are still lots of systems like these out there (the vendors are still making
billions of dollars selling and supporting them).
• Many (most?) of these types of systems completely lack any sort of automation and
configuration management.
• We are in 2017, why? We have all this great tooling for more than a decade!

8. Possible answers
• Fear, Uncertainty and Doubt, for real.
• Might be easier to just wait them to die and try do it right next time.
• Maybe it is not worth the effort.
• There are still all those audits and compliance checks!
• Who could save us?

9. Puppet
• Puppet is all about state (until yesterdays keynote).
• We define what we want, Puppet gets us there and makes sure it stays consistent
over time.
• After years and years of manual changes and people have no idea what is the current
state.
• “Reverse engineer the current state”

10. Get the agent installed
• Raises lots of questions:
• What does it do?
• What are the dependencies?
• What ports does it open?

11. How do we figure the current state?
• FACTER, FACTER, FACTER.
• Write custom facts to figure out the state of users, files, packages, services, etc.
• Facter gives us some options on how to do it.

12. FACTER DEMO

13. Facter gotchas
• Custom facts are synced globally (every node receives everything).
• Make sure to properly confine them.
• Extreme HARD do debug after it syncs.
• Exceptions and stderr are not saved anywhere.
• External facts are handy and easy to do, but they are costly. Every external fact
results on a fork.
• It gets worse on Windows, PowerShell takes many milliseconds to start and then
execute.
• If its a custom fact and it calls PowerShell, same problem.

14. Facter gotchas
• If the state you need to know does not change that often, write a single our a couple
of scritps that run outside of a Puppet run and generate JSONs, YAMLs or text files.
• Stay in Ruby to avoid forking into a shell
• Did you say to use the cache feature of Facter?
• https://tickets.puppetlabs.com/browse/FACT-348

15. After you got the facts straight
• Query them on PuppetDB.
• Inspect them using mcolletive and the inventory custom reports plugin (very handy) .
• https://docs.puppet.com/mcollective/reference/ui/nodereports.html
• Do some analysis to write the manifests.

16. Puppet state based model
• Kind of all or nothing.
• Resources in a manifest could easily obliterate current state and break things.
• Needs careful design and architecture to support exceptions.
• But, we can compare state using —noop!

17. Noop mode
"When applying a resource in noop mode, Puppet will check whether it is in sync, like it
does when running normally. However, if a resource attribute is not in the desired state
(as declared in the catalog), Puppet will take no action, and will instead report the
changes it would have made.”
https://puppet.com/docs/puppet/5.3/metaparameter.html

18. NOOP DEMO

19. In summary
• Write really simple and small profiles to make them easily “noopable".
• Add a control flag to each of them to call or not the noop() function.
• Use the Event Inspector.
• Carefully disable noop node by node, profile by profile, if needed.
• After every server is done, just remove the noop() function from your profiles.
• Honorable mention: Augeas and Hercules Team modules
• https://forge.puppet.com/herculesteam

20. QUESTIONS?