5. Our Puppet History
☁ Early Puppet adopters … since version 0.25.X
☁ Large scale environment with distributed team
☁ We made every possible mistake
We’re on our 3rd major Puppet implementation!
6. Lessons Learned
☁ Do NOT make changes directly on the Puppet Master
☁ DO your testing - lint, code validation, etc.
☁ Do NOT pollute your downloaded official modules
☁ DO define and document the standard workflow
☁ Do NOT store sensitive data into modules
19. Awesome, so we have a
neat-looking HA/FT set-up…
…but how do we manage pushing
changes to Puppet Masters?!
20. ☁ Puppet masters can “come and go” randomly
☁ Keep the modules up to date per environment
☁ K.I.S.S. - Tame the learning curve for the team
☁ Avoid reinventing the wheel
Challenges
23. 1. Make changes and commit/push to git server
2. Git server triggers post-commit hook (POST) to Captain Hook server
3. Captain Hook server validates the payload & creates new message:
☁ Full refresh ➩ r10k deploy environment -p
☁ Light refresh ➩ r10k deploy environment
☁ Module refresh ➩ r10k deploy module <name>
4. Captain hook server pushes new message to SNS
5. Captain hook client polls & reads messages ( ➩ r10k)
6. … and we get notified in slack/flowdock/dashboard
Typical Puppet Workflow
25. ☁ Fairfax is a large scale complex environment
☁ Many systems engineers are constantly pushing changes
☁ Puppet architecture designed for HA and fault tolerance
☁ Puppet workflow helps us deploy changes to multiple
masters safely and easily
Summary