Axa Assurance Maroc - Insurer Innovation Award 2024
Ā
How Puppet fits into your existing architecture
1. How Puppet ļ¬ts into
your existing
architecture
2011-11-10
Seattle, WA
SASAG
Garrett Honeycutt
Professional Services Consultant
garrett@puppetlabs.com
http://linkedin.com/in/garretthoneycutt
2. We are hiring
ā¢ Professional Services
ā¢ Technical Training Manager
ā¢ Operations Engineer
11. External Node
Classiļ¬er
Puppet Dashboard
ā¢ source of truth for list of nodes
ā¢ Add/Remove hosts through API - ties into
provisioning
12. Package Management
Run your own Software Repositories
ā¢ You control when package versions change
ā¢ Packages are not mysteriously missing
ā¢ Much faster provisioning
13. Package Management
Version control your repositories
ā¢ Does not mean you need to use a VCS
ā¢ /data/repos/CentOS_5.5_Base symlink to /data/
repos/CentOS_5.5_Base-2011062700
ā¢ Use hardlink(1) to deal with duplicate ļ¬les
15. Package Management
no package { āfooā: ensure => latest }
ā¢ not so homogeneous clusters while groups of
systems converge
ā¢ ideally upgrades happen with rebuilds
ā¢ upgrades are triggered out of band - MCollective
24. Disposable Architecture
ā¢ not how many systems are alive
ā¢ service response times
ā¢ % of anticipated capacity
25. Disposable Architecture
Develop other metrics to determine system health
ā¢ not how many systems are alive
ā¢ response times
ā¢ % of anticipated capacity
27. How Puppet ļ¬ts into
your existing
architecture
2011-11-10
Seattle, WA
SASAG
Garrett Honeycutt
Professional Services Consultant
garrett@puppetlabs.com
http://linkedin.com/in/garretthoneycutt
28. Change Management
with Puppet
2011-11-10
Seattle, WA
SASAG
Garrett Honeycutt
Professional Services Consultant
garrett@puppetlabs.com
http://linkedin.com/in/garretthoneycutt
29. What?
Change - āan event that results in a new status
of one or more conļ¬guration itemsā[1]
[1] - http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library#Change_Management
31. Why?
Compliance with Change Management policies
ā¢ CAB - Change Approval/Advisory Board
ā¢ Different environments have different criteria for
passing to the next one
33. Gate Examples
Puppet Test Area -> Dev
ā¢ Devās agree/know of change
Dev -> QA
ā¢ Devās have completed and self tested
QA -> Prod
ā¢ QA team has veriļ¬ed systems
ā¢ Ops is ready (has runbooks, monitoring setup, ... )
34. Documentation and Policies
Understand your environments
ā¢ What are they?
ā¢ What is their order of precedence?
ā¢ What are their SLAās?
ā¢ Who owns them?
35. Documentation and Policies
Understand gating factors for change
ā¢ What are the gates between each environment?
ā¢ Who approves them?
ā¢ In what forum are they approved?
37. VCS Structure (git view)
same as SVN except
ā¢ you do not have separate directories for
ā¢ trunk
ā¢ branches
ā¢ tags
38. VCS Structure
trunk / master
ā¢ New code that is the best known working code
ā¢ but still not very well tested ...
39. VCS Structure
branches
ā¢ short lived
ā¢ use topical branches!
ā¢ associate branches with ticket numbers, so you can
leverage your ticketing system to capture who is
requesting changes and why
ā¢ avoid assigning branches to people as they tend to
be long lived
40. VCS Structure
tags
ā¢ immutable (even if you can technically make
changes)
ā¢ found that BIND style serials work quite well for
naming tags
ā¢ 2011041300 would be the ļ¬rst tag on April 13th,
2011.
41. Flow
ā¢ Change request comes in (from your ticket system)
ā¢ You create a branch from trunk/master that
corresponds with the request
ā¢ Make changes to the branch
ā¢ Merge the branch back into trunk/master
ā¢ test against trunk/master
ā¢ create a tag
ā¢ associate that tag with the next environment all the
way through to Prod
43. Oops, we found a bug
ā¢ tags are immutable, remember?
ā¢ create a brand new tag off of trunk/master
ā¢ start the process from the beginning
ā¢ short-cuts are more expensive
44. Release Management
Multiple people making changes?
ā¢ You need a release manager to be responsible for
merging from branches into trunk/master
ā¢ Potentially rotate who holds this position
45. Release Management
Multiple teams exchanging code?
ā¢ Investigate using multiple module paths
ā¢ Communication!
ā¢ private github - can facilitate cooperation
46. Mailing List of changes
Create a mailing list for all changes
ā¢ You can always ignore it
ā¢ reach out to those writing poor code before they ask
you to merge it into trunk
ā¢ svnmailer is great
47. Testing trunk/master
Create at least one representative system for each
different type of system you model
ā¢ Run these systems off the code in trunk/master
ā¢ Before cutting a tag, rebuild all these systems from
scratch
ā¢ further tests that relationships between resources
are working
ā¢ proves you can actually provision a system from
scratch
48. Approaches to testing
branches
ā¢ Puppetās understanding of environments is good
for this
ā¢ Setup a different Puppet master per branch
ā¢ Do not rely on a puppet master at all -- use puppet
apply and test locally
49. Change Management
with Puppet
2011-11-10
Seattle, WA
SASAG
Garrett Honeycutt
Professional Services Consultant
garrett@puppetlabs.com
http://linkedin.com/in/garretthoneycutt