This document discusses Puppet, a configuration management tool. It provides tips to avoid common mistakes when using Puppet such as coding without planning, poor orchestration using tags, and lack of change management between environments. It also discusses using watchdog to monitor Puppet activity and reboot systems if needed, as well as following the three Rs of coding - reuse, reproduce, and recycle - to ensure Puppet code is adaptive for different environments.

1. Puppet
DevOps Meetup

2. Why Puppet?
●
It's fast
●
It's flexible
●
It has a great community
●
Other people find it cool if they knew you know
puppet
●
It's a career milestone

3. Puppet Common Mistakes

4. ●
Coding without planning
– You see a problem, you write scripts to solve the
problem. Then comes another problem, same
thing, you write script to resolved it.
●
Until how long will you be doing this routine?
●
- Lazy system admins are the best admins!

5. ●
Bad Orchestration
– Puppet is admired because of its flexibility,
that's the reason why people find it complex.
●
Why not use “tags”
●
- cpanel (for only cpanel environment)
●
- mta (for only mta servers)
●
- ntp (for only ntp service)
●
Better logging records
●
- using “--admin=name”

6. ●
Poor Change Management
– Puppet has provided a utility for “change
environment”.
●
Staging & Production Environment
●
- Combine it by using a version control
system (SVN)

7. ●
The use of WatchDog
– watchdog is such a daemon. It opens
/dev/watchdog, and keeps writing to it often
enough to keep the kernel from resetting, at
least once per minute. Each write delays
the reboot time another minute. After a
minute of inactivity the watchdog hardware
will cause the reset. In the case of the
software watchdog the ability to reboot will
depend on the state of the machines and
interrupts.

8. ●
3 Rs of coding (code survival)
– REUSE
●
Adaptive commands
– REPRODUCE
●
Adaptive codes for different
environment
– RECYCLE
●
Adaptive!
–