Byron Miller, HomeAway

1. Ge#ng
Started
with
Puppet
@byron_miller
1

2. @Byron_Miller
@byron_miller
2

3. #ATXPUG
@byron_miller
3

4. Meetup!
2nd
Tuesday
@byron_miller
4

5. How
I
got
Started
• Oracle
*.*
• Enterprise
Linux
• Needed
a
way
to
not
waste
every
Monday
and
every
day
I
needed
to
refresh/clone
• Kill
technical
debt
• “Classic
Enterprise..”
@byron_miller
5

6. Vocabulary
• Convergence
–
stabilize
over
[me
• Idempotent
–
unchanged
element
when
operated
on
by
itself
• Orchestra[on
–
Coordina[on
&
Management
of
complex
systems
• Puppet
–
The
ecosystem
• Manifests
&
Modules
–
The
code
@byron_miller
6

7. More
Vocabulary
• ENC
–
External
Node
Classifier
• Mcollec[ve
–
orchestra[on
tool
set
• Hiera
–
key
value
lookup
system
• Node
–
Server/VM
• Facter
–
node
facts
• Types
&
Providers
–
Built
in
resources
you
declare
in
puppet
manifests
@byron_miller
7

8. Theory
(is
where
it
starts)
@byron_miller
8

9. Begin
by
thinking
• Puppet
has
a
learning
curve
but
making
it
work
for
your
organiza[on
is
up
to
how
you
define
“ge#ng
things
done”
and
your
future
• The
“vocabulary”
and
“Verbiage”
of
puppet
is
well
documented
&
simple
with
a
liele
prac[ce
• Think
about
your
work
• Think
about
your
future
@byron_miller
9

10. Puppet
docs
• The
Docs
heps://docs.puppetlabs.com/
• Types
&
Providers
heps://docs.puppetlabs.com/references/stable/
type.html
@byron_miller
10

11. Ge#ng
Started
–
Set
Goals
• What
is
your
goal(s)?
• How
do
you
measure
success
or
failure?
• What
is
your
Intent?
Know
the
theory
of
your
desired
state
@byron_miller
11

12. How
do
you
work?
• Is
your
organiza[on
highly
constrained
&
highly
ordered?
• Do
you
strive
for
self-­‐regula[ng
systems?
• Is
your
goal
compliance?
• Stability?
• Agility?
@byron_miller
12

13. Define
Workflow
• Simple
– Easy
to
install
&
Maintain
• Safe
– Version
Control
-­‐
“Git
workflow”
• Secure
– SSH
/
SSL
/
Accountability
• Scalable
– Handle
1000s
of
nodes
@byron_miller
13

14. Modules
• Everyone’s
a
developer
• Style
Guide
• Testable
@byron_miller
14

15. Long
term..
• Simple
–
Don’t
add
complexity
• Safe
–
Safe
to
fail
experimenta[on
• Secure
–
Auditable
• Scalable
–
Point
in
[me
convergence.
@byron_miller
15

16. Prac[ce
• Track
your
theories
• Test
your
theories
• Experiment
• Experiment
again
• Never
underes[mate
the
value
of
POC’s.
@byron_miller
16

17. Module
Development
@byron_miller
17

18. Be
Pragma[c
@byron_miller
18

19. Style
• Make
quality
a
requirement
• Know
when
to
stop
(don’t
over
op[mize)

20. DRY
–
Don’t
repeat
yourself
• Imposed
Duplica/on
–
Apparent
lack
of
choice
• Inadvertent
Duplica/on
–
Not
realize
that
they’re
duplica[ng
informa[on
• Impa/ent
Duplica[on
–
lazy
/
duplicate
because
it
seems
easier
• Interdeveloper
Duplica/on
–
Mul[ple
people
on
teams
/
mul[ple
teams.

21. Code
• Keep
low
level
knowledge
in
code
• Reserve
Comments
for
high
level
expecta[ons
• Foster
an
environment
where
it’s
easier
to
find
and
reuse
exis[ng
stuff
than
to
write
it
yourself.

22. Scope
&
Avoid
Global
data
• Every
[me
you
reference
global
data
it
[es
you
to
the
other
components
that
share
data
• Use
Scoping

23. Manage
Complexity
Complexity
is
generally
used
to
characterize
something
with
many
parts
where
those
parts
interact
with
each
other
in
mul[ple
ways.

24. Orthogonal
-­‐
Safe
to
Fail
• Independent
/
lightly
coupled
systems
– Eliminates
effects
of
unrelated
things
– Design
self
contained
things
• Increased
produc[vity
&
contained
risk

25. Prototype
(experiment)
• Architecture
• New
func[onality
in
exis[ng
systems
• Structure
or
contents
of
external
data
• Third
party
tools
or
components
• Performance
issues
• User
interface
/
experience
/
design

26. Experiments
• Worry
less
about
correctness,
completeness,
robustness
and
style.
• Focus
on
design
/
defini[on
• Is
coupling
minimized?
• Can
you
iden[fy
poten[al
sources
of
duplica[on?

27. Style
Guides
• heps://docs.puppetlabs.com/guides/
style_guide.html

28. Test
• Loosely
coupled
systems
easier
to
test
–
interac[ons
between
components
are
limited.
– Unit
tes[ng
is
easier
– Test
in
CI
pipeline
• Beaker
/
rspec
/
puppet
lint

29. Refactor
• Avoid
code
rot.
Don’t
let
bad
code
fester
and
turn
all
your
code
into
abandonware
• Code
rot
will
keep
you
from
staying
current,
maintaining
your
skills
and
generally
cause
people
to
shy
away
from
platorm
for
new
shiny
thing..

30. It’s
code
• Version
control
• Test
• Refactor
• Share.
• forge

31. Module
Template
• “puppet
module
generate”
–
use
the
boiler
plate
scaffolding
• Use
Garethr’s
boiler
plate
–
nice
&
updated
heps://github.com/garethr/puppet-­‐module-­‐
skeleton

32. Data
Separa[on
• Hiera
– Yaml,
Mysql,
GPG
etc..
• ENC
– Puppet
PE
– Foreman
– Homemade
– ?
• Single
source
of
truth..
Anyone
have
any?
J

33. Parameterized
Classes
• Great
for
ENCs
• Easy
to
set
default
values
• Portable
/
Shareable
• Just
do
it..

34. Class
Inheritance
• Use
within
a
module
to
reduce
repe[[on
(DRY)
• Inheri[ng
from
other
modules
decreases
modularity,
but
hard
to
avoid
– ENC
confusion

35. Code
Defensively
• Catch
unexpected
events
before
they
break
things
–
gracefully
bow
out
if
you
don’t
support
platorm
– Default
case
fail
on
unsupported
platorms
• Plan
for
Puppet
Future
parser
– Some
changes
/
restric[ons
– Expressions,
Lambdas,
Itera[ons
&
more
heps://docs.puppetlabs.com/puppet/latest/
reference/experiments_future.html

36. It’s
code
but…
• Don’t
think
of
it
as
“object
oriented”
from
a
programmers
perspec[ve
• It’s
a
“Domain
Specific
Language”
(DSL)
used
to
describe
a
desired
state.
@byron_miller
36

37. Prac[ce
• Vagrant
/
VM
instances
– Build
/
test
/
deploy
– Pull
modules
from
forge
• Read
• Test
• Deploy
• experiment
@byron_miller
37

38. Opera[ons
@byron_miller
38

39. More
Thinking
• How
do
we
work?
• What
should
we
automate?
• What
are
our
goals?
• Systems
thinking..
• Sense
Making..
@byron_miller
39

40. Sense
Making
@byron_miller
40

41. Simple
Domain
• Start
with
what
you
know
• Relieve
pain
points
• Remove
constraints
• “Cause
–
effect”
rela[onships
–
you
can
codify
this
@byron_miller
41

42. Chaos
@byron_miller
42

43. Simple
-­‐>
Chaos
• When
simple
breaks
– All
hell
breaks
loose.
@byron_miller
43

44. Infrastructure
• as
code..
Bus[ng
out
some
Deming..
“As
a
System
of
profound
knowledge”
A. Apprecia[on
for
a
system
B. Theory
of
Varia[on
C. Theory
of
Knowledge
D. Psychology
@byron_miller
44

45. Systems
Approach
Taking
a
systems
approach
results
in
viewing
the
organiza[on
in
terms
of
many
internal
and
external
interrelated
connec[ons
and
interac[ons
as
opposed
to
discrete
and
independent
departments
or
processes
governed
by
various
chains
of
command.
Apprecia[on
for
a
system..
@byron_miller
45

46. Varia[on
Why
did
something
go
wrong?
How
can
we
repeat
success?
Common
Cause
–
predictable
varia[on
within
a
system
Special
Cause
–
unique
event
outside
the
system
@byron_miller
46

47. Knowledge
• Theory,
Experimenta[on,
Sta[s[cal
analysis,
conveyed
meaning,
processes.
“Informa)on
is
not
knowledge”
-­‐Deming
@byron_miller
47

48. Psychology
• Human
Systems
• Drive
out
Fear
• Mo[va[on
@byron_miller
48

49. Management
Is..
• Predic[on
• Theory
– What
causes
posi[ve
interac[ons?
– What
removes
conflict?
• Understanding
&
Conveying
meaning
of
a
system
• People..
@byron_miller
49

50. Think
of
ecology
• Adopt
an
ecological
metaphor
• Codify
stories
– Feedback
loops
– Itera[ons
– Tes[ng
– Repor[ng
@byron_miller
50

51. The
system
Intent..
• What
causes
behaviors
outside
the
system?
“The
obliga[on
of
any
component
is
to
contribute
its
best
to
the
system
but
it
will
not
do
that
unless
the
system
is
managed”
@byron_miller
51

52. Future
Backwards
@byron_miller
52

53. Where
we
want
to
be
Future
Backwards:
Perspec[ves
of
people
within
an
organiza[on
give
them
a
limited
view
of
the
present,
and
such
entrained
paeerns
of
past
percep[on
can
determine
its
future.
@byron_miller
53

54. Your
future
Ge#ng
there..
• Flow
• Measure
• Retrospec[ves
• Involve
Stakeholders
• Sense
-­‐>
Categorize
-­‐>
Respond
“Bias
against
crea)vity
is
fueled
by
uncertainty”
-­‐Deming
@byron_miller
54

55. Puppet
Opera[ons
• Develop
your
“System”
to
allow
experimenta[on,
upkeep,
maintenance
and
opera[onal
agility.
• Keep
it
Simple
• Grow
&
Learn
• Prac[ce
all
the
[me
• Prac[ce
More
@byron_miller
55

56. Ops
Pipeline
• Build
Build
Build
– Just
like
code
rot,
don’t
have
server
rot
CI
• Puppet
Lint
• Beaker/Rspec/ServerSpec
• Rubocop
@byron_miller
56

57. Keep
it
simple
• Decouple!
– Use
Roles
&
Profiles
(the
one
“paeern”
I’ll
always
recommend)
– Hiera
is
your
friend,
but
don’t
go
too
nuts
– Keep
your
ENC
simple
-­‐
categoriza[on
@byron_miller
57

58. Use
the
feedback
loops
• Pay
aeen[on
to
pipeline
– Don’t
let
things
rot
– Seek
out
improvements
– Share
lessons
learned
– Get
feedback
• Puppet
Reports..
• Puppet
Dashboard..
• Event
Inspector
(PE)..
(and
other
tools)
@byron_miller
58

59. Don’t
stop
Thinking
• Maintain
a
consistency
of
understanding
and
effort
• Don’t
focus
on
local
op[mums
• Quality
starts
here
• Quality
starts
with
intent
• No
system
whatever
the
effort
put
in
will
be
free
from
accident/incident/error
@byron_miller
59

60. Enable
People
• Puppet
enables
me
to
codify
to
“my
future”
• Puppet
enables
me
to
know
my
past
@byron_miller
60

61. Prac[ce
• Test
Upgrades
• Test
new
forge
modules
• “Safe
to
fail”
experimenta[on
• Serverspec..
Beaker..
@byron_miller
61

62. Keep
trying
• Look
at
logs
• puppet
-­‐-­‐debug
–verbose
• Talk
to
community
• Use
the
dashboard
• puppet
-­‐-­‐help
@byron_miller
62

63. Community
• Google
Groups
• Twieer
• “Ask”
puppetlabs
• Online
Documenta[on
• IRC
• User
Groups!!
• Sh*t
Gary
Says
-­‐
hep://garylarizza.com/
@byron_miller
63

64. Ques[ons?
“Organiza)ons
which
design
systems…
are
constrained
to
produce
designs
which
are
copies
of
the
communica)on
structures
of
these
organiza)ons.”
-­‐
M.
Conway
@byron_miller
64