Puppet has been used for infrastructure automation for 10 years. Lessons have been learned about preventing common failures when dealing with variables and classifying nodes. It is important to limit the impact of failures through change control practices like testing changes, limited rollouts, and having rollback options. When adopting new tools or upgrading existing infrastructure, a gradual approach works best to minimize risks.

1. Ten years of
[Puppet] installations.
What now?
Lessons learned, sane suggestions,
outlook for the future.

2. Who am I?
Alessandro Franceschi
More Op than Dev for more than 20 years
Puppet consultant for more than 10 years
CTO example42 Gmbh
Author of puppi, tp, psick …
@alvagante

3. Who are We?
We are expected to be who works or is
interested in IT automation
In particular, “classic” Configuration
Management tools like [Puppet|Ansible|Chef|
Salt|Cfengine..] and their future in a in
container world

4. Infrastructure as code
Code and data that configure the status of out
infrastructure (servers’ configurations, network,
storage, cloud resources…)
Is typically versioned and centralised
Change to the code implies changes to our
infrastructure
Code has to be written, tested, deployed, applied

5. Pains

6. Common failures
When dealing with variables values
When classifying nodes (what goes where)
When shipping wrong code or data
Files changing in the wrong way
Things happening where they shouldn’t
Things keep on happening

7. [Big] failures
They happen
Sometimes from small errors
Often due to lack of knowledge
[Appropriate] Tests would have avoided them
Wide spread failures CAN be mitigated

8. Limit impact
Understand the extent and the potential risk
of every change (quantity and quality of
affected resources)
[noop] manage critical nodes
Controlled rollouts that stop at early warnings
Have a red button

9. Projects

10. Greenfield implementations
Start with the easier, faster, simpler, most useful
First manage systems baselines
Then the most common applications
Prioritise according to effort/benefit
[Don’t] automate, what you do once

11. Infrastructure code design
Seek experts’ advice
Design for future exception (if cheap)
Divide et Impera (Single Point of Responsibility)
Easy to read, easy to use
Avoid or limit coupling
Document, at least the essential

12. Brownfield migrations
(from * to managed and automated)
First automate new deployments
Prioritise what takes more global time
Consider replacement alternative
Migration is on 2 axes:
systems migrated , applications managed
Grab the 80s in the 80/20 rule
Don’t migrate what is going to die

13. Automating applications
Involve domain users and experts
Define together change mode and process
Design for ease of use and expandability
Understand where to place sane defaults
Understand conditions for different data

14. Infrastructure code upgrades
A [module|class|component] at a time
Test (at least the most common conditions)
Refactoring is always an option
If it works, without compromises, keep it
This is where unit tests make the difference

15. Day by day

16. [yaml] operations
Change requests mostly involve modifying infrastructure
code and data
Ideally only data
Once it’s data is easier to delegate to the same requesters
Pick ticket, write, test, deploy, apply, check
(automate as much as possible)

17. Test Changes
“I like tests. I just don’t like to write them”
Do single simple useful tests on what matters
Then connect, integrate and automate
Start from the basics, the commons, the sensible
Test different conditions (os, role, env, dc…)
[x2] peer review changes on what’s critical

18. People and tools

19. Tool is not the issue
Start with what looks most fitting
The sage, when ignorant,
asks for advice and learns
Implementation makes the difference
Integrations of overlapping tools are common

20. Share knowledge
The better we know the tool,
more we do with it
Make people familiar with the tool
Share the right info for the right audience
Gather feedbacks, design with user in mind

21. Classic Tools are mature
[Puppet|Ansible|Chef|Salt|Cfengine..]
They solved real problems of the past
They handle [old|new] technologies
[They] evolved to fix their weaknesses
[They] feature: provisioning, cfgmgmt,
orchestration

22. Future

23. Future is present
[Tools] manage current IT infrastructures
[Tools] manage newest IT technologies
IT of today will still be used in [10] years
Tools with evolve, and us with them

24. For sure in the future
We will have to manage more and more
[cloud|Hardware|VM|container|device|thing]
Someone or something have to do it
Automation is unavoidable
We are here for that

25. a last tip
It applies to all the previous

26. Ask always the usual questions
WHAT
WHY
WHO
WHERE
WHEN
HOW
Share the answers